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

151–160 of 270 posts

Re: Handling cookies is a minefield

#151

Post by j16sdiz »

labster wrote: post #128
qingcharles wrote: post #110

Earlier quoted context omitted.

The name of the city is 東京 -- anything in Latin characters is a rough transliteration. Tokio was the common spelling in European texts until some time last century, and is still used regularly in continental Europe. see also, e.g. Tokio Hotel

Tokio is a different (masculine) name in Japanese, pronounced quite differently. /tokʲio/ vs. /to̞ːkʲo̞ː/. https://en.m.wikipedia.org/wiki/Tokio_(given_name)

We are talking about the spelling centuries ago, when the romanisation were less standardised

Re: Handling cookies is a minefield

#152

Post by nox101 »

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.

the new thing should be called "cupcakes" or "candies" or "snacks" or "munchies"

Re: Handling cookies is a minefield

#153

Post by telgareith »

bpicolo wrote: post #148
prokopton wrote: post #147

Earlier quoted context omitted.

If you want to maintain state across navigations and share that state with a server it’s the best we’ve got.

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

#154

Post by j16sdiz »

emn13 wrote: post #92
graypegg wrote: post #85

Earlier quoted context omitted.

I think they mean that you can always send back the content of a localstorage property with javascript grabbing the value and sending another request back with it in the body. Since the front end is going to run any javascript the server sends it (disregarding adblockers at least), it's sort of a more indirect version of Set-Cookie.

Yeah, that's what I meant. There's no built in support; but it's indirectly readable since client-side JS can read it.

This miss the "HttpOnly" part, which prevents javascript (think script injection vulnerability) from touching this part of the storage

Re: Handling cookies is a minefield

#155

Post by nox101 »

bob1029 wrote: post #35
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.

The DOM & URL are the safest places to store client-side state. This doesn't cover all use cases, but it does cover the space of clicking pre-authorized links in emails, etc. I spend a solid month chasing ghosts around iOS Safari arbitrarily eating cookies from domains controlled by our customers. I've never seen Google/Twitter/Facebook/etc domains lose session state like this.

If I open a second window or tab I expect when I go to 'myemail.com' that it knows who I am and shows me my account even though the url in the 2nd tab doesn't have any extra info in the URL

Re: Handling cookies is a minefield

#156

Post by j16sdiz »

IgorPartola wrote: post #135

Cookies need to die. Their only legitimate use is with for which we have the Authentication header. Having a standard way to authenticate into a website in a browser would be amazing, just too bad that Basic and Digest auth wasn’t good enough at the time. As a bonus we could get Persona-style passwordless future.

How about user preference without logging in? Are you suggesting create a trillion throwaway accounts?

Re: Handling cookies is a minefield

#157

Post by j16sdiz »

loa_in_ wrote: post #106
ricardo81 wrote: post #50

Earlier quoted context omitted.

Are they ubiquitous? I'm no client side guru, I know I could look at makeuseof etc, but why not ask some professionals instead.

At the very least localstorage is supported across the board

No. It is disabled in many browsers when opened in private mode. Where you can have session cookies

Re: Handling cookies is a minefield

#158

Post by teaearlgraycold »

treflop wrote: post #131
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…

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.

Re: Handling cookies is a minefield

#159

Post by NavinF »

treflop wrote: post #131
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…

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.

Yep. Even within the prod environment it's ideal to have a separate domain (as defined by the Public Suffix List) for sketchy stuff like files uploaded by users. Eliminates a whole class of security issues and general fuckery

Re: Handling cookies is a minefield

#160

Post by seandoe »

baggy_trough wrote: post #144
IgorPartola wrote: post #142

Earlier quoted context omitted.

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…

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.
Post reply on HN