cookie is sent by hono_session on each request

[georgernstgraf]

Hi,

I'd say I have a quite classical setup and everything works. On one endpoints I store a few Kilobytes of data onto the session, which works fine, besides the cookie gets always sent fresh and new by the backend. I was looking for something like in express where this can be tuned:

app.use(session({
  secret: 'your-secret-key',
  resave: false,
  saveUninitialized: false,
  cookie: { secure: true, httpOnly: true }
}));

Am I missing something or is this not implemented yet? The only option I see for me is just use the sessionMiddleware on selected endpoints. But I really want to avoid this.

Thank you so much!

George

[Mortalife]

Looks like the issue comes from https://github.com/jcs224/hono_sessions/blob/main/src/Middleware.ts#L89-L91 where the cookie is set for all other stores than CookieStore regardless of if it's a new session or not.

It should probably be moved to https://github.com/jcs224/hono_sessions/blob/main/src/Middleware.ts#L83 by default, with users who want to rotate it using the existing rotate mechanism instead.

[georgernstgraf]

I'd also like to understand the rationale behind it ... the downside of using CookieStore is that the session payload is packed into the cookie, which makes data on the session limited to the 4K of allowed cookie size.

[jcs224]

@georgernstgraf the rationale was to always have a record of when the session was last accessed, so that the user didn't experience an expired session if they kept using the app. It does seem to cause some problems though..

There's a PR that might address your issue, have you seen it? Would this help you in your situation? #30

[jcs224]

@georgernstgraf if you're using CookieStore, this issue should be addressed in the just-released v0.8.0. If you're using a non-CookieStore, this issue hasn't been addressed yet so I'm keeping the issue open.

[georgernstgraf]

@jcs224 My intent was to put as little as possible data into the cookie, just the sessionID, and let the server store the actual payload. I have written a session class (including middleware) to demonstrate what I wanted to achieve. Look at this gist!

For addressing #30 .. I'd assume my code does not have the race issue.

Thinking about your comment, you would put a cookieExpireDate onto the (server/memcache/redis)-stored session (same manner as username), and upon load (from store) you can check if you want to (resend a fresh cookie AND re-save to store with the same EOL).

I'd love to know your thoughts on this.

[jcs224]

@georgernstgraf for the non-CookieStores, only the key is stored in the cookie, and the session data is stored in some other database. There is even some guidance for writing your own driver, using MongoDB in this example:

https://github.com/jcs224/hono_sessions/wiki/Creating-a-custom-storage-driver

However, when you give it an encryption key, it is both signed and encrypted, so it's no possible for the user to even guess their own Session ID from the cookie. If you don't give it a key, the session ID remains visible as a UUID. I probably should make at least signing the cookie mandatory.

You brought up the fact that the session key is written back to the cookie on every single request, which isn't necessary, so your original issue is valid 🙂

[georgernstgraf]

I need to think loud. I only want to cover normal Store, not cookiestore.

At initial creation of a session, two things happen:

• a cookie with maxAge (expiration date can be calculated) is sent to the browser
• a session is created and persisted in the store

Our session object in the store needs to know when the cookie expires for (at least) two reasons:

• beeing able to evict stale sessions from the db (browser might have discarded the cookie)

• more importantly: if the cookie / session has left less ttl than a threshold (must be less then maxAge obviously) then we send a) an updated cookie and b) update the eol of the session in our store.

• logout seems clear (delete both)

• login also (create both)

If sessionData changes underway (darkmode, etc..), we only update the store - without touching the store's eol, because this eol perfectly reflects the cookies eol). Not resend the cookie.

I am aware my posted gist does not implement this (the knobs are there though), so I'm a bit sorry for the noise.

I'm not sure how to design this without creating a too tight coupling between Session and Store.

Thank you!