Session data wiped after return from 3D Secure page

Hi @simonp303,

Does this happen when on all consent status?

Or only when functional cookies are accepted for example,

If PayPal as service is enabled under Integrations -> Services, and if PayPal is a payment option, maybe try disabling it.

Try safe mode, under settings as well.

And if you can, could you post your URL. So we can have a look?

regards Aert

Hi @aahulsebos it is not PayPal it is Sage Pay that we are using. This uses 3D Secure (which takes you to your banks 3D Secure page, eg: https://secure4.arcot.com/acspage/cap) to authorise payment before returning to the site. That page is unique per bank I believe. The site this is on is: https://www.nationaltheatrewales.org and it relates to “quick donations” which can be started from the homepage under Quick Donate.

I have tried “safe mode” and it still failed.

Thanks.

@simonp303 with session you mean a PHP session? Is the user session ID stored in a cookie or appended to the URL?

Does the cookie or URL variable get removed when the user returns?

@rogierlankhorst yes a PHP session, specifically:
$_SESSION[tessitura-session][id] which is what I need to process a function after successful 3DS clearance.

On returning to the site that whole session “tessitura-session” block is wiped.

When I disable the plugin, it is not wiped and the code runs as expected.

As far as I know the actual session data is stored on the server, but the session Id linking the user to that data in a cookie or in the url, which is why I’m interested what method is used in your case. Is a cookie used for the storage of the session Id?

Just simple PHP session handling:
$_SESSION['tessitura-session']['id'] = $sessionId;

Where $sessionId is a string etc…

If you navigate away from the site and come back the session remains. It is only when going off to the 3D Secure pages that it seems to clear.

• This reply was modified 4 years, 3 months ago by Simon Pollard.

@rogierlankhorst

Hi Roger, I am just inserting myself here (Simon and I have been trying to debug this together)

To check my understanding, you think the issue could be that the PHPSESSID cookie is getting removed as we pass back onto the site from 3DS. This would make a lot of sense and explain why we are seeing what we are seeing.

Is there a way of making this cookie “necessary” in the plugin so it never gets cleared. I can’t see it in any of the options pages in the Plugin Dashboard.

Thanks for your help on this.

Ian

Hi @ianbrown,

It was a thought, but thinking about it, I don’t think that’s where the issue is. In the cookie banner script there is no code to clear cookies, and safe mode didn’t make a difference. Safe mode disables the cookie blocker.

I’d like to try to narrow it down step by step. First, I’d like to check the front-end javascript, by testing without it.

Can you enable both safe mode, and add this code as mu-plugin (has to be a mu-plugin, otherwise it’s too late in the process). This will remove the cookiebanner code altogether.

function cmplz_my_filter_site_needs_cookiewarning( $cookiewarning_required
) {
    return false;
}
add_filter( 'cmplz_site_needs_cookiewarning', 'cmplz_my_filter_site_needs_cookiewarning' );

If it works with this code, please try the same with safe mode disabled.

Another possible cause might be used headers. I came across this thread:
https://stackoverflow.com/questions/1130533/ie8-loses-my-session-data-when-using-payment-gateway

So based on that thread some additional questions:

– Do you have this issue in all browsers?
– As there is a jquery error detection feature only active for admins which sends a header, do you have this issue both as admin and as lower level user?

@rogierlankhorst

Thank you for this we are still looking into this as it appears to be happening in Chrome but not in Firefox DE

Thank you for your help so far

Hi @ianbrown,

Could it be you have additional privacy settings in Chrome via native settings or an extension that might cause this behavior?

regards Aert

@aahulsebos Thank you for the suggestion

We had looked into that a bit yesterday. We have spent more time on it today, and it looks like it has been the Chrome 80 update to the SameSite settings for the session cookie that has caused it.

We have done a fix this afternoon and it looks to be working.

@rogierlankhorst Thank you for your help too. It wasn’t your plugin causing the issue in the end, but we really appreciate the time you have spent on it.

Hi @ianbrown,

Thanks for letting us know!

regards Aert

No problem, you guys have been awesome ??