-
Notifications
You must be signed in to change notification settings - Fork 89
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
What to do in case token expires #5
Comments
In normal case, if token expires js will send a blank value as key. And validation will fail. One possible case if we keep a configurable option (default:
the js will issue a quick xhr to this server and wait for response, but in response header, refreshed cookie will be retrieved and js can then attach tokens with requests. imp: |
#label -> next version, currently validation will fail |
Isn't it insecure to have CSRFProtector disabled for the "get me a new token" XHR call? |
"to get a new token" --> that would be done via cookie+session, not by returning the data directly. So that when the user actually wants to submit his form, the usual process is run (fetch token from cookie, attach to request, post). |
Well thats a good idea, to issue a xhr call to refresh the token few seconds before expiry. But then we need a page that handles such requests without doing any other processing. One of the way would be to issue a xhr to same page (currently open) with some special request parameter, such that backend just issue a token and terminates the connection. The only doubt I have is, token expiry time is 30 minutes. Is it a wise idea to implement this?@chdeliens. |
Indeed, that's what a thought of: issuing a XHR call to the same w/ special params. But then, we have to assume that the ::init() call is made soon enough to avoid any processing on the page. A cleaner integration would be to have a special page dedicated to this purpose of regenerating a token. Regarding the token expiry time, I'm not sure I get it right. Are you afraid that the expiration time of 30 minutes is too high (and I would agree, I think 5 minutes, or even 1 minute would be more secure -- even though we can't possibly get that value because either in session or in domain-only cookie, but we never know what new attack would be possible tomorrow) or that it should be higher so that we don't need to implement to regenerating of the token (bad idea IMO)? |
Yeah thats a concern. But for this library to work properly its needed that |
I think the simplest and best working solution would be to have a longer expiration time. I think something in the order of a few hours is generally good. |
But should we not have a solution for that corner case too? lets say tab was open for hours and cookie expires? |
Well then there’s no problem. Any form is considered lost after several hours of inactivity. All program developers have to employ background ajax refreshment to keep those forms alive.
|
Ok so we just leave it to developer? |
yes. to add a lot of code and complexity for a very rare corner case would ruin the library, not help it. You can create a cookbook for the developers to use in these cases, but adding that to the main codebase is not very wise.
|
totally agree! |
#todo: Create a wiki page, mentioning this case and suggesting possible actions to developers! |
Is it safe to set expire time - At end of session? |
@mithilesh12 yeah |
csrf token has an expiry time. let us assume its 5 minutes. And after loading a page, user did spend 5 minutes somewhere else before making another request.
Now when user makes a request, say he submits a form, the js code fetches the token from cookie before submitting the form. So what need to be done in this case?
Possible solutions:
The text was updated successfully, but these errors were encountered: