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

251–260 of 270 posts

Re: Handling cookies is a minefield

#251

Post by rcxdude »

jmull wrote: post #236

> ...tragedy of following Postel's Law. The "law" is: "Be liberal in what you accept, and conservative in what you send." But here the problem is caused by being liberal in what is sent while being more conservative in what is accepted. It's using invalid characters in the cookie value, which not everything can handle. Following Postel's law would have avoided the problem.

Postel's law is the main reason why there are so many cases where something is being liberal in what it sends. It's a natural approach when trying to enter into an existing ecosystem, but when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations if the protocol, because something that is non-compliant but happens to work with some portion of the ecosystem won't get discovered until it's already prevalent enough it now needs to be accounted for by everyone, complexifying the 'real' spec and increasing the likelihood someone else messes up what they send.

Re: Handling cookies is a minefield

#252

Post by dekhn »

bvrmn wrote: post #193
dekhn wrote: post #104

Earlier quoted context omitted.

Native desktop development.

Aka unindexable, unsearchable, violation access error mess.

Indexing doesn't really work well if cookies are involved. And if indexing doesn't work, then searching doesn't.

Web pages fail for me (javascript or whatever) far more often then I get a "violation access error" from my desktop programs.

Re: Handling cookies is a minefield

#253

Post by IgorPartola »

bvrmn wrote: post #234
IgorPartola wrote: post #224

Earlier quoted context omitted.

Take a look at how basic auth is implemented in browsers today. Now imagine expanding it to (a) provide a much nicer and somewhat customizable UI for entering your credentials and (b) using proper encryption.

What about redirects from other sites, should Authorization behave like cookies? My point is cookies are ok for auth, and you basically should invent same things with another header.

That header was invented for this exact purpose before cookies were invented. It has wide browser support and semantics that make sense. Moreover, the design specifically includes provisions for additional auth mechanisms (basic and digest being the two most widely used). The downside was that the UI for setting that header was ugly.

Your comments remind me of the people who didn’t get HTTP verbs and wanted to use POST for everything before rediscovering REST.

Re: Handling cookies is a minefield

#254

Post by solatic »

Author started with throwing the results of JSON.stringify into a cookie, and I was surprised that his issue wasn't just that someone had thrown a semicolon into the JSON that was being stringified.

Most of the headaches around cookies seem to be around people trying to get them to work with arbitrary user input. Don't do that. Stick with fixed-length alphanumeric ASCII strings (the kind you use for auth tokens) and you'll be fine.

Re: Handling cookies is a minefield

#255

Post by bvrmn »

IgorPartola wrote: post #253
bvrmn wrote: post #234

Earlier quoted context omitted.

What about redirects from other sites, should Authorization behave like cookies? My point is cookies are ok for auth, and you basically should invent same things with another header.

That header was invented for this exact purpose before cookies were invented. It has wide browser support and semantics that make sense. Moreover, the design specifically includes provisions for additional auth mechanisms (basic and digest being the two most widely used). The downside was that the UI for setting that header was ugly. Your comments remind me of the people who didn’t get HTTP verbs and wanted to use PO…

> and semantics that make sense

A paradise for CSRF.

> Your comments remind me of the people who didn’t get HTTP verbs and wanted to use POST for everything before rediscovering REST.

REST is not about HTTP methods if you read the paper. It's curious you have a direct map between HTTP methods and REST verbs as your mental model.

Re: Handling cookies is a minefield

#256

Post by bvrmn »

dekhn wrote: post #252
bvrmn wrote: post #193

Earlier quoted context omitted.

Aka unindexable, unsearchable, violation access error mess.

Indexing doesn't really work well if cookies are involved. And if indexing doesn't work, then searching doesn't. Web pages fail for me (javascript or whatever) far more often then I get a "violation access error" from my desktop programs.

Good luck to have HN as a native app and get a huge diverse community around :P

Re: Handling cookies is a minefield

#257

Post by tacone »

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

I am using path to wire my http only cookies to be sent only to /api not in assets/html requests. The cookie will eventually contain a JWT token I do use as an access token. Consequently I will probably wire my refresh cookie only to be sent to /api/refresh-token and not in other requests.

The client won't get to decide which cookie to send where.

Looks like a good pattern to me.

Re: Handling cookies is a minefield

#258

Post by marcosdumay »

ndusart wrote: post #247
marcosdumay wrote: post #230

Earlier quoted context omitted.

No, when you create a protocol define exactly what you need what is optional and what is an error, and stick to that. Being liberal on what you accept is a path for disaster.

You changed the problem. Postel's law is not about writing the protocol but implementing it. Sure, protocol should be designed to be as specific as possible but unfortunately these are not always defined up to that point for any good or bad reasons, and we generally are at best just in the implementation side and cannot influence the writing of the protocol, so the Postel's law is the best we can apply to avoid havin…

From wikipedia:

> The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.

Re: Handling cookies is a minefield

#259

Post by withinboredom »

0x073 wrote: post #246
withinboredom wrote: post #209

Earlier quoted context omitted.

Since when can you trust js?

Big websites use js and if they leak most of the time it's not a js issue. I think the distrust of js is a personal issue.

I mean, anyone can open devtools and change the code to do whatever ... or install an extension that does it. So, since when can you guarantee that a browser client will actually do what you program it to do? In my experience, you can't guarantee anything on the client -- since forever. I was asking when/if that changed. I don't see why you would make that a personal attack?

Re: Handling cookies is a minefield

#260

Post by 0xbadcafebee »

pjc50 wrote: post #215
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,…

Anarchy is the price to pay for not having a monopoly dictate a nice clean spec which they can force-deprecate whenever they want.

> a monopoly dictate a nice clean spec which they can force-deprecate whenever they want

We already have that at times. Apple forced a change to cert expiration that nobody else wanted, but everyone had to pick up as a result. Google regularly forces new specs, and then decides "actually we don't like it now" and deprecates them, which others then have to do as well. Virtually all of the web today is defined by the 3 major browser vendors.

If all these "specs" actually had versions, and our clients and servers had ways to just serve features as requested, then we could have 20 million features and versions, but nothing would break.

Example with cookies: if the cookie spec itself was versioned, then the server could advertise the old version spec, clients could ask for it, and the server could serve it. Then later if there's a new version of the spec, again, new clients could ask for it, and the server could serve it. So both old and new clients get the latest feature they support. You don't have to worry about backwards compatibility because both client and server can pin versions of specs and pick and choose. You can make radical changes to specs to fix persistent issues (without worrying about backwards compatibility) while simultaneously not breaking old stuff.

But we can't do that, because "cookies" aren't their own spec with their own versions, and clients and servers have no way of requesting or advertising versions of specs/sub-specs.

You could actually implement this on top of HTTP/1.1:

  1. Make cookies their own spec, and version it
  2. Add a new request header: "Cookie-Spec-Ver-Req: [range]"
  3. If there's no request header, the spec is version 1.0
  4. If Server sees a request header, it determines if it supports it
  5. Server replies with "Cookie-Spec-Ver: " of what it supports, based on the request
  6. Client receives the spec it requested and handles it accordingly
Do that for every weird "feature" delivered over HTTP, and suddenly we can both have backwards-compatibility and new features, and everything is supported, and we can move forward without breaking or obsoleting things.

This actually makes sense from a programmatic standpoint, because "Cookies" are implemented as their own "Spec" in a program anyway, as a class that has to handle every version of how cookies work. So you might as well make it explicit, and have 5 different classes (one per version), and make a new object from the class matching the version you want. This way you have less convoluted logic and don't have regressions when you change things for a new version.

Post reply on HN