15 ms·
The fnid is a CSRF token, just with an disadvantageous implementation that leads to a far too short expiry time. I don't know much about the internals of Arc,
by quasque 12y ago
The fnid is a CSRF token, just with an disadvantageous implementation that leads to a far too short expiry time.
I don't know much about the internals of Arc, but maybe it would be possible to serialise the continuation data, combine it with a reasonable expiry time, apply some form of authenticated encryption to this, and supply that as the fnid? And reverse the process - with appropriate integrity checks - when the fnid is submitted. Then you have your state distributed at the client-side instead of all being kept on the server, so it can scale more effectively.
EDIT: Nevermind, just realised that this very suggestion is addressed here, and it's more difficult than I anticipated https://github.com/HackerNews/HN/issues/11#issuecomment-32152432 https://github.com/HackerNews/HN/issues/11#issuecomment-3215...
- grey-area 12y agoA CSRF token doesn't have to be stored in memory on the server like these fnids, you only need a way to verify it like a secret for decoding it. This is a solved problem for many other servers so they could just look at some other implementation of CSRF, or start by getting rid of the many uses of fnid which are not required anyway (they are also used on GET requests). I don't think they should try to serialise fnids, but just get rid of them completely. What state is required for a posted reply other than the three things outlined above + CSRF protection?
- quasque 12y agoYou're right, I was overthinking the solution. I think the most common technique I've seen for generating CSRF token is to compute an HMAC of the immutable request parameters. I'm guessing that's what HN already implements for voting, as the token is dependent on user id and the id of the thing being voted on, and kind of looks like an SHA-1 hash.