v8 beta release, last tasks and discussions about iron-session HOT 6 CLOSED

cc @devjmetivier as for the OverridableOptions question. Thanks.

from iron-session.

Can you provide explanations why we need mergeHeaders and createResponse

These aren't required in the next.js example because we are passing cookies() there. If we pass something like:

const res = new Response()

getIronSession(req, res, ...)

then cookies are appended to the original res object. Later if someone wants to, say, specify body based on the session data, they will need something like createResponse(res, { body: 'the user is authenticated' }).

If we aren't planning on supporting other frameworks, then I guess it's fine to not export them.

from iron-session.

iron-session v8 is live now 👍 https://github.com/vvo/iron-session

from iron-session.

Hey. I see this is closed now, however, for the use case of Overridable Options is that:

We can set our options for our Iron Session object during

1. Initiation

const getServerActionSession = async () => {
  const session = getServerActionIronSession<IronSessionData>(sessionOptions, cookies())
  return session
}

2. Function call .save() or .destroy()

export const submitCookieToStorageServerAction = async (cookie: string) => {
  const session = await getServerActionSession()
  session.cookieVariable = cookie
  const newCookieOption = { cookieOptions: { maxAge: undefined } }
  await session.save(newCookieOption)
}

We need options for the developer to pass in Cookie options that are different than the defaultOptions at the time of Iron Session object initiation and/or later at the time of .save()/.destroy() function call.

const defaultOptions: Required<OverridableOptions> = {
  ttl: fourteenDaysInSeconds,
  cookieOptions: { httpOnly: true, secure: true, sameSite: 'lax', path: '/' },
}

function mergeOptions(
  userSessionOptions: IronSessionOptions,
  overrides?: OverridableOptions,
): Required<IronSessionOptions> {
  const options: Required<IronSessionOptions> = {
    ...defaultOptions,
    ...userSessionOptions,
    ...overrides,
    cookieOptions: {
      ...defaultOptions.cookieOptions,
      ...userSessionOptions.cookieOptions,
      ...overrides?.cookieOptions,
    },
  };

We need the type OverridableOptions to ensure ttl is passed as our Iron Session core code expects and the cookieOptions are passed to the Cookie handler as the NextJS cookies() function expects

type OverridableOptions = Pick<IronSessionOptions, "cookieOptions" | "ttl">;

The final type definition for `CookieOptions` ends up to be
`'domain' | 'path' | 'secure' | 'sameSite' | 'name' | 'value' | 'expires' | 'httpOnly' | 'maxAge' | 'priority'`

Note these code examples refer to the codebase before the most recent Friday release changes. Congratulations on the release!

from iron-session.

Thank you @renchris, for the detailed explanation.
Do you have any real-world example in mind for when you would need to update ttl and/or cookie options during a save()? I am not saying they are none but I like to start from the problem (? changing the cookie name, why?) and then move to the solution (save accepts options)

What I have done in the end: I created updateConfig that you can call anytime to update any options:

This should be enough, correct?

from iron-session.

Also @renchris I mentioned you here: https://twitter.com/vvoyer/status/1726521507457986758 👍

from iron-session.