in reply to RE: mmmmm .. cookies
in thread mmmmm .. cookies

Cookies can certainly be used as an identification token for authentication and authorization purposes, as long as you remember the golden rule: You must provide a way to timeout a cookie, remove a cookie, and reload the cookie onto a different browser.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: RE: RE: mmmmm .. cookies
by swiftone (Curate) on May 30, 2000 at 17:08 UTC
    Question regarding this:
    On a site that I am preparing for rollout, I am implementing a cookie-based authentication, and rather than what appears to be the "standard" method of returning a cookie for the loginId, and a cookie with a one-way encrypted password, I set a (pseudo)random string in the DB when the user logs in, and send that string to the user as a cookie. As I see it, the differences between the two are:
    • My method involves more DB overhead (an UPDATE with every login)
    • My method does NOT allow more than one client logged in with the same ID at a time.
    • My method lets me be lazier and not learn the various MD5 stuff until I have more time :)
    The DB overhead isn't a problem for quite a while, but are there any other advantages/disadvantages to this that I'm not seeing?