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

131–140 of 270 posts

Re: Handling cookies is a minefield

#131

Post by treflop »

maxwellg wrote: post #107

Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…

At work, whoever designed our setup put the staging and dev environments on the same domain and the entire massive company has adopted this pattern.

What a colossal mistake.

Re: Handling cookies is a minefield

#132

Post by NBJack »

teaearlgraycold wrote: post #130
maxwellg wrote: post #107

Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…

Using the path field is a code smell

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

Re: Handling cookies is a minefield

#133

Post by preisschild »

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

Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?

Re: Handling cookies is a minefield

#134

Post by HappMacDonald »

kevincox wrote: post #119
draw_down wrote: post #111

Earlier quoted context omitted.

Yeah, isn’t that how you represent a list of values? (Or maybe better to say a collection, not sure if ordering is preserved)

But if the attributes are exactly the same then the cookies replace each other. So this isn't a general mechanism for representing a list. Not to mention that the way to delete a cookie is sending a replacement cookie that expires in the past. How are you supposed to delete the right cookie here?

Is there a way for JS to see the attributes for each value? Because presumably setting an expire time in the past and iterating over every used set of attributes would get the job done to delete the cookie. Iterating over all possible (plausible?) attributes may also work, but knowing the specific attributes set would narrow that list of erasing writes to issue.

Re: Handling cookies is a minefield

#135

Post by IgorPartola »

Cookies need to die. Their only legitimate use is with for which we have the Authentication header. Having a standard way to authenticate into a website in a browser would be amazing, just too bad that Basic and Digest auth wasn’t good enough at the time.

As a bonus we could get Persona-style passwordless future.

Re: Handling cookies is a minefield

#136

Post by HappMacDonald »

preisschild wrote: post #133
littlestymaar wrote: post #80

Earlier quoted context omitted.

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

Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?

I recall in the Elm community there was a lot of hooplah around the package system aligning too much with a single repo provider (github) so that might be one disincentive there.

Re: Handling cookies is a minefield

#137

Post by maxwellg »

kevincox wrote: post #119
draw_down wrote: post #111

Earlier quoted context omitted.

Yeah, isn’t that how you represent a list of values? (Or maybe better to say a collection, not sure if ordering is preserved)

But if the attributes are exactly the same then the cookies replace each other. So this isn't a general mechanism for representing a list. Not to mention that the way to delete a cookie is sending a replacement cookie that expires in the past. How are you supposed to delete the right cookie here?

And the worst is that you need to exactly match the domain and path semantics in order to delete the cookie! Domain is easy enough because there are only two options - available to subdomain and not available to subdomain. But if you have a cookie with the `/path` set and you don't know what value was used, you literally cannot delete that cookie from JS or the backend. You need to either pop open devtools and look at the path or ask the end user to clear all cookies.

Re: Handling cookies is a minefield

#138

Post by azornathogron »

preisschild wrote: post #133
littlestymaar wrote: post #80

Earlier quoted context omitted.

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

Why not do it like go does and use the git hosting domain as a prefix (like github.com/org/project)?

It doesn't have to be git either - a few version control systems are supported. See https://go.dev/ref/mod#vcs

And it doesn't have to be the direct domain+path of the repository, it can be some URL where you put a metadata file that points to the source repo.

Re: Handling cookies is a minefield

#139

Post by teaearlgraycold »

NBJack wrote: post #132
teaearlgraycold wrote: post #130

Earlier quoted context omitted.

Using the path field is a code smell

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

For modern applications you’ll have better ways to maintain state. As shown they cause trouble in practice. Cookies should be used sparingly.

Re: Handling cookies is a minefield

#140

Post by wdr1 »

IgorPartola wrote: post #135

Cookies need to die. Their only legitimate use is with for which we have the Authentication header. Having a standard way to authenticate into a website in a browser would be amazing, just too bad that Basic and Digest auth wasn’t good enough at the time. As a bonus we could get Persona-style passwordless future.

Why are first-party cookies bad?
Post reply on HN