>>! In T84960#950866, @Anomie wrote:
> The point isn't to make the tokens last **longer** than the session. [...] You won't get a 5-minute token and be able to extend it indefinitely by re-requesting it, or get a 5-minute token but then requesting it again after 4 minutes gives you the same token that will expire in only 1 minute, or [..]

I understand that. My point is that it seems useless to embed tokens in the html that client-side JavaScript (from core, extensions or gadgets) cannot reliably use because by design it will always expire after a few minutes. Similarly it seems useless that VisualEditor and other uses of tokens almost always have to make two or three round trips just to make a write action. Right now its three. 1) Failed write action for token expired, 2) get new token, 3) Re-try write again. Not only does it make two more http requests then desired, it also transmits a potentially large amount of data to the server multiple times. We could cut this back to 2 requests by making the client-side aware of how long the tokens are valid for. While that is better, it is imho not good enough.

Two facts:

* In the past we made the decision to embed the user.tokens module in the page because we saw performance problems with the client-side having to request a token for write actions by JavaScript (for e.g. watch star click, or VE edit save).
* In the past we made the observation that saving content with VisualEditor is a performance bottle neck, that we worked hard to cut down. Due to this token expiration problem, we basically nullified all that effort by having to submit everything twice for a lot of users.

As such, I would recommend strongly that we **figure out a feasible way to allow MediaWiki frontend to perform write actions with the API without needing to fetch a token over a separate HTTP request**. The client's cookie is already authority enough to request as many tokens as it wants during the session, so in theory it seems really stupid that we need a token at all when making a write action. Clearly whatever origin can make or forge one request, can also forge the other. Raising the bar might make sense to just make it a tiny bit harder, but I'm questioning whether that's worth it.

From this perspective, this change was a significant regression as both of these two expectations are no longer met by the system.

The naive approach of not making the tokens change every request is understandably not acceptable from a security perspective because of "BREACH"-type reflection attacks. The only option I left then is to continue issuing new tokens each page view but have those tokens (that are embedded in the page) be valid for the entire duration of a page view (or otherwise, at least for an hour or so).