Closed vvo closed 11 months ago
cc @devjmetivier as for the OverridableOptions question. Thanks.
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.
iron-session v8 is live now š https://github.com/vvo/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!
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: https://github.com/vvo/iron-session/blob/eb1db401595a5ec3888e952e6da125db8c383773/src/core.ts#L115
This should be enough, correct?
Also @renchris I mentioned you here: https://twitter.com/vvoyer/status/1726521507457986758 š
Hi there, @brc-dd and @renchris. First, thank you for all your contributions and help and everyone who chimed in on #586.
Here's the status: I published
iron-session@8.0.0-beta.6
, please give it a try:Usage: https://github.com/vvo/iron-session/tree/v8#usage
Notable changes and questions to finish this release:
getIronSession(req, res, sessionOptions)
andgetIronSession(cookieStore, sessionOptions
OverridableOptions
? I don't understand the usecase yet, please be specific špnpm dev
at the root of the repoThank you again, looking forward to discussing here now and reach a shippable state super soon.