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?
Handling cookies is a minefield
191–200 of 270 posts
Re: Handling cookies is a minefield
#192Re: Handling cookies is a minefield
#193Re: Handling cookies is a minefield
#194Earlier 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)?
Re: Handling cookies is a minefield
#195Earlier 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.
I don't think that's the case. Amazon, Nokia as some counterexamples.
Re: Handling cookies is a minefield
#196Earlier 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).
Re: Handling cookies is a minefield
#197Earlier 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.
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
#198Earlier 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.
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
#199Earlier 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!
Re: Handling cookies is a minefield
#200Just dont make them, and dont accept them.