search

widelands / widelands-website

The widelands website is a bunch of applications for the django web framework. It is developed in the open here.
https://www.widelands.org/
GNU General Public License v2.0
15 stars 10 forks source link

CSRF verification failed. Request aborted. #188

Open gunchleoc opened 5 years ago

gunchleoc commented 5 years ago

I have spot a bug:

CSRF verification failed. Request aborted. when I was searching from the website (simple search). But I couldn't reproduce it until today.

And today I have noticed two things:

  1. CSRF token is sent
  2. Between opening the tab homepage and searching something I have logged into Widelands on other tab.

Ad 1.: I have checked from FireFox debug engine that I have sent CSRF token (payload here): csrfmiddlewaretoken 0semFHKn6pOtaQ6FnLhYebyORox30xJvx8IeuW6blGKkjdfhzy1Y724xteBSXEIL q map+generat section Forum

Ad 2.: I have checked on other browser (opera) that the bug can be reproduced there.

So try reproducing:

  1. Log off the Widelands website
  2. Close web browser (clear all cache, settings, sessions, whatever?)
  3. Open web browser and go to Widelands webpage
  4. Copy the page / open any link within it ON SECOND TAB!
  5. Log in there (click login and pass credentials)
  6. Try to search anything through simple-search.

Going around it I have one idea, why it is that: The session on server side for anonymous user is no-longer true (after login), so static data (CSRF token) is not valid any more. But I am not sure here, I have never spot such a problem.

Imported from Launchpad using lp2gh.

gunchleoc commented 5 years ago

(by franku) Thanks for your bug report.

I can confirm this with these steps (Opera):

  1. Log out
  2. Close additional Browser tabs where the website is shown, leave 1 tab with the website open.
  3. Open the website in an additional tab and login here
  4. Switch to the other tab (showing not logged in) and try to search with the form in the navigation bar

The problem is that the csrf-token cookie is updated in step 3 (login). Sending a request through the browsers tab (showing not logged in) uses the old csrf value then.

I guess the underlying problem is that the view used in the navigation bar uses a redirect.

gunchleoc commented 5 years ago

(by w-aaaaa) Good google search and I spot a link: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona/The_implementor_s_guide/Problems_integrating_with_CRSF_protection#The_problem_with_Persona

Hope it can be the solution! :)

gunchleoc commented 5 years ago

(by franku) Thanks for the link, which describes the problem very well :)

The proposed solution looks good to me. I am working currently on other things, so this bug has to wait for fixing.