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

211–220 of 270 posts

Re: Handling cookies is a minefield

#211

Post by netdevphoenix »

thayne wrote: post #190
anonfordays wrote: post #181

Earlier quoted context omitted.

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.

When was the last time you saw a public website like that? prod.companyname.com websites are extremely rare especially outside tech.

Re: Handling cookies is a minefield

#212

Post by telgareith »

CrimsonRain wrote: post #199
telgareith wrote: post #153

Earlier quoted context omitted.

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.

Thats nothing more than UX/UI.

> In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

- https://en.wikipedia.org/wiki/Code_smell

Re: Handling cookies is a minefield

#213

Post by DonHopkins »

cruffle_duffle wrote: post #15
AshleysBrain wrote: post #12

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.

A Dookie is a digested Cookie.

Re: Handling cookies is a minefield

#214

Post by foldr »

kijin wrote: post #169
NBJack wrote: post #132

Earlier quoted context omitted.

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages. For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now th…

Isn't that just the feature working as intended? Of course it is possible to introduce a bug by setting or not setting a cookie somewhere where it should/shouldn't be set.

I've never found a use for path-based cookies personally, but I'm not sure this is a particularly compelling example.

Re: Handling cookies is a minefield

#215

Post by pjc50 »

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.

Re: Handling cookies is a minefield

#216

Post by oneeyedpigeon »

kijin wrote: post #169
NBJack wrote: post #132

Earlier quoted context omitted.

Can you elaborate? I'm having a tough time finding references to that. (Disclaimer: I'm not an avid JS developer)

It means that you are setting cookies on whatever page you're on, without considering whether the cookie will be consistently accessible on other pages. For example, you set the currency to EUR in /product/123, but when you navigate to /cart and refresh, it's back to USD. You change it again to EUR, only to realize in /cart/checkout that the USD pricing is actually better. So you try to set it back to USD, but now th…

If you want cookies to be global, set them to / or leave out the path. If you want more fine-grained cookies, use a specific path. What's the problem? Currency is—in your example—clearly a site-wide setting. I think sites should make more of their hierarchical structure, not less.

Re: Handling cookies is a minefield

#217

Post by sensanaty »

thayne wrote: post #190
anonfordays wrote: post #181

Earlier quoted context omitted.

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.

Usually it's mainsite.com for the marketing site, and then app.mainsite.com for actual production, or if you have multiple it'll have the product name, like coolproduct.mainsite.com

We then have app-stg and app-canary subdomains for our test envs which can only be accessed by us (enforced via zero trust). No reason for marketing or SEO teams to care in any case.

Re: Handling cookies is a minefield

#218

Post by graemep »

netdevphoenix wrote: post #211
thayne wrote: post #190

Earlier quoted context omitted.

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.

When was the last time you saw a public website like that? prod.companyname.com websites are extremely rare especially outside tech.

The production site could be www. or something else that makes sense.

Re: Handling cookies is a minefield

#219

Post by Macha »

littlestymaar wrote: post #197
Macha wrote: post #84

Earlier quoted context omitted.

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 ar…

> nobody has ever taken the time to write an RFC with supporting arguments.

https://rust-lang.github.io/rfcs/3243-packages-as-optional-n...

https://github.com/rust-lang/rfcs/pull/3243

Re: Handling cookies is a minefield

#220

Post by littlestymaar »

eru wrote: post #141
Illniyar wrote: post #90

Earlier quoted context omitted.

Solved the problem almost completely in npm. Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. But once you know a namespace is owned by a company or project, you can know that everything under it is legit. Which solves the vast majority of squatting and impersonation problems. Also you know that everything under "node"…

> Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com Of course, there's no guarantee that https://company.com…

That just makes package names harder to remember and type (and actually less secure as more prone to typosquatting and backdoors in seamingly harmless pull requests) for no benefit.

Keep in mind that the majority of package by far don't come from companies in the first place, and requiring individual developers to have a domain of their own isn't particularly welcoming.

It's going to be tons of complexity for zero actual benefit.

Post reply on HN