Remix.run Logo
0x073 7 months ago

IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.

robgibbons 7 months ago | parent | next [-]

In both cases (cookie vs localStorage) you're really just storing your data as a string value, not truly a JSON object, so whether you use a cookie or localStorage is more dependent on the use case.

If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.

recursive 7 months ago | parent | next [-]

JSON is explicitly a string serialization format.

robgibbons 7 months ago | parent | next [-]

Right, I meant it's not a JavaScript object. It's serialized into a string in any case, no matter which API you're stuffing it into. So it's a bit of a non-sequitur for the parent to suggest that it's somehow weird to store JSON in a cookie, but not in localStorage. It's all just strings.

MBCook 7 months ago | parent | next [-]

I find it weird too. I’ve always considered cookies like very stupid key value stores.

It would never occur to me to put something more than a simple token in a cookie. A username, and email address, some opaque thing.

The idea of trying to use it for arbitrary strings just seems weird to my intuition, but I don’t really know why. Maybe just because when I was learning about them long ago I don’t remember seeing that in any of the examples.

recursive 7 months ago | parent | prev [-]

My point is that there really is no such thing as "truly a JSON object".

7 months ago | parent | prev [-]
[deleted]
0x073 7 months ago | parent | prev [-]

Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies.

withinboredom 7 months ago | parent [-]

And if I don't want any javascript to see my values, ever? Or how do you handle CSRF?

0x073 7 months ago | parent [-]

Httponly cookie is the way, but then you just don't use json as cookie value that is send on every request.

Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.

withinboredom 7 months ago | parent [-]

Since when can you trust js?

0x073 7 months ago | parent [-]

Big websites use js and if they leak most of the time it's not a js issue.

I think the distrust of js is a personal issue.

withinboredom 7 months ago | parent [-]

I mean, anyone can open devtools and change the code to do whatever ... or install an extension that does it. So, since when can you guarantee that a browser client will actually do what you program it to do? In my experience, you can't guarantee anything on the client -- since forever. I was asking when/if that changed. I don't see why you would make that a personal attack?

0x073 7 months ago | parent [-]

But that a general problem, having a html only page with a form is the same problem. Only transfer what the user should see.

You need server verification for data that's important. Native programs can be changed with over programs or hex editor.

The talk was about data that is stored into cookies as json and csrf. (Cookies can be changed with devtools or extension)

Csrf is always an attack from third party against the user, if the user extract the data itself that's no csrf problem.

Because of this I thought you distrust js that can get attacked from third party, but yes js is as easy to change like .net or java programs.

lambdaone 7 months ago | parent | prev | next [-]

You're really going to hate it when you learn about JSON Web Tokens, which exist exactly to hack past this sort of problem.

0x073 7 months ago | parent | next [-]

Jwt is encoded and it is used for data without a server session.

I'm not a fan for jwt and it used more often than it should, but sometimes it makes sense.

MBCook 7 months ago | parent | prev [-]

But at least they’re base 64 encoded so you don’t have to worry about the special characters

hinkley 7 months ago | parent | prev | next [-]

Good way to hit max header length issues. Ask me how I know.

osrec 7 months ago | parent [-]

How?

hinkley 7 months ago | parent | next [-]

Well you see when a front end developer and a backend developer hate each other very much, they do a special hug and nine days later a 400 request header or cookie too large error is born.

(Seriously though, someone trying to implement breadcrumbs fe-only)

mdaniel 7 months ago | parent | prev | next [-]

I'm not them, but that 419 pattern in the logs is burned into my adrenaline response: https://duckduckgo.com/?t=ffab&q=nginx+419+cookie+header&ia=...

0x073 7 months ago | parent | prev [-]

I used chromelogger years ago that created often a too big http header over time https://craig.is/writing/chrome-logger

ricardo81 7 months ago | parent | prev | next [-]

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

loa_in_ 7 months ago | parent [-]

At the very least localstorage is supported across the board

j16sdiz 7 months ago | parent [-]

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

7 months ago | parent | prev [-]
[deleted]