84e47b82a5
1. Logout is better called in a POST request (avoids caching in most situations + avoids weird CSRF "logout attacks", i.e. can't be logged out by clicking on an email link) 2. We should wait for logout to complete before mutating the user, otherwise some weird race conditions might prevent swr to catch the right logged out state |
||
|---|---|---|
| .. | ||
| components | ||
| lib | ||
| pages | ||
| public | ||
| .env.development | ||
| .env.production | ||
| .gitignore | ||
| package.json | ||
| README.md | ||
| vercel.json | ||
Example application using next-iron-session
This example creates an authentication system that uses a signed and encrypted cookie to store session data. It relies on next-iron-session.
It uses current best practices for authentication in the Next.js ecosystem.
Features:
- Static Generation (SG), recommended example
- Server-side Rendering (SSR) example in case you need it
- Logged in status synchronized between browser windows/tabs using
useUserhook andswrmodule - Layout based on the user's logged-in/out status
- Session data is signed and encrypted in a cookie
next-iron-session also supports:
- Express / Connect middlewares
- Multiple encryption keys (password) to allow for seamless updates or just password rotation
Online demo at https://next-iron-session.vercel.app/ 👀
Deploy your own
Deploy the example using Vercel:
How to use
Execute create-next-app with npm or Yarn to bootstrap the example:
npx create-next-app --example with-iron-session with-iron-session-app
# or
yarn create next-app --example with-iron-session with-iron-session-app
Deploy it to the cloud with Vercel (Documentation).