On Wed, Jan 14, 2009 at 3:41 AM, Lyle <webmas...@cosmicperl.com> wrote: > > Runs the risk of the session ID being found, but I guess if I verify the > cookie and IP address...
I think the risk of the session ID (cookie) hijacking is the same either way. So, whether they are forced to a login page as a formality (with their credentials already filled in) it would be the same thing. I don't think you can tie cookies to IP addresses. Some users may be behind firewalls, accessing the internet from clustered HTTP proxies. There might be a way to associate those users with a block of addresses. You could create a (somewhat complicated) algorithm where you give them a cookie via https. Then, every 5 minutes (or 5 days) redirect them to that HTTPS URL to check if they have that cookie, update your server-side session information to indicate it's been checked, and then redirect back to the non-HTTPS URL they were really going to, detect that they were just securely validated, and generate a new cookie/sessionID. That would be relatively transparent to the end user and invalidate hijacked cookies. The time limit could be a fixed period of time, and an inactivity time. It depends on how sensitive your site is. Once every 12 hours, or once after 1 hour of inactivity(?). I think that would be effective. I haven't done it myself. I've been thinking about it. Mark ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################