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

141–150 of 270 posts

Re: Handling cookies is a minefield

#141

Post by eru »

Illniyar wrote: post #90
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).

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"…

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

There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com

Of course, there's no guarantee that https://company.com belongs to the company, but the public has already developed ways of coping with that.

(I specifically suggest doing that only to part of your namespace, because you still want people to be able to upload packages without having to register a domain first.)

Re: Handling cookies is a minefield

#142

Post by IgorPartola »

wdr1 wrote: post #140
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?

They are not bad they just are unnecessary. If your application uses local state, use local storage. If you store session data on the server, identify the user using the Authorization header. Why send arbitrary strings back and forth often with requests that don’t need them. Plus the technology is clearly rotten. They never got namespacing snd expiration right so you can just do weird stuff with them. Also, CSRF wouldn’t be a thing if cookies weren’t. This is like saying “why is finger/gopher/etc. bad?” They are not exactly bad but they are obsolete.

Re: Handling cookies is a minefield

#143

Post by eru »

tyleo wrote: post #79
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.

That was the model that Microsoft used at the height of their power and dominance in the 1990s and 2000s.

Re: Handling cookies is a minefield

#144

Post by baggy_trough »

IgorPartola wrote: post #142
wdr1 wrote: post #140

Earlier quoted context omitted.

Why are first-party cookies bad?

They are not bad they just are unnecessary. If your application uses local state, use local storage. If you store session data on the server, identify the user using the Authorization header. Why send arbitrary strings back and forth often with requests that don’t need them. Plus the technology is clearly rotten. They never got namespacing snd expiration right so you can just do weird stuff with them. Also, CSRF woul…

How would you use the Authorization header to implement server side session data?

Re: Handling cookies is a minefield

#145

Post by anal_reactor »

treflop wrote: post #131
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.

I'm sure this will be replicated in future projects because it's much easier to argue "we're already following this pattern so let's be consistent" than "this pattern is bad and let's not have two ruined projects"

Re: Handling cookies is a minefield

#146

Post by michaeljsmith »

thaumasiotes wrote: post #122
bell-cot wrote: post #36

Earlier quoted context omitted.

His Majesty's English might suggest "biscuit".

What do the British call biscuits? https://chefjar.com/wp-content/uploads/2021/05/popeyes-biscu...

The closest thing is https://en.wikipedia.org/wiki/Scone.

Re: Handling cookies is a minefield

#147

Post by prokopton »

teaearlgraycold wrote: post #139
NBJack wrote: post #132

Earlier quoted context omitted.

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.

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

Re: Handling cookies is a minefield

#148

Post by bpicolo »

prokopton wrote: post #147
teaearlgraycold wrote: post #139

Earlier quoted context omitted.

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

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

Server can store session state

Re: Handling cookies is a minefield

#149

Post by deathanatos »

johnp_ wrote: post #99
deathanatos wrote: post #95

That is a bit of a minefield, I agree… The way around this, as a developer, is URL-safe-base64 encode the value. Then you have a bytes primitive & you can use whatever inner representation your heart desires. But the article does also note that you're not 100% in control, either. (Nor should you be, it is a user agent, after all.) I do wish more UAs opted for "obey the standard" over "bytes and an prayer on the wire"…

> URL-safe-base64 And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.

oh, geez. No, just base64, using the URL safe alphabet. (The obvious 62 characters, and "-_" for the last two.

It's called "urlsafe base64", or some variant, in the languages I work in.

> This encoding may be referred to as "base64url".

https://datatracker.ietf.org/doc/html/rfc4648#section-5

But yeah, it's not base64 followed by a urlencode. It's "just" base64-with-a-different-alphabet.

Re: Handling cookies is a minefield

#150

Post by deathanatos »

Retr0id wrote: post #109
johnp_ wrote: post #99

Earlier quoted context omitted.

> URL-safe-base64 And make sure to specify what exactly you mean by that. base64url-encoding is incompatible with base64+urlencoding in ~3% of cases, which is easily missed during development, but will surely happen in production.

Isn't it a lot more than 3%? I don't think I've heard anyone say url-safe-base64 and actually mean urlencode(base64(x))

… yeah. I assume they're getting that from doing 3/64, but for uniform bytes, you're rolling that 3/64 chance every base64-output-character. (And bytes are hardly uniform, either … TFA's example input of JSON is going to skew towards that format's character set.)
Post reply on HN