Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handling cookies is a minefield

grayduck.mn

Post reply on HN
Print view View original

81–90 of 270 posts

Re: Handling cookies is a minefield

#81

Post by plorkyeran »

emn13 wrote: post #68
Sohcahtoa82 wrote: post #28

Earlier quoted context omitted.

> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.

And yet the html5 syntax variation survived (with all it's weird now-codified quirks), and the simpler, stricter xhtml died out. I'm not disagreeing with out; it's just that being flexible, even if it's bad for the ecosystem is good for surviving in the ecosystem.

There was a lot of pain and suffering along the way to html5, and html5 is the logical end state of postel's law: every possible sequence of bytes is a valid html5 document with a well-defined parsing, so there is no longer any room to be more liberal in what you accept than what the standard permits (at least so far as parsing the document).

Re: Handling cookies is a minefield

#82

Post by mdaniel »

joshstrange wrote: post #63

> Apple Support Are we sure the website wasn't just broken normally? I kid, a bit, but good lord does Apple _suck_ at websites. Apple Developer and, more often, App Store Connect is broken for no good reason with zero or a confusing error message. Note: I'm typing this on a M3 Max MBP (via a Magic Keyboard and Magic Mouse) with an iPhone 16 Pro and iPad Mini (N-1 version) on the desk next to me with an Apple Watch Se…

But why wouldn't web pages written in ObjC be just awesome and easy to manage?!

https://en.wikipedia.org/wiki/WebObjects

I can still remember when they'd purposefully take down their store page for some godforsaken reason. The mind reels

Re: Handling cookies is a minefield

#83

Post by jdlshore »

TheRealPomax wrote: post #52
recursive wrote: post #17

Earlier quoted context omitted.

None of this explicitly has anything specifically to do with HTML.

It sure doesn't, that was a comment for a completely different post. I have no idea why HN posted this comment on this article instead of the PHP 8.4 article I thought I was commenting on O_o

It’s happened enough that I suspect there’s a rarely-seen race condition somewhere in the Arc code that runs HN.

Re: Handling cookies is a minefield

#84

Post by Macha »

littlestymaar wrote: post #80
echelon wrote: post #38

Earlier quoted context omitted.

Not really. A lot of essential third party Rust crates and projects have "weird" names, eg. "nom", "tokio", etc. You can see that from the list of most downloaded crates [1]. This one just happens to have been owned and maintained by core Rust folks and used in a lot of larger libraries. This is more the exception than the rule. It's a given that you should do due diligence on crates and not just use the first name t…

> Rust crates need namespacing to avoid this and similar problems going forward. It hasn't been implemented despite crowd demanding it on HN for years because it won't solve the problem (namespace squatting is going to replace name squatting and tada! you're back to square one with an extra step).

I do agree that people will assume xyz/xyz is more authoriative than some-org/xyz, but I think there is benefit to knowing that everything under xyz/* has a single owner. The current approach is to name companion crates like xyz_abc but someone else could come along with xyz_def and it's not immediately obvious that xyz_abc has the same owner as xyz but xyz_def does not.

Re: Handling cookies is a minefield

#85

Post by graypegg »

mdaniel wrote: post #71
emn13 wrote: post #62

Earlier quoted context omitted.

However, potentially a localStorage (and sessionStorage!) compatible cookie-replacement api might allow for annotating keys with secure and/or HttpOnly bits? Keeping cookies and localStorage in sync is a hassle anyhow when necessary, so having the apis align a little better would be nice. Not to mention that that would have the advantage of partially heading off an inevitable criticism - that users don't want yet ano…

> and they're server-readable too now, just indirectly. Could you point me to more reading about this? It's the first time I've heard of it

I think they mean that you can always send back the content of a localstorage property with javascript grabbing the value and sending another request back with it in the body. Since the front end is going to run any javascript the server sends it (disregarding adblockers at least), it's sort of a more indirect version of Set-Cookie.

Re: Handling cookies is a minefield

#87

Post by xp84 »

emn13 wrote: post #62
graypegg wrote: post #22

Earlier quoted context omitted.

I think one important use case we have for cookies is "Secure; HttpOnly" cookies. Making a token totally inaccessible from JS, but still letting the client handle the session is a use case that localStorage can't help with. (Even if there's a lot of JWTs in localStorage out there.)

However, potentially a localStorage (and sessionStorage!) compatible cookie-replacement api might allow for annotating keys with secure and/or HttpOnly bits? Keeping cookies and localStorage in sync is a hassle anyhow when necessary, so having the apis align a little better would be nice. Not to mention that that would have the advantage of partially heading off an inevitable criticism - that users don't want yet ano…

I think if I were implementing a webapp from scratch today I'd use one single Session ID cookie, store sessions in Redis (etc) indefinitely (they really aren't that big), and for things meant to be stored/accessed on the frontend (e.g. "has dismissed some dumb popup") just use local storage. Dealing with anything to do with cookies is indeed incredibly painful.

Re: Handling cookies is a minefield

#88

Post by hinkley »

osrec wrote: post #65
hinkley wrote: post #58

Earlier quoted context omitted.

Good way to hit max header length issues. Ask me how I know.

How?

Well you see when a front end developer and a backend developer hate each other very much, they do a special hug and nine days later a 400 request header or cookie too large error is born.

(Seriously though, someone trying to implement breadcrumbs fe-only)

Re: Handling cookies is a minefield

#90

Post by Illniyar »

littlestymaar wrote: post #80
echelon wrote: post #38

Earlier quoted context omitted.

Not really. A lot of essential third party Rust crates and projects have "weird" names, eg. "nom", "tokio", etc. You can see that from the list of most downloaded crates [1]. This one just happens to have been owned and maintained by core Rust folks and used in a lot of larger libraries. This is more the exception than the rule. It's a given that you should do due diligence on crates and not just use the first name t…

> Rust crates need namespacing to avoid this and similar problems going forward. It hasn't been implemented despite crowd demanding it on HN for years because it won't solve the problem (namespace squatting is going to replace name squatting and tada! you're back to square one with an extra step).

Solved the problem almost completely in npm. Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that.

But once you know a namespace is owned by a company or project, you can know that everything under it is legit. Which solves the vast majority of squatting and impersonation problems.

Also you know that everything under "node" for example is part of the language.

Post reply on HN