On Tue, Mar 19, 2002 at 10:27:20AM -0800, Wizard wrote: > Ok, I've never developed a sessioning system from scratch, so I have some > questions. This is what I am doing, and I want to know if anyone sees any > problems: > Sessions Database: > 1. Session_key > 2. ip_address (REMOTE_ADDR) > 3. user_name > 4. browser string (HTTP_USER_AGENT) > 5. expires (+20m) > 6. permissions, db_name, etc.
IP addresses are not unique. Many people browse from behind Network Address Translating (NAT) firewalls as well as mega reverse proxies like AOL. In the first case, the IP lookup will succeed, but the username will fail. In the second case, the IP lookup may fail, depending on how the proxying is done. In either case, your system may not work for some number of users. In general, it is not a good idea to pass user_names around in a cookie. While it is true that most people can be identified by the computer they appear to be using, it is not always true. Browser strings are not a great match: even allowing for the existence of 100 different browser types and flavors, you will soon discover many people have the same user agent string. Also, unless all your users use cookies, you may want to pass the session data in the url, which means that some of that information could leak to other sites. The generally accepted method of handling sessions is to generate a unique session id which you identify with the person. The session_id is then associated the rest of the user information, usually in a database. When/if the user logs in, you can either change the state of the session to mark that they have logged in, or generate a different kind of session_id. The session id is propagated to the user either in the url or with cookies. I initially do both and set a flag. The next time I see that session_id, if the flag is set and they returned a cookie, I switch to cookies, otherwise I continue to use the url method. Obviously, in either case, I unset the flag. The need to be able to use both the cookie and url methods pretty much require that when the user logs in, you change the state of the session, rather than generate a completely different kind of session. There are other gotchas. I have written a few emails to this forum on the topic. Perhaps there's an archive somewhere. If you haven't already, read 'Dos and Don'ts of Client Authentication on the Web' at http://www.usenix.org/events/sec01/fu/fu_html/index.html There are now a few CPAN modules to deal with sessions, in addition to many non-Perl solutions. When I first started using them, there were either none publicly available or none that suited my needs so I wrote one. Now there are a few available, some quite similar to my implementation. You can't go too wrong using one of them, unless your needs really are different. Regards -Gyepi Sam
