🚀
ShipClojure
  • README
  • Development
    • Getting Started
    • REPL Workflow
    • AI Development with ShipClojure
    • Getting Updates
    • Formatting code
    • ShipClojure Guiding Principles
  • Backend
    • Migrations
    • Secrets
    • Routing
    • ShipClojure Blog
    • Email
  • Frontend
    • UIx + re-frame
    • HTTP Requests with Re-frame
    • Frontend Navigation with Re-frame
    • Toast Notifications
    • Icons
  • Server Side Rendering
    • Static/Landing pages
  • Auth
    • How Auth works
    • Oauth2 providers
  • Deployment
    • Deployment
  • Decisions
    • 001 - Cookie Sessions
    • 002 - Single Page Application Architecture
    • 003 - Re-frame instead of Refx
    • 003 - Move from cookie sessions to JWT Access + refresh tokens
Powered by GitBook
On this page
  • Context
  • Decision
  • Consequences
  1. Decisions

001 - Cookie Sessions

PreviousDeploymentNext002 - Single Page Application Architecture

Last updated 1 month ago

Date: 2024-06-5

Status: accepted

Context

Initially I wanted ShipClojure to use JWT tokens and but that turned out to be problematic especially when it comes to server rendering.

Another issue is that the Clojure community is more set on cookies. You can observe this from the strategies and auth packages already existent.

Decision

Authentication will be done through a session cookie store, signed with a secret found in system.md. The secret is persistent so sessions aren't revoked every time we restart our server.

Consequences

The code for access/refresh token logic will be deleted, however you can still find it in the history.

ShipClojure will make heavy use of cookies. The session will be accessible in the :session map from each request incoming to the server

One problem with this approach is that from user management, we cannot revoke a session. As a solution, we will implement a persistent session memory (redis or ) that can be deleted.

refresh token rotation
Here is the last working commit with refresh token logic
persistent atom