This one is on my last nerve.
1) Click on post.
2) Think about writing up a response.
3) Go do something.
4) Wait ten minutes.
5) Write up a response and hit "submit."
6) "Unknown or expired link."
7) roll back, roll forward, and hope you can ctrl-c what you wrote rather than have it vanish into the aether.
8) refresh link.
9) ctrl v if you're lucky.
10) make the comment you wanted to make in step (5).
If you're going to time it out, could you write what I wrote into cache and give me a place to resubmit? I'm sure it has something to do with your structure changing when there's a comment, but it's like playing raquetball in a minefield.
Same here, so much so it is unconscious now. The habit has formed after years of comments on forums, reddit, and emails that may or may not save as drafts, etc.
Not a good thing. This has actually been pretty good to me lately. There are underlying memory causes, which we can address to an extent, but the other approach would be a save-draft option. I just looked into ways to improve the browser cache and found Lazarus. I wonder if anyone has tried it?
This feels more like a server-side bug than a client one. Checking the source of the page, I saw this: <input type=hidden name="fnid" value="qQcI2u8r4K"> Is this an field to protect against CSRF? Is the server-side bit of info to check this just dropped over time?
Yes, the fnids are the culprit, and they are user-specific continuation functions. There's a rich history of discussion about them on HN. Aside from engineering our way out of them, we can extend the number that can be cached before being culled, or we can decrease the instances of them. We can do both. They are over utilized on Hubski. In my early days, I would generate them willy-nilly, now it's my goal to wind them down to a minimum. I'll bump up the number, and start picking some low hanging fruit.
Hoping that's not a security hole if I spoof a random fnid that belongs to someone else... Wouldn't it make more sense to couple the storage time of the functions to a specified timeout? Or alternatively, couple one ID to a page, so you don't generate one for each comment for each view? As is, it seems like a 10x increase in traffic would mean a 10x decrease in the time before the fnids expire. It might cause memory issues, but that could be easily fixed by firing up more servers (Not sure what your opinion is on The Cloud)
https://news.ycombinator.com/item?id=639976 Some of the fnids do have timeouts, and that's one of a number of ways to alleviate this. We are currently "in The Cloud", on a Ubuntu server at Digital Ocean. We used to be on Linode, which has great service, but DO has SSD, and that has huge advantages with Hubski's unusual architecture.Hoping that's not a security hole if I spoof a random fnid that belongs to someone else...
Wouldn't it make more sense to couple the storage time of the functions to a specified timeout?
Both awesome and worrisome. No post from pg on there, did they patch HN (Slash how did they) to fix the security hole? Does hubski have the same fix applied? Dunno if increasing the length of the fnid / cookie would help if your PRNG has been compromised...
Yeah, really impressive. Not sure about HN, but we use the Arc3 rand-string. pg did respond. I'm still looking into what else might have been a part of it.