Cannot pay via europsl.eu: "Session expired"
Categories
(Core :: Networking: Cookies, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox96 | --- | disabled |
People
(Reporter: giul.mus, Unassigned)
References
Details
(Whiteboard: [necko-triaged])
I am unable to purchase tickets on Trenitalia.com, the Italian national train service, when paying by credit card: I am redirected to a payment processor (europsl.eu) where I can enter my details, but upon submitting the form I get an error saying "Session expired". This has been occurring for months, maybe more than a year.
I tested this on Nightly (89) with and without privacy.resistFingerprinting, as well as on Release without privacy.resistFingerprinting.
Making this bug private but not security, as conversation may involve private info.
Thank you for the report.
Is your credit card being charged? Or can you reproduce this multiple times without being charged?
I also suggest reaching out to trenitalia to make them aware of the issue.
If there's a way to reproduce this without having to pay? For example, does going to the payment website and cancelling the request also cause this error?
I can reproduce this without being charged. In fact, I can reproduce this using wrong credit card info (eg. using a credit card that I previously saved but with the wrong CVV).
I don't think Trenitalia is responsible for this. I looked at the network tab and when submitting the credit card form I'm redirected to paye.netsgroup.com, then 3ds.sia.eu, then back to the error page on europsl.eu. Also, paying on Trenitalia with eg. PayPal works correctly, so the cookie handling on their side should be ok.
So the error is the redirect from 3ds.sia.eu to europsl.eu ?
I assume you're filing the bug because this works with other browsers?
The error occurs somewhere in the payment process, but yeah I think cookies are being lost in one of the redirects. I'll try recording HAR traces in a min and see if something changes.
Yes, I can pay correctly with Chrome.
This seems to be caused by lax-by-default.
You can fix it by setting the network.cookie.sameSite.laxByDefault
pref to false
Indeed, toggling the config works. (I'm having trouble interpreting the HAR traces since at one point the authentication flow is different, but disabling SameSite=Lax restores the correct behaviour.)
I wrote a quick message on the sia.eu contact form explaining the issue and linking to this bug, what now?
I think it's up to the site developers to fix this.
Comment 8•3 years ago
|
||
In comment 4 the reporter said Chrome worked, but by that date Chrome had already been doing laxByDefault
for six months. If laxByDefault is the problem then they must be treating Firefox differently from Chrome.
Comment 9•3 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)
I think it's up to the site developers to fix this.
Do you know if anybody reached out to the site developers about this issue?
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
Do you know if anybody reached out to the site developers about this issue?
Not to my knowledge.
(In reply to Daniel Veditz [:dveditz] from comment #8)
In comment 4 the reporter said Chrome worked, but by that date Chrome had already been doing
laxByDefault
for six months. If laxByDefault is the problem then they must be treating Firefox differently from Chrome.
It's possible this site triggers yet another corner case bug in our sameSiteLax implementation.
Comment 12•3 years ago
|
||
marking as disabled for fx96 since we set sameSite.laxByDefault and sameSite.noneRequiresSecure to false via a pref flip
Comment 13•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
We won't be shipping samesitelax by default, so all of this breakage bug can be closed: Bug 1617609
Description
•