• A user authenticates on my site.
  • The user selects items to purchase and is sent via curl call (see below) to a payment site.
  • The payment site does its thing and returns to my site via a callback URL I posted to it. I assume it is also a curl call, since data is posted back.
  • Upon return, if less than 120 seconds has elapsed since the user originally authenticated on my site, the user's authenticated session is resumed (good).
  • Upon return, if more than 120 seconds has elapsed since the user originally authenticated on my site, a new session is started (bad). The user is effectively signed out.

This behavior is 100% consistent. I can call the 3rd party site and return any number of times within the 120 second window after authentication and the authenticated session is always resumed. But as soon as I return after 120 seconds, a new session is started.

It doesn't matter whether I authenticate, immediately go to the 3rd party site, and then wait there 120 seconds, or if I authenticate, wait at my site 120 seconds, and then go to the 3rd party site, if the return to my site happens more than 120 seconds after original authentication on my site, a new session is started instead of resuming the authenticated session.

What could cause this? Some kind of timer setting, cache setting, etc.? Maybe a module? I'm asking before I begin the process of disabling modules one by one.

My curl call:

$ch = curl_init('https://commerce.cashnet.com/404Handler/pageredirpost.aspx');
curl_setopt($ch, CURLOPT_POSTFIELDS, $data); // $data includes the callback URL

AN EARLIER VERSION OF THE PROBLEM DESCRIPTION talked about session ids changing, information passed, etc. I removed all that to simplify, as it got too long to leave it in. The original set of comments below are based on that earlier description, which is why they don't seem to make sense now. But they were helpful in guiding me to further testing that revealed the 120-second issue.

1 Answer 1


A callback from a credit card processing site to your Drupal server should never have the same session as the paying customer. If it does, then you have a problem.

But I'm not sure that's what you're saying - you are vague when you talk about session ID. If you mean that the paying customer's session ID shouldn't change when your server sends the payment information to the credit card processing site then receives the response, then you are correct. But why even mention credit card processing and posting back in this case, as it's not very relevant? If the paying customer's session ID changes, then you need to investigate how the session ID is invalidated and what your session timeout is. Perhaps your callback is invalidating a cache tag that forces a new session to be generated for that user.

  • Thanks, anonymous. I have edited my explanation in an effort to make it more clear. I'm not sure what you mean in your "never" statement. Hoping my edits will clarify. Oct 28, 2020 at 3:22
  • 1
    What I mean by "never" is that the session should be unique to that user - if an external site has the session credentials that means the external site can do anything the authenticated user (paying customer) can do - this would be a session hijack vulnerability.
    – anonymous
    Oct 28, 2020 at 3:58
  • 3
    Another thing that could be going wrong with your session is that http and https have separate sessions - if your paying customer is accessing your site via https but some of the page content is served via http, then the https session will be broken and a new session created. For payment purposes, the entire page should be https (images, css, js, advertisements, etc should all be served via https) so as not to break the session.
    – anonymous
    Oct 28, 2020 at 4:00
  • Thanks again for your kind responses, anonymous. I'll check the http/https issue. I tried sending the session ID to the 3rd party site only as a test. It isn't something I'd do normally. If there's a way to force Drupal to resume the authenticated session, that would solve the problem, but I have no idea how to do that. Oct 28, 2020 at 15:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.