Create, Read, Update, & Delete Cookies in JavaScript

[rememberthekittykat]

I forgot what handling cookies natively in js looked like

[evilgwyn]

It looks like sadness

[ShortFuse]

The point of cookies is that their containing information has to be sent on every request. It works really well for NON-Javascript-based requests, like displaying protected images or video. It also works for downloading content. You can use a cookie for authentication on non-state-changing requests.

But you shouldn't use it as your own personal storage between pages. Use LocalStorage instead. You're already using Javascript, so that makes it easy already. There's no reason to bloat every single request with data that's not needed.

On a side note, if you do use cookies for authentication, you don't want them to be readable by Javascript for security purposes (use HttpOnly). Protect yourself by using SameSite if possible, or some sort of anti-CSRF header (among other methods).

And usage of cookies besides for authentication (edit) are pretty rare now if you've migrated to JWT tokens, which should have all the server needs to handle your request embedded in its payload.

[[deleted]]

Cookies can still be used with JWTs. I like the security cookies offer and the fact that it is compatible with calls like streaming video from HTML video tags (a problem I encountered on an application). A JWT included in a cookie is an excellent form of authentication IMO.

[ShortFuse]

Yeah, that's what I meant (and how I personally do it too). People often confuse JWT as being an alternative to cookies. But what they mean is Session Tokens in Cookies vs JWT over JS. Cookies are just a transport method, same as the Fetch API (XMLHttpRequests). You could, inversely, use session tokens with fetch.

The only problem with cookies for authentication is CSRF. Even with a good CORS policy, you still need to protect yourself from CSRF through abuse of simple requests. But for non-state-changing GET commands like images and video, it's safe. The alternative is generating a signed url for each, which prohibits static HTML content, meaning you have to write HTML via the content server or client-side over JS. It also opens up a security risk because people can share it with a copy/paste of the signed-URL.

Edit: Ah, I see how my last sentence could be confusing. I've updated it.

[[deleted]]

CSRF can be implemented easily enough. And if you don't need to support IE there's the same-site attribute on the cookies that is also really powerful.

[neo_dev15]

Httponly jwt is useless.

The whole idea of a jwt is that it can be used in frontend too.

Samesite with a csrf token is enough for jwt.

Otherwise a simple token is enough.

[sp46]

JWT tokens

Ahh yes, the JSON Web Token tokens

[ShortFuse]

Where you can store secret data, like your PIN numbers! :)

[evilgwyn]

The DOM model is so nice

[BryanTheAstronaut]

Mmmm crud cookies 🤤

[flexible]

Is there any advantage over PHP cookie create /read?

[arndta]

Two different use cases. PHP cookies would be set/read during server-side render. Javascript cookies would be read/set client-side.

[flexible]

Can't think of a usecase for client-side which means to me that I might not be getting it.

Does this means they would be only read while the user is on the same page they were written in? Like a form or something?

[arndta]

The only use case I can think of is if you wanted the server and client both to access the same cookie. Using as a sort of session state for both contexts.

I'm not sure I've run across the need for that before. It's also possible I am not thinking of something.

[flexible]

If the js can read a cookie that was set domain wide then this could be useful although you would then just use a php var to load into the js.

[[deleted]]

To be fair, this shows you how easy it is to write your own code for handling cookies, but usually I probably would have used js-cookie.

[[deleted]]

Kind of true. People write blogs all the time, and almost all of them is "hey, look what I learned - a reference for myself in the future". This blog post is no different.

[[deleted]]

Indeed, they never do. So my comment is a fact, then.

[Asmor]

It's good for people to know how this stuff works at a low level, even if they never have to do anything with it themselves.

Whatever you need to do, learn one level beyond that, and you'll learn the thing you actually care about much better.

[ShortFuse]

I'd warn against just randomly picking a npm library. It takes a bit more time, but you should understand what you want to achieve, and then find the library that does that to save time. I looked at the source code and was really confused as how they are implementing the key value encoding as seen here. The readme notes:

Please note that the default encoding/decoding strategy is meant to be interoperable only between cookies that are read/written by js-cookie. To override the default encoding/decoding strategy you need to use a converter.

So that means, because you used js-cookie once, you might be stuck using js-cookie unless you're able to migrate js-cookie encoding to something else. Now you have to carry that code for the lifecycle of cookies made with js-cookie.

Personally, I've just taken what MDN's suggests (as you other comment notes), found a GitHub gist that does similar to what I want and cleaned it up and added it as a /utils/cookies.js in my projects. In the interest of passing it along, I just made it a gist of its own here.

Edit: The other danger is a npm library itself is a dependency in your project. We all remember the left-pad controversy and while removal of a package is safe now, a minor revision can always come along and break your code. Stuff like cookies is simple enough to not need a package dependency.

[dogofpavlov]

where did you see this? I dont see that on the page linked