You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Eric Bellotti <er...@summitmedianetwork.com> on 2001/03/03 01:11:18 UTC

Apache::ASP Sessions + mod_ssl + ParanoidSessions

Is it possible that when "paranoid sessions" are enabled in Apache::ASP
under mod_ssl, sessions get occasionally dropped?  Not a big deal though. =)

EB



Re: Apache::ASP Sessions + mod_ssl + ParanoidSessions

Posted by Joshua Chamas <jo...@chamas.com>.
Eric Bellotti wrote:
> 
> Is it possible that when "paranoid sessions" are enabled in Apache::ASP
> under mod_ssl, sessions get occasionally dropped?  Not a big deal though. =)
> 

Not likely, but if a paranoid sessions security check fails, 
you'll get a "[security] hacker guessed ..." warning in the 
apache error_log, see this bit of code from Apache::ASP:

		    if(defined($state_ua) and $state_ua ne $asp->{'ua'}) {
			$asp->Log("[security] hacker guessed id $id; ".
				  "user-agent ($asp->{'ua'}) does not match ($state_ua); ".
				  "destroying session & establishing new session id"
				  );
			$state->Init();
			undef $state;
			goto NEW_SESSION_ID;	

There might be other reasons for the session-id cookie getting dropped,
especially for IE browsers. ( painful lessons I've learned recently )
These reasons have nothing to do with SSL.

When IE opens a new window, it may create this window in a "new process".
Occasionally a new IE process will not have the same temporary cookies,
as the old process/window.  This is documented somewhere in the MS 
knowledge base with the only work around being to use permanent cookies.

Another real work-around is to make sure your web app does not create
new windows during the course of its execution.  The bug in the knowledge
base FAQ indicates that the real problem is new framesets, so you may
be all right if your new windows don't use framesets.  

I could enable this perm session cookie feature automatically for Apache::ASP, 
with a config like SessionCookiePermanent, and just set to to expire in one 
year or something.  The ASP session will timeout in SessionTimeout minutes
anyway at the server.  But because this radically changes the notion of a 
session,it would have to be a new config, and not a default.

Another reason could be that some IE versions seem to have a 20 cookie limit,
after which some cookies will be dropped.  If your application is setting
too many cookies, then you might get this behavior after the application
is running for a while and sets that many cookies.

I have not yet seen an instance of Netscape dropping cookies, but
I imagine it could if you set a cookie that it too long, as there
is some limit in size to its cookies like 1024 or 4096 bytes
last I heard.

-- Josh

_________________________________________________________________
Joshua Chamas			        Chamas Enterprises Inc.
NodeWorks >> free web link monitoring	Huntington Beach, CA  USA 
http://www.nodeworks.com                1-714-625-4051