[ic] Lost cart on checkout to SSL server - new session ID created?

Mike Heins interchange-users@interchange.redhat.com
Thu Aug 23 21:31:44 2001


Quoting Terese Elbring (atlantis@belowsealevel.org):
> Hello,
> 
> I was losing my cart contents every time I attempted to check out using 
> our SSL server.  Every time I accessed the SSL server, I was assigned a 
> new session ID.  I tried all possible solutions listed in the various 
> threads here, with no success.  
> 
> I turned on debugging and added some statements to bin/interchange to try 
> to figure out what was happening.
> 
> Long story short, I commented out line 1895 (init_session();) in 
> bin/interchange and everything seems to be working properly now. My 
> question is, have I broken the script in some way that I have not yet 
> discovered?  What might the ramifications of this change be?  Thanks for 
> your time, code snippet follows.

I think you fixed something, not broke it.

> 
> --------- CODE SNIP ---------
> 
> if(! $Vend::CookieID) {
> 	if( is_retired($sessionid) ) {
> 		new_session();
> 		last RESOLVEID;
> 	}
> 	my $compare_host	= $CGI::secure
> 						? ($Vend::Session->{shost})
> 						: ($Vend::Session->{ohost});
> 
> 	if(! $compare_host) {
> 		new_session($seed) unless $CGI::secure;
> #		init_session();
> 		$Vend::Session->{shost} = $CGI::remote_addr;
> 	}
> 	elsif ($compare_host ne $CGI::remote_addr) {
> 		new_session($seed);
> 		init_session();
> 	}
> 

CVS annotation says this line of code was added July 18, but I don't think
that would be correct. I will look at previous versions and see where
it appeared.

The basic idea is to allow one IP address to talk per session, and allow
separate IPs for secure and non-secure (as when you are behind a proxy
in HTTP but not in HTTPS).

Interchange can tolerate almost anything if it has a cookie, and
theoretically should allow one attempt per session to make the
transition between non-secure and secure. It should then try and
set a cookie on the secure side and be OK. 

I think we should do an analysis of diffferent scenarios to try
and fully characterize where sessions are lost and not lost. We may
not be able to fix the worst scenario, which is:

	1. No cookies enabled.
	2. Differing secure and non-secure server domains.
	3. Differing IP addresses on client for HTTP and HTTPS.
	4. WideOpen not set.

but we should be able to characterize what goes wrong where.

If I ever get enough time to do this, I will. But someone who
is interested in having differing secure/non-secure domains would
be more motivated than me. 8-)

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

I have a cop friend who thinks he ought be able to give a new ticket;
"too dumb for conditions".