in reply to Perl and Cookies

You can set a single cookie with the username and password, delimited somehow, and parse it yourself. Or use something like CGI::Cookie.

BUT

Just to drive it home:

Replies are listed 'Best First'.
Re^2: Perl and Cookies
by pajout (Curate) on Mar 06, 2006 at 09:01 UTC
    Yes, I agree with previous recommendations, but I want to describe my way of session ID creation: I have the stored procedure in my db (PostgreSQL), which generates random text with length specified by argument and checks it's uniqueness against proper column of the session table. The first character could be [a..z] or [A..Z], the others could be [0..9] too. I guess that 10 characters is enough... No secret salt, no digest, but slightly slower when new session ID created.

      That's not a great way to do session IDs. There are a few reasonably reliable ways:

      1. Take a hash of the username, IP address, and date/time of login. This should be unique as long as no one is cheating. ;-)
      2. Use a *sequential* ID in your sessions table. Hash this with the info above and it *will* be unique.
      3. Just use Data::GUID and store the Globally Unique ID (GUID) it generates as your session key. This is, actually, the simplest in my experience. It also guarantees uniquness and avoids the odd chance of hash collisions and such that the former two risk.

      In either case, save only the session ID in a cookie (or, if you prefer {and are willing to do a little extra work}, you can pass it in the URL and not use cookies at all). In the sessions table, store an expiration time; each time you check for a valid session, you can update the expiration (unless, of course, the session has already expired).

      This seems to be the best approach short of implementing some kind of full-featured auth scheme on the server side.

      <-radiant.matrix->
      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
        You'll re-compile the session id to check validity each time, right? You'd need 3 things: username, IP (granted), and login time(granted if stored for use as salt).
        IP and a request-incremented value are good additions- salt to taste.

        But if you only send the session ID, where is the username coming from?

        ad 1/ Can the user establish two sessions at the same time?
        ad 2/ Yes, I'v simplified my table - it has sequential primary key (aka ID) and the session identifier, I named it "token".
        ad 3/ I prefer simple solutions, and when I am able to fully satisfy the requirement with 50 rows of code, I am not using the modules, having thousands rows, potentially with bugs.
        You wrote that my way is not the great, but you did not write why :>))
        In any case, thanks for sharing experience...