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

171–180 of 270 posts

Re: Handling cookies is a minefield

#171

Post by kijin »

HappMacDonald wrote: post #134
kevincox wrote: post #119

Earlier quoted context omitted.

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.

No, there isn't. All you get a list of values that are valid for the current page. Same on the server side.

If you're ever in a situation where you need to invalidate all possible instances of a cookie, it's easier to just use a different name.

Re: Handling cookies is a minefield

#172

Post by mu53 »

gweinberg wrote: post #127

I got the impression that almost as soon as they were introduced people thought the only sensible use of cookies is to set an opaque token so the server can recognize the client when it sees it again, and store everything else server side. I don;t understand why it's a problem that the client (in principle) can handle values that the server will never send. Just don't send them, and you don;t have to worry about perp…

Cookies are an antiquated technology. One of the first introduced while the web was still young in the 90s, and they have had a few iterations of bad ideas.

They are the only place to store opaque tokens, so you gotta use them for auth.

Re: Handling cookies is a minefield

#173

Post by dumpsterdiver »

Analemma_ wrote: post #105
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,…

This is also the fault of shit-tastic middleware boxes which block any protocol they don't understand-- because, hey, it's "more secure" to default-fail, right?-- so every new type of application traffic until the end of time has to be tunneled over HTTP if it wants to work over the real Internet.

> middleware boxes which block any protocol they don't understand-- because, hey, it's "more secure" to default-fail, right?

If the intent is to secure something then failing-open will indeed be at odds with that goal. I suspect you’re not implying otherwise, but rather expressing frustration that such providers simply can’t be bothered to put in the work and use security as an excuse.

Re: Handling cookies is a minefield

#174

Post by 0x073 »

withinboredom wrote: post #98
0x073 wrote: post #69

Earlier quoted context omitted.

Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies.

And if I don't want any javascript to see my values, ever? Or how do you handle CSRF?

Httponly cookie is the way, but then you just don't use json as cookie value that is send on every request.

Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.

Re: Handling cookies is a minefield

#176

Post by tigerlily »

That reminds me of the Frog and Toad story about willpower vs eating cookies. Yes, handling cookies is a mine field!

I read the collected stories with my two year old, though I made sure we skipped the scary ones with the Dark Frog. I think the cookies ending was a little over his head, but we had fun taking turns acting out Toad pulling his blankets over his head when Frog tells him it's spring.

Re: Handling cookies is a minefield

#178

Post by magicalhippo »

baggy_trough wrote: post #144
IgorPartola wrote: post #142

Earlier quoted context omitted.

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?

Not a web dev. So do I understand it correctly that it's not so much the server side of this that's the issue, after all the Authorization header contains a nice token, but rather how to safely store the token client side without using cookies?

Re: Handling cookies is a minefield

#179

Post by sureIy »

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…

Seems perfectly reasonable to me?

If you are on /somepath I'd expect to get C as is the most specific value out of all three. All the values are still returned, ordered, which to me is the best of both worlds (path-specific values + knowing the globals)

The only thing I don't like is the magic `document.cookie` setter, but alas that's nearly 30 years old.

Re: Handling cookies is a minefield

#180

Post by hahn-kev »

MBCook wrote: post #165
j16sdiz wrote: post #156

Earlier quoted context omitted.

How about user preference without logging in? Are you suggesting create a trillion throwaway accounts?

What about things like local storage?

If you want to store language preferences then that means you only know client side and you can't serve html in their language
Post reply on HN