3 ms·

This is largely correct. Each reply form includes a hidden input field with the name 'fnid' in their form. Many other pages include a parameter with the same na

This is largely correct. Each reply form includes a hidden input field with the name 'fnid' in their form. Many other pages include a parameter with the same name. This is the unique identifier of a closure that's associated with the page you're on. These closures are deleted after X time, at which point requests from that page can no longer be handled correctly. Yes, obviously it would be great if X were increased. But doing so would require an increase in server resources or a significant change in the way HN's backend works; neither of these options is free. That is the reason why things are this way. This is an old debate. See, for example: https://github.com/HackerNews/HN/issues/11 https://github.com/HackerNews/HN/issues/11

grey-area 12y ago
fnids are evil, they just need to drop them and respond properly to posts without them. What more state needs to be recorded which is not already encoded in a POST reply request {user:n,post:7651593,text:'xxx'}? The solution should be pretty straightforward: Reply forms -> Remove fnid, authenticate on post, add CSRF Flag links -> Remove fnid, authenticate on post, add CSRF They already check authentication on these actions anyway as you'll see if you try upvote links from another user without login, all that would be required would be to use CSRF instead of these closures to handle posts like this - the closures are not a workable solution on a large site, and I'd contend are dangerous on a small site - they throw away a lot of the advantages of HTTP for no appreciable gains. Things like the more link are particularly pointless, they could just use something like: https://news.ycombinator.com/x?fnid=xxx -> https://news.ycombinator.com/news/2 This would change over time like the existing home page, but there's no reason for a simple GET request like this to expire.
- 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 ago
    A 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 ago
      You'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.

grey-area 12y ago

fnids are evil, they just need to drop them and respond properly to posts without them. What more state needs to be recorded which is not already encoded in a POST reply request {user:n,post:7651593,text:'xxx'}? The solution should be pretty straightforward: Reply forms -> Remove fnid, authenticate on post, add CSRF Flag links -> Remove fnid, authenticate on post, add CSRF They already check authentication on these actions anyway as you'll see if you try upvote links from another user without login, all that would be required would be to use CSRF instead of these closures to handle posts like this - the closures are not a workable solution on a large site, and I'd contend are dangerous on a small site - they throw away a lot of the advantages of HTTP for no appreciable gains. Things like the more link are particularly pointless, they could just use something like: https://news.ycombinator.com/x?fnid=xxx -> https://news.ycombinator.com/news/2 This would change over time like the existing home page, but there's no reason for a simple GET request like this to expire.

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 ago
  A 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 ago
    You'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.