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

181–190 of 270 posts

Re: Handling cookies is a minefield

#181

Post by anonfordays »

teaearlgraycold wrote: post #158
treflop wrote: post #131

Earlier quoted context omitted.

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.

For the juniors reading this, here's what you do: Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

Re: Handling cookies is a minefield

#182

Post by matsemann »

Go and failing to parse http headers correctly should become a meme at some point.

One issue we had was the reverse proxy inserting headers about the origin of the request to the server behind. Like ip, ip city lookup etc. And that parsed through a service written in go that just crashed whenever the city had a Norwegians letter in it, took ages to understand why some of our (luckily only internal) services didn't work for coworkers working from Røros for instance. And that was again not the fault of the Go software, but how the stdlib handled it.

Re: Handling cookies is a minefield

#183

Post by teaearlgraycold »

anonfordays wrote: post #181
teaearlgraycold wrote: post #158

Earlier quoted context omitted.

For the juniors reading this, here's what you do: Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

Ah yes if you use a CNAME that would work. You know better than me.

Re: Handling cookies is a minefield

#185

Post by bvrmn »

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…

> if you store session data on the server, identify the user using the Authorization header.

And by what miracle browser would send Authorization header? Who sets it? For which domain it could be set?

Re: Handling cookies is a minefield

#186

Post by mcfedr »

anonfordays wrote: post #181
teaearlgraycold wrote: post #158

Earlier quoted context omitted.

For the juniors reading this, here's what you do: Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

The reason not to do that is that dev.example.com can set cookies on example.com and other envs can see them.

Re: Handling cookies is a minefield

#187

Post by vbezhenar »

mu53 wrote: post #172
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.

They are not the only place to store tokens. You can store tokens with localStorage for JS-heavy website, in fact plenty of websites do that. It's not as secure, but acceptable. Another alternative is to "store" token in URL, it was widely used in Java for some reason (jsessionid parameter).

Re: Handling cookies is a minefield

#188

Post by bvrmn »

seandoe wrote: post #160
baggy_trough wrote: post #144

Earlier quoted context omitted.

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

I think they mean storing an identifier in local or session storage and then sending it in the header.

Identifier in local storage could be stolen by 3rd party JavaScript. Anybody who wants to use local storage for sensitive information should read why there is a httpOnly cookie attribute.

Re: Handling cookies is a minefield

#189

Post by NegativeLatency »

There’s a nasty bug in the python cookie parser, cookies after a cookie with quotes will be dropped: https://github.com/python/cpython/pull/113663

Zoom or some other website our customers use was writing a cookie with quotes that would break the site. Amazingly hard to reproduce and debug.

Re: Handling cookies is a minefield

#190

Post by thayne »

anonfordays wrote: post #181
teaearlgraycold wrote: post #158

Earlier quoted context omitted.

For the juniors reading this, here's what you do: Buy a second domain, ideally using the same TLD as your production domain (some firewalls and filters will be prejudiced against specific TLDs). Mimic the subdomains exactly as they are in production for staging/dev.

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

That only works if you (and any third party code that might run on such a domain) are completely consistent about always specifying the domain as one of your subdomains whenever you set a cookie.

And if your marketing/SEO/business people are ok with having something like "prod" as a subdomain for all your production web pages.

Post reply on HN