[ic] DIrty dirty hack... can i get some feedback?

Andrew McBeath interchange-users@interchange.redhat.com
Wed Oct 3 19:27:00 2001


Ok, I know this is far from the greatest idea I've ever had,  but I 
wouldnt mind your guys thoughts on this:

I'm just the latest in a long line of people to run into the old SSL, 
different domains, and disappearing carts problem.

Yes, I am aware (and leaning towards) other solutions which remove the 
session change rather than dealing with it, but I'm just thinking about 
the problem and it's cause. You are always going to get the session 
switch when jumping to the secure server (by design/definition of what a 
session is) yeah?  But...the session data, particular the cart contents, 
_is_ stored by interchange temporarily.

First Question:  Am I right in thinking that Interchange has the 
capability to load this session data if fed the right session ID?  The 
non-SSL session ID is already being passed...whats to stop you looking 
up that data?  Having looked at the internals, Interchange uses the 
current session ID regardless of what ID you passed it.  Is this by 
design?  And was this changed? Because from what I've seen in the mail 
archives it makes sense (considering the IpHead, IpQuad, and related 
directives, and their usage) that you used to be able to pass a session 
ID in the string and, depending on the config directives used, 
Interchange would allow you to load that session's data.  Is that right? 
or am I way off the mark?

I tried a quick experiment in that I started a session, put an item in 
my cart, went to the checkout, and verified there was no items in my 
cart.  I then opened the session file for each of the sessions I just 
started  (non-SSL and SSL), copied the 'main'=>[ ... ] block (in the 
carts section) from the non-SSL to the SSL session file.  Take a guess 
at what happened when I hit refresh in my browser...

So... the ability to transfer your cart (and every last little bit of 
data about your session) between sessions is there and, from an initial 
poke around, is actually (or once was) built in to Interchange.

Anyway, someone must have followed this line of thought before and 
here's my question:

If you are going to transfer session data like this, what problems are 
looming in the background, and assuming it can be done with reasonable 
security (i.e. not vulnerable to passing random session id's in the 
query string for example)...I feel it's worth the $125 US each customer 
is going to save not having to buy a certificate from Thawte. 

What do you guys reckon about this?

Regards,

Andrew McBeath