Strange behavior of CSRF tokens with a low csrf_expire (3.1.2)

Well, no ... actually because of a bug that was fixed in 3.1.3, which also contains a lot of other security patches. You should've updated first.

There's a few bugs that slipped through in that release, I'm waiting for 3.1.4 to see if it's stable.

Cons: 2 know regressions, with known fixes that are easy to do even by hand.
Pros: Other bugfixes aside - 5 security patches, one of them fixing the bug that I told you about.

The choice should be obvious, but I hope you at least checked to see if you're affected by the vulnerabilities in question.

Not just the approach, the entire idea is bad.

Knowingly submitting a request that you know will fail is obviously bad, but while tracking the token by expiry time would be more clean, it is still not a bullet-proof approach. In any case, whatever you do will amount to the same effect as setting a huge expiry time.

But the real problem is that you're going out of your way to disable a security feature. Often overlooked, but CSRF also prevents against replay attacks, and against someone physically impersonating careless users who leave their browsers open. What you're trying to do nullifies those protections and you'll now always refill the form with a valid token.

I don't follow. One of these two will happen;

1. User submits the form, sees a 403, clicks back and refreshes the page. User submits and it goes through.
2. User submits the form, 403 is handled, corrected, and the request goes through.

1. User confirms that it is them that spent a long time on the page and indeed they are submitting it.
2. You assume what the user wants, and that it is the same user you are assisting.

The first is a bad user experience. If they use the back button and not a link on the 403 page they have to refresh the page again or they will see another 403.

This is not uncommon. It may be mildly annoying, but not at all unreasonable ... not everything can magically work.
The CSRF token is a self-contained session; an authentication mechanism. Would you auto-create and authorize sessions?

They aren't going to understand the message, why they need a token, why leaving a page open causes this to occur, etc.

They don't need to even read to word "token", let alone try to understand it. You can change the message to say they've spent too much time on the page before submitting and that's it.

Either way, security is more important than whether they understand the message or not.

In either case if the user is in front of the computer (being theirs or not) they will gain access.

The problem isn't the legitimate user, but impersonators.

The token is not stored in the form. It's saved as a property on the main app class (js) and passed to conduits each request. Every response includes the new token which is handed back to the app class for future use.

When talking about a form being submitted, you can safely assume I mean the payload being sent.