Apache::ASP
<% Web Applications with Apache & mod_perl %>
  INTRO
  INSTALL
  CONFIG
  SYNTAX
  EVENTS
  OBJECTS
  SSI
% SESSIONS
  XML/XSLT
  CGI
  PERLSCRIPT
  STYLE GUIDE
  FAQ
  TUNING
  CREDITS
  SUPPORT
  SITES USING
  TESTIMONIALS
  RESOURCES
  TODO
  CHANGES
  LICENSE

  EXAMPLES

Powered by Apache::ASP
Powered by ModPerl and Apache
Powered by Perl
SESSIONS
Cookies are used by default for user $Session support ( see OBJECTS ). In order to track a web user and associate server side data with that client, the web server sets, and the web client returns a 32 byte session id identifier cookie. This implementation is very secure and may be used in secure HTTPS transactions, and made stronger with SecureSession and ParanoidSession settings (see CONFIG ).
However good cookies are for this kind of persistent state management between HTTP requests, they have long been under fire for security risks associated with JavaScript security exploits and privacy abuse by large data tracking companies.
Because of these reasons, web users will sometimes turn off their cookies, rendering normal ASP session implementations powerless, resulting in a new $Session generated every request. This is not good for ASP style sessions.

Cookieless Sessions

 *** See WARNING Below ***
So we now have more ways to track sessions with the SessionQuery* CONFIG settings, that allow a web developer to embed the session id in URL query strings when use of cookies is denied. The implementations work such that if a user has cookies turned on, then cookies will be used, but for those users with cookies turned off, the session ids will be parsed into document URLs.
The first and easiest method that a web developer may use to implement cookieless sessions are with SessionQueryParse* directives which enable Apache::ASP to the parse the session id into document URLs on the fly. Because this is resource inefficient, there is also the SessionQuery* directives that may be used with the $Server->URL($url,\%params) method to generate custom URLs with the session id in its query string.
To see an example of these cookieless sessions in action, check out the ./site/eg/session_query_parse.asp example.
 *** WARNING ***
If you do use these methods, then be VERY CAREFUL of linking offsite from a page that was accessed with a session id in a query string. This is because this session id will show up in the HTTP_REFERER logs of the linked to site, and a malicious hacker could use this information to compromise the security of your site's $Sessions, even if these are run under a secure web server.
In order to shake a session id off an HTTP_REFERER for a link taking a user offsite, you must point that link to a redirect page that will redirect a user, like so:
 <% 
    # "cross site scripting bug" prevention
    my $sanitized_url = 
	$Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
 %>
 <html>
 <head>
 <meta http-equiv=refresh content='0;URL=<%=$sanitized_url%>'>
 </head>
 <body>	
	Redirecting you offsite to 
	<a href=<%=$sanitized_url%> >here</a>...
 </body>
 </html>
Because the web browser visits a real page before being redirected with the <meta> tag, the HTTP_REFERER will be set to this page. Just be sure to not link to this page with a session id in its query string.
Unfortunately a simple $Response->Redirect() will not work here, because the web browser will keep the HTTP_REFERER of the original web page if only a normal redirect is used.