You could use a session specific get parameter. A trick is to use md5 to hash session specific data to get a fairly unique session specific key and use that as the session parameter.

Since http is stateless there is really no good universal way to handle session management. You have to pick the lesser of the evils depending on your application. Besides cookies:

• You could use fat links containing a session id. This would require dynamically generated pages.
• If you can set up your page using form buttons for the links you can put a session id in a hidden field
• You could track sessions by IP address, but this creates problems when your potential visitors are sharing an ip address through a proxy server
• If using basic user authentication, you can associate sessions with $ENV{REMOTE_USER}.

There may be other tricks out there too. Look on CPAN for CGI:Session. The readme file has a decent discussion on this. Though I can't personally vouch for the module - I downloaded but never tried it out - it may be just what you need.

Only the first two options mentioned by hangon would work.
IP addresses can be shared by multiple users using the same host and therefore will not serve as a unique session id.
The userid (retrieved with $ENV{REMOTE_USER}) is no good either because multiple users could share a userid and logon concurrently. Example: company has a subscription on a web magazine and multiple employees can view pages using the company userid.

I have to respectfully disagree with varian. Any of the options can work depending on your requirements. IP logging may be good enough if you don't expect your users to be on the same host. You could also try refining this option with a combination of IP and remote port. The user id will work if you require each user to have their own account. Granted, you probably could not prevent two people from sharing an account without your knowledge.

In addition, my first two options can also present problems. Fat urls can pose problems for users trying to bookmark a page. Using a form may not be workable for your page layout.

The point is that none of the available options is perfect - they all have pitfalls. You need to decide which option will work best for your application. You could also try a combination of methods. On one site I use a combination of javascript, cookies and IP/port logging with server side testing. If nothing works the user gets sessionless access with reduced functionality. Many e-commerce sites also use a combination of methods. Amazon.com for example uses a complex technique involving cookies, fat URLs and redirects.

You could use fat links containing a session id. This would require dynamically generated pages.

No it would not. If you do not stick the sessionid in the query, but instead at the beginning of the path and the use relative URLs for whatever's supposed to know the session you don't have to tweak the HTML in any way and the browser will send the session ID along just fine:

http://www.your.site.com/ID:168F7E8A45EE/the/path/page.pl?the=real+par
+ameters
[download]

instead of

http://www.your.site.com/the/path/page.pl?ID=168F7E8A45EE&the=real+par
+ameters
[download]

What you have to do in this case is to tell your web server to extract the session ID from the path before it maps the path to directories and files on disk. I believe it's easy for Apache (though can't give you detailed instructions), for MS IIS you might (provided that they did not change the interface too much) use something like mine SessionID.dll.

Jenda


Support Denmark! Defend the free world!