We use a CSRF cookie on all of our forms that send data via HTTP POST. By default, the CSRF cookie out lives the session cookie by 2+ hours, in order to ensure it does not expire for users that still hold a valid session. We do notify users of sessions about to expire and give them the ability to extend it.

Yesterday, I got a report about a bug that prevented someone from logging in. When I investigated, I found that the user had arrived to our login form (which does not start a session until submitted) twelve hours before actually submitting the form. This threw a cryptic 'not authorized to see this page' error from the framework that we use.

I've taken care to make that error more informative for the benefit of someone NOT trying something malicious with provisions for the user to fix the problem.

What is the proper way to handle situations wherein the user has only a certain amount of time to do something before not being able to do it? What I'm considering is just refreshing the page a few minutes before the CSRF cookie expires to prevent it from expiring (or regenerate the token), and stopping that countdown if keyboard / focus events fire to prevent the corner case of reloading on a user while they type. JS is a requirement to be able to use the system, it's just not practical for us to deal with it being disabled.

This isn't a 'typical' timed event, as most users don't know and don't care about CSRF tokens or when they're going to expire. It's not like a quiz page where the user has 30 seconds to answer a question. This should be something the user never sees.

I'm quite certain that I'm not the first person to encounter this scenario, so I'm wondering if there is a standard way of handling it?


3 Answers 3


Since Javascript is required, why not simply do a small AJAX request behind the scenes as the cookie is about to expire to get it refreshed? The user need not know about it (provided it sends almost no data — mobile users shouldn't be surprised by using their data allowance) and the refreshed cookie can be set with the response.

Refreshing the entire page seems overkill, especially if there's a form on the page which might be cleared when it happens.

A bit more here: http://www.bennadel.com/blog/1995-AJAX-Requests-Get-And-Set-Cookies-Like-Any-Other-HTTP-Request.htm

  • I'm going with this, as it is the least Rube Goldbergish way of doing things. I'm taking @dnbrv's fine suggestion of a 'Login permission cookie' error if for some reason the AJAX request fails (user lost Internet during their absence), at which point I hide the form and tell them they should refresh.
    – Tim Post
    Commented Jul 4, 2012 at 14:29

The solution you describe in your question sounds like a winner. Based on your description of the situation, the solution has to reset the countdown without interfering with a user's activities. Thus, a script that refreshes the page & pauses on mouse or keyboard input will fix the problem.

I would add another "feature" to it: display a flash message with a countdown during the last 10 seconds notifying the user of the upcoming refresh just in case they decide to perform the action at the last moment & won't be able to complete it. The message should be something like:

Login permission cookie will expire in X seconds. The page will reload then. Please wait.

I purposefully used "login permission" because the common person doesn't know or care what CSRF is.

  • 1
    "Login permission" is definitely a winner. I was at a loss for a more friendly name. I was thinking "Security token", but some people panic when any kind of notice containing "security" appears.
    – Tim Post
    Commented Jul 4, 2012 at 4:53

When your receive request with expired cookie, make target page issue redirect that would regenerate cookie and repeat exactly same request instead of generating error. Add additional field to this request indicating that it is regeneration request. If it fails again, then user indeed have problem that cannot be solved with regeneration and only then you'll have to display error. This should make process completely transparent to user and not require specific timing to refresh cookie.

  • That would work, however it would require a bit of monkeying around in the core of the framework. The security class is loaded very early on (Codeigniter) , and will halt completely when this is encountered. +1 however as something like what you describe would be the cleanest and most unobtrusive way of dealing with it.
    – Tim Post
    Commented Jul 4, 2012 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.