Jump to content

SSL Problem: Session ID being reset


aftk2

Recommended Posts

All right, I'll to explain this as best I can.

I've developed a shopping cart with the CakePHP framework. I mention this because it may turn out to be important, although I don't think it's the main problem. Anyway, I'm currently using session to store shopping cart contents. This works throughout the entire site. Finally, I submit the form containing all shipping, billing information and total information to my payment gateway (Cybersource), which is configured to accept the request, either confirm or deny it, and then, upon completion, go back to whatever URL I've configured at Cybersource (there is a spot in Cybersource's admin panel for both a confirm or deny action.)

Well, the good news is that this all works when I'm not in SSL. I'm on my server at http://mysite.com/store/index.php?url=/checkout/confirm and I forward to https://ordertest.cybersourcewhatever.com, it processes the order and redirects a post back to https://mysite.com/store/index.php?url=/checkout/receipt/ (which is where it should go.) This is actually POST, and has to be, because they post variables like 'decision' (which I check to see if the order was accepted or not) and things like 'orderNumber' which I access in the $_POST array and store in the database. This all works fine.

Until I go into SSL.

At this point, both when I'm at https://mysite.com/store/ and https://mysite.mysharedsslprovider.com/store/, the session cart works fine for the entire purchasing process, and then I submit to cybersource, and when it's finished, and I get dumped back to https://mysite.com/ or https://mysite.mysharedsslprovider.com (I'm using a shared certificate which can be accessed at both places, although it gives a warning if I do https://www.mysite.com/store/); at this point, my session is cleared, and I have no products in my cart, and my order process is screwed up, because I'm relying on the contents of my cart to enter items into the database (for the completed order record.) I've checked the HTTP headers, and what's happening is that I'm attempting to set the same cookie all the way through (for session), but upon returning from cybersource's HTTPS server, a new cookie is set, and a new session ID is given.

Is this is a shared SSL problem (this is what I've heard it may be.) Is this a CakePHP problem? A generalized session problem from PHP? Any idea on how I could get around it? I suppose I could pass session ID through the form at that point and try and get it back from cybersource, but since I'm using CakePHP's sesssion abstraction functions that may be difficult. Any thoughts? Please!

Andrew
Link to comment
https://forums.phpfreaks.com/topic/27151-ssl-problem-session-id-being-reset/
Share on other sites

there is no way around it, other than passing the session id via the url, it's to different domains no matter if it's a shared cert or not. Like I said the only way around it is to pass the session id or a hash reference that references the session id! Why can't you just create a secure form on your site and send the payment via a internal socket controlled ssl scripting call, this way they never leave the site.


To answer your response - really? The problem isn't that I don't have access to the session ID when I'm on the other server (the cybersource order.whatever.com server) - the problem is that when I come back to the server, re-visiting the SAME domain I just left - and the cookie was fine while jumping from page to page on that domain - I guess I'm just not sure why jumping to an external domain and then posting back to the originating one would reset the session cookie for the original domain.

As far as your second idea - I had thought about doing this in the past, the problem is that Cybersource makes me include a whole bunch of extra hidden form variables in a script (they generate HOP.php for you, and you include it); I'll have to check out that script, and make sure I'm submitting all of their extra, undocumented variables to them, through Curl or something. Definitely doable, and it might be where I'm heading, but I was hoping to do it as a last resort.

Thanks for the response.

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.