1. If your script sends a session id, everyone who visit the script would get a session id.

Answers are reversed to make it a little easier.

3. Usually the session id is sent throgh the answer http header as a cookie. It is designed to be a 32 byte random number, that makes a hijack of someone elses session more difficult. Then when a user progresser through the site the user sends back the 32 byte number to mark a valid session. So when the script receives a sessionnumber it should not send a new sessioncookie. The received cookie is set up to compare to sessiondata stored on the server usually in a tmp-file.

2. The session file should just hold a user_id, so if the session-tmp-file exists on a particular session the user_id could be retrieved through the file.

Also if you don't want to have a sessionfile you could hold the session information in the db.

Dear JanneVee,
Thank you so much -- just clarifying that every person gets a sessionid really smoothed things out for me. I really appreciate it.

It is easier to work with if everyone who comes to the script gets it but it is a design thing. It can also be designed the other way a valid login would receive a session that is logged in. Update: Check out Joosts reply.

1. Does everyone that comes to the site get a sessionid? Or only people that are logged in?

   Depends on your code :-) But in general I think that most session mechanisms give a session to everybody that visits some "dynamic page" (i.e. a CGI script or Apache handler). Mainly because it's easier that way:

   # somewhere at the start of some handler of CGI script...
   
   my $session  = CGI::Session->new("driver:File", $query, {Directory=>'/
   +tmp'});
   
   if (my $user = $session->param('user')) {
      # user is already logged in...
   }
   elsif (my $user = get_user($query->param('user'),$query->param('passwo
   +rd'))) {
      # store newly logged in user in session
      $session->param('user',$user);
   }
   
          
   # somewhere else
   
   print $session->header( -some => 'value' );
   # instead of $query->header.
   [download]

   Instead of having to check for as session id and a valid username and password combination, and maybe even more request params just to initialize the session object. Besides, sessions can be handy even if a user is not logged in.

2. You do not want to "check the cookies"; you already have a session - see code example above, just store the valid username or user object in the session when the user logs in, and then you can retrieve the user name/object directly from the session afterwards.

3. A session id is just some hard to guess string, that can be passed to the user agent (browser) - usually set as a cookies, but sometimes it is part of the URL.

   A session id identifies a sepecific session - that is, every visitor gets a unique session, in which the programmer can store data about that visitor.

   The session itself is NOT stored in the visitor's browser but on the server (i.e. in a database or file), only the session id is passed to the user.

   Good session modules make it hard to guess a session id by generating one from some semi-random function.