Handling cookies is a minefield • Hacker News Board

Re: Handling cookies is a minefield

#71

Post by mdaniel » Thu, Nov 21, 2024, 8:25 PM UTC

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…

> 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

Re: Handling cookies is a minefield

#72

Post by [deleted] » Thu, Nov 21, 2024, 8:26 PM UTC

jeffreyrogers wrote: post #49

About 10 years ago I implemented cookie based sessions for a project I was working on. I had a terrible time debugging why auth was working in Safari but not Chrome (or vice-versa, can't remember). Turned out that one of the browsers just wouldn't set cookies if they didn't have the right format, and I wasn't doing anything particularly weird, it was a difference of '-' vs '_' if I recall correctly.

[deleted]

Re: Handling cookies is a minefield

#73

Post by mdaniel » Thu, Nov 21, 2024, 8:27 PM UTC

cruffle_duffle wrote: post #15

AshleysBrain wrote: post #12

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.

Definitely don't use "SuperCookie" as that's a thing: https://en.wikipedia.org/wiki/HTTP_cookie#Supercookie

Re: Handling cookies is a minefield

#74

Post by codetrotter » Thu, Nov 21, 2024, 8:28 PM UTC

echelon wrote: post #38

juped wrote: post #7

Earlier quoted context omitted.

De facto standardization by snapping up good names early!

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…

A sibling comment talked about “UwU names”. Not sure exactly if they are referring to “tokio” or something else. But if it’s tokio, they might find this informative:

> I enjoyed visiting Tokio (Tokyo) the city and I liked the "io" suffix and how it plays w/ Mio as well. I don't know... naming is hard so I didn't spend too much time thinking about it.

https://www.reddit.com/r/rust/comments/d3ld9z/comment/f03lnm...

From the original release announcement of tokio on r/rust on Reddit.

And also to the sibling commenter, if tokio is a problematic name to you:

Would either of the following names be equally problematic or not?

- Chicago. Code name for Windows 95, and also the name of a city in the USA. https://en.wikipedia.org/wiki/Development_of_Windows_95 https://en.wikipedia.org/wiki/Chicago

- Oslo. Name of a team working on OpenStack, and also appears in their package names. Oslo is the capital of Norway. https://wiki.openstack.org/wiki/Oslo https://en.wikipedia.org/wiki/Oslo

If yes, why? If no, also why?

Re: Handling cookies is a minefield

#75

Post by mdaniel » Thu, Nov 21, 2024, 8:28 PM UTC

hinkley wrote: post #57

One of the things I’ve always found frustrating about cookies is that you have to do your own encoding instead of the API doing it for you. I’m sure someone somewhere does but too often I’m doing my own urlencode calls.

Encoding is at least solvable, but every browser having their own cookie length versus some standard value makes that some nonsense. Kong actually has a plugin to split (and, of course, recombine) cookies just to work around this

Re: Handling cookies is a minefield

#76

Post by hombre_fatal » Thu, Nov 21, 2024, 8:30 PM UTC

jeffreyrogers wrote: post #49

About 10 years ago I implemented cookie based sessions for a project I was working on. I had a terrible time debugging why auth was working in Safari but not Chrome (or vice-versa, can't remember). Turned out that one of the browsers just wouldn't set cookies if they didn't have the right format, and I wasn't doing anything particularly weird, it was a difference of '-' vs '_' if I recall correctly.

IIRC there is (or was?) a difference in case-sensitivity between Safari and Chrome, maybe with the Set-Cookie header? I've run into something before which stopped me from using camelCase as cookie keys.

Can't seem to find the exact issue from googling it.

Re: Handling cookies is a minefield

#77

Post by mdaniel » Thu, Nov 21, 2024, 8:30 PM UTC

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?

I'm not them, but that 419 pattern in the logs is burned into my adrenaline response: https://duckduckgo.com/?t=ffab&q=nginx+419+cookie+header&ia=...

Re: Handling cookies is a minefield

#78

Post by mdaniel » Thu, Nov 21, 2024, 8:33 PM UTC

AlienRobot wrote: post #41

>everything behaves differently, and it's a miracle that [it] work at all. The web in a nutshell.

Browsers: what it would look like if Postel's Law were somehow made manifest in C++ and also essential to modern life

Re: Handling cookies is a minefield

#79

Post by tyleo » Thu, Nov 21, 2024, 8:34 PM UTC

0xbadcafebee wrote: post #61

Did anyone else notice that the HTTP protocol embeds within it ten-thousand different protocols? Browsers and web servers both "add-on" a ton of functionality, which all have specifications and de-facto specifications, and all of it is delivered through the umbrella of basically one generic "HTTP" protocol. You can't have the client specify what version of these ten-thousand non-specifications it is compatible with,…

Tbh I’ve made peace with this world and I might even enjoy it more than the planned obsolescence one.

Re: Handling cookies is a minefield

#80

Post by littlestymaar » Thu, Nov 21, 2024, 8:36 PM UTC

echelon wrote: post #38

juped wrote: post #7

Earlier quoted context omitted.

De facto standardization by snapping up good names early!

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).