session
cookie-session
session | cookie-session | |
---|---|---|
1 | 3 | |
895 | 1,104 | |
0.2% | 0.1% | |
0.0 | 7.2 | |
12 days ago | 3 months ago | |
JavaScript | JavaScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
session
-
JWT should not be your default for sessions
Frameworks usually sign cookies by default, or at least offer an option to do so. Some (like Ruby on Rails) can encrypt them for you too. There's nothing really stopping you from storing data in them just like you would a JWT. In fact, frameworks and session libraries often use this cookie storage by default (even in the Node ecosystem, e.g: koa-session, express cookie-session), since an in-memory store can grow to an arbitrary size. Of course, you can also just store a JWT in a cookie, which has the advantage of being standardized in terms of claims and signing algorithms etc.
cookie-session
-
Stop using JSON Web Tokens for user sessions
The lack of logout and XSS are problems, but I ran into a couple apps that completely forgot to expire sessions due to lacking framework support. In nodejs's cookie-session and @google-cloud/connect-firestore sessions never expire. This issue impacts downstream software including, awkwardly enough, Google's Passkey demo apps. There isn't interest in fixing this.
Make sure your app is actually using a JWT framework, not a lesser version, and implements basic security practices.
[1] https://github.com/expressjs/cookie-session
[2] https://github.com/googleapis/nodejs-firestore-session
-
Node Authentication Questions
Side note: a JWT in an HttpOnly cookie, which is what some people advocate, is still a cookie-based session. Using a library like cookie-session would already give you the ability to have a signature-verified JSON payload, just like using a JWT would.
-
JWT should not be your default for sessions
Frameworks usually sign cookies by default, or at least offer an option to do so. Some (like Ruby on Rails) can encrypt them for you too. There's nothing really stopping you from storing data in them just like you would a JWT. In fact, frameworks and session libraries often use this cookie storage by default (even in the Node ecosystem, e.g: koa-session, express cookie-session), since an in-memory store can grow to an arbitrary size. Of course, you can also just store a JWT in a cookie, which has the advantage of being standardized in terms of claims and signing algorithms etc.
What are some alternatives?
Strapi - π Strapi is the leading open-source headless CMS. Itβs 100% JavaScript/TypeScript, fully customizable and developer-first.
vue-cookies - A simple Vue.js plugin for handling browser cookies
a12n-server - An open source lightweight OAuth2 server
body-parser - Node.js body parsing middleware
egg - π₯ Born to build better enterprise frameworks and apps with Node.js & Koa
csurf - CSRF token middleware
node-session-client - Node implementation of free, cross-platform, onion-routed GetSession.org client
session - Simple session middleware for Express
cookie-parser - Parse HTTP request cookies
cookie - HTTP server cookie parsing and serialization