If I'm not mistaken, that had nothing to do with SQL injection. The fnid basically was the authenticator that allowed a person to edit a page, regardless of who was logged in.
What about other HN-powered Arc sites? Are they vulnerable as well? I won't name names, because I'm guessing they are indeed vulnerable.
With hindsight, do you still feel fnids are a good way to go? They present an obvious bottleneck in that the server has to remember many closures for a period of time as opposed to having each client remember their share. I know you drastically reduced the use of fnids some time ago. I wonder if the remainder are a vestige that's OK to live with because life's too short, or there's fundamentally a strong argument for them I'm missing.
Sometimes these closures have more stuff in them than you could conveniently put in a url. For example, they might refer to another closure describing what to do next. When you try to do something that requires you to be logged in, for example, you're given the login page, with a fnid referring to a closure describing what you were in the middle of doing. That's why after logging in you're able to continue doing whatever you were doing.
Agreed. How about making the fnid a signed cache of often used environment variables(instead of a random string), which could also be looked up via a more time consuming method if needed. Depends really on your traffic profile how much data could reasonably and cost-effectively be cached, but it could be a very sizable portion saved by retrofitting the current method.
If I'm not mistaken, that had nothing to do with SQL injection. The fnid basically was the authenticator that allowed a person to edit a page, regardless of who was logged in.
What about other HN-powered Arc sites? Are they vulnerable as well? I won't name names, because I'm guessing they are indeed vulnerable.
Edit: Yes, they are.