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

XSRF cookie expiration issues #865

Open
bdarnell opened this issue Aug 4, 2013 · 4 comments
Open

XSRF cookie expiration issues #865

bdarnell opened this issue Aug 4, 2013 · 4 comments
Labels

Comments

@bdarnell
Copy link
Member

bdarnell commented Aug 4, 2013

The xsrf cookie is not refreshed gracefully when it expires. Form-based applications will usually be OK since they will request a page with a fresh token before any form submission, but long-lived AJAXy pages can have trouble if a session crosses the 30-day boundary. There should be some way to refresh the token before it expires.

Additionally, the cache expiration of any page that includes xsrf_form_html should not be greater than the remaining time on the xsrf cookie.

Discussion: https://groups.google.com/forum/#!searchin/python-tornado/xsrf/python-tornado/1aN84IYC7h8/cW9-J9JbxcUJ

@bdarnell bdarnell added the web label Jul 16, 2014
@z0u
Copy link

z0u commented Oct 5, 2015

This affects me too: I'm writing an AJAX application, and the only time the XSRF cookie gets set is when the user logs in. But at that point _current_user is None, so the _xsrf cookie is set to expire with the browser session. I needed to override xsrf_token in my login handler to set the expiry to the same time as my user session cookie:

    @property
    def xsrf_token(self):
        token = super().xsrf_token
        self.set_cookie( '_xsrf', token, expires_days=30)
        return token

@z0u
Copy link

z0u commented Oct 5, 2015

... Or should I be calling xsrf_token for every GET request, so that it gets refreshed?

@bdarnell
Copy link
Member Author

bdarnell commented Oct 6, 2015

I think the original idea was that you'd delay the initial creation of the xsrf_token until the user had logged in. I'm not sure why it sets a session-scoped cookie when there is no user, instead of just being an error or using the same 30-day expiration. (Maybe it was a gesture towards privacy, so there were no long-term cookies on anonymous users? But browser sessions are longer than they used to be so I'm not sure that session-scoped cookies ever make sense any more). Even if that was the original idea, though, it's not really correct since login forms need XSRF protection too.

The current system is really designed for traditional HTML forms, and it's not a great fit for modern javascript apps. I'm not sure what the right design for that environment is. The simplest workaround I've used is to make GET requests (periodically and after any failure) just to refresh the xsrf_token.

bdarnell added a commit to bdarnell/tornado that referenced this issue Feb 1, 2023
This feature is more invasive than using the samesite cookie attribute
but does not provide additional protection, so it is no longer
something that we should recommend.

Now that this feature is deprecated, the open issues related to it
will not be fixed (however, I intend to keep the current code around
indefinitely; there are no plans to remove it).

Closes tornadoweb#865
Closes tornadoweb#2573
Closes tornadoweb#3026
@bdarnell
Copy link
Member Author

bdarnell commented Feb 2, 2023

With the introduction of SameSite cookies, Tornado's xsrf_cookies system is obsolete. I intend to deprecate it which means that issues like this one will go unfixed (I do not intend to delete the feature entirely, though). Feedback is welcome in #3226.

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

No branches or pull requests

2 participants