in reply to Re^4: Concern with CGI::Session
in thread Concern with CGI::Session

About the example from the CGI::Session::Tutorial doc. I listed above, it only checks to see if a Cookie name exists or not.
And it will fail if the cookie's value is not a valid current session id. Which is good enough. I like
my $session = CGI::Session->(undef, $cgi, {Directory=>'/tmp'})
better though, since I then don't have to remember what the cookie's name is, and it also handles session ids via param().
That being said, anyone who can create a cookie with the same name can be verified and will be able to view a members area site.
Update: anyone who can create a cookie with the right name and the same VALUE (session id) can do that. These session ids are generated "randomly" and are not easy to guess at all.

Just make sure the sessions time out after some period of inactivity. You can also store the user-agent info in the session and check that for each request (pretty reliable, but not that secure) and/or store the client's IP adress in the session and check it (which will fail for some ISPs, since they rotate IP adresses) but that's about it. If you're really worried about this, you should also worry about people snooping the username/password from the login request. Use SSL and hard to guess session ids (default in CGI::Session).

How can you use CGI::Session to actually check the session id from the cookie to match the one from the database? There is no where in the tutorial or in the cookbook that shows an example how. Ahhhhh I wish I was smart and could figure this stuff out easy.
That's what the new CGI::Session line does. It checks if there is a session with the given id and returns that. if the id is undefined, it gives you a new session. Any data stored in the session object will be stored somewhere for later retrieval. That's all there is to it.

update: you also seem to have missed the fact that $cgi->cookie($name) returns just the cookies value, not a CGI::Cookie object. See the CGI docs