Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with first time checkout as unauthenticated/anonymous user #492

Closed
ThomBreugelmans opened this issue May 27, 2024 · 1 comment · Fixed by #496
Closed

Issues with first time checkout as unauthenticated/anonymous user #492

ThomBreugelmans opened this issue May 27, 2024 · 1 comment · Fixed by #496
Labels

Comments

@ThomBreugelmans
Copy link
Contributor

Describe the bug
If someone tries to checkout on events for the first time without logging in (aka as an anonymous user) they encounter an "Owl no" page. However when pressing the back button to return to the tickets page and trying to checkout again they are able to perform the checkout. Deeper investigation shows that when attempting the checkout there is no XSRF token set, when the error page is shown the token gets generated and set after which the checkout is able to succeed.

To Reproduce
Steps to reproduce the behavior:

  1. Open up a fresh browser, or incognito mode
  2. Go to wisv.ch/events and add a ticket to checkout (for example the membership)
  3. accept the terms and conditions and go to checkout
  4. after getting a owl no page move one page back with the back error
  5. attempt the checkout again which will be successful

Expected behavior
The user should be able to checkout anyway or if logging in is required redirect them to a login page instead of an error.

@ThomBreugelmans
Copy link
Contributor Author

Spring boot apparently only sets the XSRF-TOKEN on requests that modify the state of the server (e.g. no GET), see section 3 in https://www.baeldung.com/spring-security-csrf
This means that an unauthenticated user who has not yet visited the site or ordered something, will not have an XSRF-TOKEN yet. And when they go to checkout they will make their first POST request, which will set their XSRF-TOKEN. However this request will also be rejected with a 403 because they do not have a valid token yet and the endpoint is protected. Though, if they try this again it will succeed as they now have a valid token.

I think the /checkout POST endpoint should not be protected with CSRF as it leads to these current issues, additionally there is no harm done by creating a checkout as it does not harm users (no money gets stolen, nor (personal) details).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant