|Vibrant Life Plans||Electronic Information System Plan||Data||Admin Scale For Vibrant Life|
|New Theme Page||Policies||Programs||Notes||Table Of Contents|
Somebody There: Tom Martin is the IC for this Project
Somebody taking responsibility for the area or action: Tom Martin. This can be changed to be Nick Reid, with Karl's approval. Both of them can work on the Project, but there is still only one I/C.
Form of Organization Planned Well: Karl Loren is the Plan I/C, and this web site presents the various elements of the Plan.
Form of Organization Held or Reestablished: Tom Martin reports progress to Karl Loren and Karl keeps the work within the Plan, and revises the Plan, as necessary so that it always covers the work being done.
Organization Operating: The organization for this Project is and has been operating.
Vital Target #1:
There is an initial research and study target -- to "learn about cookies" so that we can establish one or more "Cookie Policies" for our web pages.
As a resource to start with, here are articles already published on this web site that can be reviewed, plus whatever other sources Tom wants to look up and, presumably publish to our web site as convenient reference.
The actual Vital Target here is a draft of a written "Cookie Policies" to cover the type of cookies we will use on our web pages, and to explain how, if at all, they will be tied in with our server database. This Policy should be written for Karl's approval, then published in our Policy section, and then adhered to for our web designing.
Typical Error Message: Cookies Not Saved
Cookies Are Short Pieces Of Data Used By Servers
Whenever a web browser requests a file from the web server that sent it a cookie, the browser sends a copy of that cookie back to the server along with the request. Thus a server sends you a cookie and you send it back whenever you request another file from the same server. In this way, the server knows you have visited before and can coordinate your access to different pages on its web site. For example, an Internet shopping site uses a cookie to keep track of which shopping basket belongs to you. A server cannot find out your name or e-mail address, or anything about your computer using cookies.
Microsoft Knowledge Base Article - 260971
A cookie is a text string that is included with Hypertext Transfer Protocol (HTTP) requests and responses. Cookies are used to maintain state information as you navigate different pages on a Web site or return to the Web site at a later time. This article provides information about cookies.
What is a Cookie? Slide Show
These are "slide shows" and they are a good way to explain what a "cookie" is and other features of a cookie. Note that this slide show includes how cookies can be used improperly, usually without your knowledge.
Here is a Web Designer Asking The Same Question I have Asked
I have just about no experience working with cookies in PHP, although I do have some moderate experience with other elements of PHP and with MySQL.
For a site I'm making, I want to create a Login page where users enter their info and password. Then I want to send them to a script that checks the username/password against the database, and sends the user to the members page if successful, or back to the login page if unsuccessful.
Vital Target #2:
Thus, I have assumed that as a person approaches our web page there will be SOME information contained in the cookie, but not an entire history of relationship between that person and Vibrant Life.
That history WILL be, however, represented by the information in the data base. Thus, I assume that the cookie will be used to locate the person in the data base and serve up information for our immediate use == information that is contained in the data base, not just the cookie.
Thus, while the "cookie" may not have total purchases by the person, the data base would have that information. The cookie, then, connects with the data base and that person's total purchases are available to either display on a screen, or to influence how the web might appear to the person.
We should recognize that access to a person's information in the data base will have several different levels of security. The cookie would allow display at the lowest level of security -- perhaps only a name. If there is to be any DISPLAY of further information, then some further security step is required, like the requirement for entry of a password. There may not be the same security level required simply for our USE of the data to determine, for instance, how the web pages might be changed depending on what information may be stored in the data base.
For instance, we may have a data base record of "courses and lessons" signed up for, or done, by the person. With relatively low security clearance the person, on the basis of the cookie alone, could be routed to the exactly correct page of a lesson he is in the middle of.
The various security levels are NOT established by these words, but only that there is probably a need for different levels of security here and that the connection between the cookie and the data base is governed by the security considerations.
The vital target here is to draft a proposed "Cookie Connection Policy" that lays out the mechanics of what we expect to do and to state our confirmation that this is feasible, and in fact has been tested as workable. This would involve some form of working database and working cookie, on a test basis, to see that we can move forward with a larger application of the use of the cookies.
The IC is to draft such a policy for Karl's approval, then publish that Policy in our Policy Section.
These targets are all assigned to the person in charge of the area, as decided above.
Operating Target #1: Actually create the first cookie script and install it one one page. (That is, a "cookie" can be active for only one page, or all pages in a web site. This Target involves installing a cookie that is active on one page only and demonstrates, merely, that our cookie procedure is working.
Operating Target #2: Design a "message to Karl Loren" form that captures the information posted to that form and then transfers that information to the data base where there must be a "search function" to see if this person is already in the data base. If the person is not in the data base, then the new information would be used to create a new record, still marked however, as "pending" and awaiting a human review to make it a permanent part of the data base. If there is some question, the information should be placed in a temporary location for human review. If it appears that the information pertains to a person already in the data base, then it would again be placed in a temporary location pending human review as to whether there should be any updating of the data base.
The database information is the senior information. Although the person, himself, can change that information, even this change is held in a pending location until a human can review it and allow the change to become permanent.
Even then the program should allow "old" information to be stored, with the date, in an archive so that it can be brought up and looked at again.
Note that actual changes in SOME portions of the data base are within the control of the person himself, but it should not be automatic to make those changes on the basis of information contained in a message form.
|Tables Of Contents With Full Details: Page Title, Comment and Date Last Modified|
|Alphabetical List Of All Company Policies||Table Of Data in Title Order||Staff Assignments showing titles||Programs & Projects In Title Order||Table of Notes In Title Order|
|Policies In Order Of Last Modified||Data In Order of Last Modified||Staff Assignments showing date last modified||Programs & Projects In Order of Last Modified||Table of Notes In Order Date Last Modified|