Posted by ctclibby on 07/04/06 11:50

Mike wrote:
[snip]
>
> This is one way to do it. Storing all the users details to sessions
> when they log in is another way. What would be best??

Best is a consideration of what you are trying to accomplish. Cookies
are viewed by some as security problems. Well, if you put security
stuff in cookies, guess what -> security problems.

Some folks are so paraniod that they don't allow cookies. Go figure.

A cookie is a snippet of data that is stored on YOUR computer with some
sort of infomation in it. Since you are creating the application that
stores the cookie, you control the information that is placed into the
cookie. Most of the time cookies are a index into some db that has
MORE infomation about that last session. Cookies expire automagically.
You can set the expiration time. Out of curiosity I looked at some of
the ones that exist on my box and found that some wouldn't expire until
2059 ( hmmm, wonder if I will still be breathing? 100+ YO )

Ok, so you probably knew all that and I lost some skin on my finger
tips just typing it.

Here is the 'it depends' part. If you are trying to track where a
logged in user is going or has gone, a database is probably the best
bet. You could set up a 'progress' table and update that data when
your logged in user moves from page to page. Note that when the user
moves, you also need to check that they are indeed logged in and valid.
With this sort of setup in place, you now have a static path of steps
that need to happen to deal with a user. Since PHP manages session and
session_id()'s just fine, that would be one of the database fields.
Page name could be another. Your security model is now between your
server and that logged in user. Session id's are pretty much unique
and can NOT be seen by another user on a different box. Well, that
other user gets their own session id, but without knowing other session
id's, you can't do anything about it. Go ahead, try and guess one?

If you are concerned about security between the boxes, you might look
at https ( secure http ) as data is en-crypted/de-crypted at the server
and the client box and can not be 'read' on the wire. You have to jump
additional hoops to make this work proper, but if it is important that
your customers/users are secure, go jump hoops.

Sorry, back to page to page memory. If something happens and the user
is disconnected, ( network down, windoz restart ... etc [ Guess which
happens more often?] ) the user only has to log back in, then the
application fetches the page ( or last page ) visited and we then can
continue. When the user is done, they need to logout. Everything is
then zero'd or brought to the first static step of the process.

Assume the worst. Turn off cookies on your test box, then deal with
logging in and what ever your application is. Log in from another box,
see how your code deals with it. Log out and see what is left over
that you need to deal with. Check your /tmp folder for session_id's
and give them a look. Test, test and test again. Don't worry, it is
fun now isn't it?

my $0.02 worth.

todh

[Back to original message]