| ▲ | robgibbons 5 days ago |
| 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 5 days ago | parent | next [-] |
| JSON is explicitly a string serialization format. |
| |
| ▲ | robgibbons 5 days 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 4 days 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 5 days ago | parent | prev [-] | | My point is that there really is no such thing as "truly a JSON object". |
| |
| ▲ | 5 days ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | 0x073 5 days ago | parent | prev [-] |
| Combine local storage with service worker, so you pass the data to the server if needed. Completely without setting cookies. |
| |
| ▲ | withinboredom 5 days ago | parent [-] | | And if I don't want any javascript to see my values, ever? Or how do you handle CSRF? | | |
| ▲ | 0x073 4 days 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 4 days ago | parent [-] | | Since when can you trust js? | | |
| ▲ | 0x073 4 days 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 3 days 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 2 days 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. |
|
|
|
|
|
|
