I am not sure if I follow completely. How do you verify that user who the
user says he/she is?
I log into your web-site as memberA. You kindly leave me a delicious cookie
with my username stored in it. Maybe even my password (I hope not!). Now,
I know that another member, memberB, has special rights to your site. What
is stopping me from editting the cookie to memberB's username and hijacking
their account? And if you do store the password information in the
cookie...you are letting each user be compromised either as the cookie is
flung through the Internet ether, or minimally on their own computer where
someone else can easily access the cookies.
With sessionID, you have an ID and information that is checksum'd. We keep
that sessionID in a DB once a user has successfully logged in. Whenever I
check the sessionID I know they have already logged in -- on top of that,
there is no really useful information in the cookie that might compromise
security. (Plus, the checksum ensures that one is tampering with the
cookie.) But you do keep username, userlevel information within the session
information stored on your local DB -- where is reasonably safe from prying
eyes.
If I wanted to delete a user and ensure they immediately lost all access, it
is rather trivial to go through all active sessions in the db, see if the
user I am deleting matches the username in the session information, and if
so delete the session record.
:
: * User logs in.
: * Site Admin decides to delete the user.
: * In our stateless servers, the user_id is invalidated
: immediately.
: * Next request from User, he's implicitly logged out,
: because the user_id
: is verified on every request.
:
: In the case of a session-based server, you have to delete
: the user and
: invalidate any sessions which the user owns.
:
