News for hackers. Stuff that matters.
Re:Handling cookies is a minefield by RadiozRadioz on Thursday November 21, 2024 @01:28PM (#42207151)
NewCookie is, roughly, what browser Local Storage is.

At least for some use cases. Of course, it doesn't directly integrate with headers.

Re:Handling cookies is a minefield by graypegg on Thursday November 21, 2024 @01:33PM (#42207211)
I think one important use case we have for cookies is "Secure; HttpOnly" cookies. Making a token totally inaccessible from JS, but still letting the client handle the session is a use case that localStorage can't help with. (Even if there's a lot of JWTs in localStorage out there.)
Re:Handling cookies is a minefield by emn13 on Thursday November 21, 2024 @03:04PM (#42208037)
However, potentially a localStorage (and sessionStorage!) compatible cookie-replacement api might allow for annotating keys with secure and/or HttpOnly bits? Keeping cookies and localStorage in sync is a hassle anyhow when necessary, so having the apis align a little better would be nice. Not to mention that that would have the advantage of partially heading off an inevitable criticism - that users don't want yet another tracking mechanism. After all, we already have localStorage and sessionStorage, and they're server-readable too now, just indirectly.

On the other hand; the size constraints on storage will be less severe than those on tags in each http request, so perhaps this is being overly clever with risks of accidentally huge payloads suddenly being sent along with each request.

Re:Handling cookies is a minefield by xp84 on Thursday November 21, 2024 @03:49PM (#42208521)
I think if I were implementing a webapp from scratch today I'd use one single Session ID cookie, store sessions in Redis (etc) indefinitely (they really aren't that big), and for things meant to be stored/accessed on the frontend (e.g. "has dismissed some dumb popup") just use local storage. Dealing with anything to do with cookies is indeed incredibly painful.
Re:Handling cookies is a minefield by mdaniel on Thursday November 21, 2024 @03:25PM (#42208253)
> and they're server-readable too now, just indirectly.

Could you point me to more reading about this? It's the first time I've heard of it

Re:Handling cookies is a minefield by graypegg on Thursday November 21, 2024 @03:47PM (#42208501)
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.
Re:Handling cookies is a minefield by emn13 on Thursday November 21, 2024 @04:03PM (#42208632)
Yeah, that's what I meant. There's no built in support; but it's indirectly readable since client-side JS can read it.
Re:Handling cookies is a minefield by j16sdiz on Thursday November 21, 2024 @10:11PM (#42210794)
This miss the "HttpOnly" part, which prevents javascript (think script injection vulnerability) from touching this part of the storage