Live data from Hacker News

Handling cookies is a minefield

grayduck.mn

191–200 of 270 posts

Re: Handling cookies is a minefield

#191

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?

We have *.example.dev, *.example.qa, *.example.com for development, staging/qa and production. Works well and we haven't had any issues with cookies.

Re: Handling cookies is a minefield

#194

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

How does it prevent squatting in any way?

Re: Handling cookies is a minefield

#195
post #97

Earlier quoted context omitted.

A sibling comment talked about “UwU names”. Not sure exactly if they are referring to “tokio” or something else. But if it’s tokio, they might find this informative: > I enjoyed visiting Tokio (Tokyo) the city and I liked the "io" suffix and how it plays w/ Mio as well. I don't know... naming is hard so I didn't spend too much time thinking about it. https://www.reddit.com/r/rust/comments/d3ld9z/comment/f03lnm... Fro…

Just want to point out that location names are used for codenames because they cannot be trademarked Big tech uses them instead of wasting legal time and money having to clear a new name that's temporary or non-public. Changing the name to Tokio removes this benefit and still leaves it disconnected from its purpose.

> location names are used for codenames because they cannot be trademarked

I don't think that's the case. Amazon, Nokia as some counterexamples.

Re: Handling cookies is a minefield

#196
post #172

Earlier quoted context omitted.

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

To expand on the "not as secure" comment: local storage is accessible to every JS that runs in the context of the page. This includes anything loaded into the page via like tracking or cookie consent services.

Re: Handling cookies is a minefield

#197
post #84

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

I do agree that people will assume xyz/xyz is more authoriative than some-org/xyz, but I think there is benefit to knowing that everything under xyz/* has a single owner. The current approach is to name companion crates like xyz_abc but someone else could come along with xyz_def and it's not immediately obvious that xyz_abc has the same owner as xyz but xyz_def does not.

This is a completely different topic though, and I think there's interest in shipping something like that.

That's the main problem with “just add namespace FFS” discussions that come every other week: everyone has its own vision of what namespace should look like and what they are meant for, but nobody has ever taken the time to write an RFC with supporting arguments. In fact, people bring this mostly in ways that are related to name squatting (like right here) even though that's not a problem namespace can solve in the first place. It's magical thinking at its finest.

Re: Handling cookies is a minefield

#198
post #124

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

There are problems it does solve though. It’s incomprehensible that we get so many new package managers that fail to learn from the bajillion that came before.

It actually learned and that's what makes cargo as good as it is (arguably the best of all that came before, and a source of inspiration for the ones that came after).

But its authors rightly concluded that it's useless to expect to prevent name squatting by any technical mean!

Re: Handling cookies is a minefield

#199

Earlier quoted context omitted.

Server can store session state

Server side session state for more than authentication is way worse than "code smell." It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!

I add some products in phone. Then I login to desktop later for modification and order. Cart is empty. That's engineering smell. A really bad one.
Post reply on HN