github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 23:52:05 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

Manually Create / Generate Cookie from Session #1656

New Issue
Closed
opened 2026-03-13 08:54:01 -05:00 by GiteaMirror · 9 comments
GiteaMirror commented 2026-03-13 08:54:01 -05:00
Owner
Copy Link

Originally created by @alexanderl19 on GitHub (Aug 7, 2025).

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

Helper function to manually generate the signed session cookie from a session object.

Describe alternatives you've considered

Currently, I've been parsing the set-cookie header with the returnHeaders property:

auth.api.signInEmail({
	body: ...,
	returnHeaders: true,
}),

then getting the cookies from there. However, some endpoints (validate ott) don't return a cookie header even with returnHeaders set to true.

Having an option to just take the returned session and generate the cookie directly seems like a reasonable "catch all", and would avoid repeatedly parsing headers.

Additional context

My working understanding from briefly looking that the NextJS cookie plugin is that it parses the cookie header out then uses the NextJS specific method of setting cookies. Is there some architectural reason for this?

Originally created by @alexanderl19 on GitHub (Aug 7, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. _No response_ ### Describe the solution you'd like Helper function to manually generate the signed session cookie from a session object. ### Describe alternatives you've considered Currently, I've been parsing the set-cookie header with the returnHeaders property: ```ts auth.api.signInEmail({ body: ..., returnHeaders: true, }), ``` then getting the cookies from there. However, some endpoints (validate ott) don't return a cookie header even with returnHeaders set to true. Having an option to just take the returned session and generate the cookie directly seems like a reasonable "catch all", and would avoid repeatedly parsing headers. ### Additional context My working understanding from briefly looking that the NextJS cookie plugin is that it parses the cookie header out then uses the NextJS specific method of setting cookies. Is there some architectural reason for this?
GiteaMirror added the enhancement label 2026-03-13 08:54:01 -05:00
GiteaMirror commented 2026-03-13 08:54:02 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Aug 13, 2025):

@alexanderl19 If you’re simply seeking the session token, you can access it using session.token. Is there anything else you’re requesting that differs from this?

@frectonz commented on GitHub (Aug 13, 2025): @alexanderl19 If you’re simply seeking the session token, you can access it using `session.token`. Is there anything else you’re requesting that differs from this?
GiteaMirror commented 2026-03-13 08:54:03 -05:00
Author
Owner
Copy Link

@alexanderl19 commented on GitHub (Aug 14, 2025):

I'm looking to specifically generate the signed session cookie content on the server. I am aware that I can manually access the session token and create a signed cookie via middleware, but this seems like a common enough use case to warrant a more convenient utility function.

if (ctx.path.startsWith("/one-time-token/verify")) {
	const sessionToken = ctx.context.returned.session.token;
	if (typeof sessionToken === "string")
		await ctx.setSignedCookie(
			ctx.context.authCookies.sessionToken.name,
			sessionToken,
			ctx.context.secret,
		);
}

vs something along the lines of

auth.api.getSessionCookie(session)

or

auth.api.signInEmail({
	body: parsedFormData.values,
	returnCookies: true,
}),

Currently, I'm using better-auth on the server side only. I imagine the ability to generate the session cookie would be useful regardless, but perhaps my use case is more niche than I expected. However, it does seem like a common pattern for better-auth to create a set-cookie header, just to later parse said header to set cookies with an alternative method (NextJS or SvelteKit cookie helper).

For example, would it not be more streamline to receive the cookie names / content directly from the api responses? It seems restrictive to only be able to access the signed cookie via headers or manually signing the cookie.

ie: nextCookies plugin implementation

(current) Call Better Auth API (creates set-cookie header) -> Parse Cookies out of Response Header -> Map Cookies to NextJS cookie function

vs

(improved) Call Better Auth API -> Set Cookies to NextJS cookie function

@alexanderl19 commented on GitHub (Aug 14, 2025): I'm looking to specifically generate the signed session cookie content on the **server**. I am aware that I can manually access the session token and create a signed cookie via middleware, but this seems like a common enough use case to warrant a more convenient utility function. ```ts if (ctx.path.startsWith("/one-time-token/verify")) { const sessionToken = ctx.context.returned.session.token; if (typeof sessionToken === "string") await ctx.setSignedCookie( ctx.context.authCookies.sessionToken.name, sessionToken, ctx.context.secret, ); } ``` vs something along the lines of ```ts auth.api.getSessionCookie(session) ``` or ```ts auth.api.signInEmail({ body: parsedFormData.values, returnCookies: true, }), ``` Currently, I'm using better-auth on the server side only. I imagine the ability to generate the session cookie would be useful regardless, but perhaps my use case is more niche than I expected. However, it does seem like a common pattern for better-auth to create a set-cookie header, just to later parse said header to set cookies with an alternative method (NextJS or SvelteKit cookie helper). --- For example, would it not be more streamline to receive the cookie names / content directly from the api responses? It seems restrictive to only be able to access the signed cookie via headers or manually signing the cookie. ie: nextCookies plugin implementation (current) Call Better Auth API (creates set-cookie header) -> Parse Cookies out of Response Header -> Map Cookies to NextJS cookie function vs (improved) Call Better Auth API -> Set Cookies to NextJS cookie function
GiteaMirror commented 2026-03-13 08:54:03 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Aug 14, 2025):

@alexanderl19 I understand what you want now, will create a PR for it shortly.

@frectonz commented on GitHub (Aug 14, 2025): @alexanderl19 I understand what you want now, will create a PR for it shortly.
GiteaMirror commented 2026-03-13 08:54:04 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Aug 14, 2025):

@alexanderl19 I went with

auth.api.signInEmail({
	body: parsedFormData.values,
	returnCookies: true,
})

but it will require a change in better-call https://github.com/Bekacru/better-call/pull/33 stay tuned it might take a while until this gets merged into better-call and then integrated into better-auth

@frectonz commented on GitHub (Aug 14, 2025): @alexanderl19 I went with ```typescript auth.api.signInEmail({ body: parsedFormData.values, returnCookies: true, }) ``` but it will require a change in better-call https://github.com/Bekacru/better-call/pull/33 stay tuned it might take a while until this gets merged into `better-call` and then integrated into `better-auth`
GiteaMirror commented 2026-03-13 08:54:04 -05:00
Author
Owner
Copy Link

@alexanderl19 commented on GitHub (Aug 14, 2025):

Thanks!

Small tangent, but I assume this would only work on better-auth API requests that return cookies in the first place. Incidentally, auth.api.verifyOneTimeToken only returns the session, but ignores returnHeaders / asResponse options 1 . Are you familiar with whether this was an intentional decision, or just an oversight because it's not one of the core api paths.

  1. Ignores in the sense that the headers / response doesn't include a cookie for the session. ↩︎

@alexanderl19 commented on GitHub (Aug 14, 2025): Thanks! Small tangent, but I assume this would only work on better-auth API requests that return cookies in the first place. Incidentally, `auth.api.verifyOneTimeToken` only returns the session, but ignores `returnHeaders` / `asResponse` options [^0]. Are you familiar with whether this was an intentional decision, or just an oversight because it's not one of the core api paths. [^0]: Ignores in the sense that the headers / response doesn't include a cookie for the session.
GiteaMirror commented 2026-03-13 08:54:05 -05:00
Author
Owner
Copy Link

@frectonz commented on GitHub (Aug 14, 2025):

Yeah you are right, we might need to handle some specific cases like auth.api.verifyOneTimeToken but we can handle them after the returnCookes feature is integrated.

@frectonz commented on GitHub (Aug 14, 2025): Yeah you are right, we might need to handle some specific cases like `auth.api.verifyOneTimeToken` but we can handle them after the `returnCookes` feature is integrated.
GiteaMirror commented 2026-03-13 08:54:05 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Nov 13, 2025):

Hi, @alexanderl19. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You requested a helper function to generate signed session cookies directly from session objects on the server.
  • The maintainer, frectonz, is working on adding a returnCookies option to API calls like signInEmail to provide cookie data directly.
  • You noted that some endpoints, such as verifyOneTimeToken, do not return cookies even with returnHeaders enabled.
  • frectonz agreed to address these endpoints after the main feature is integrated.
  • The goal is to improve cookie handling for server-side use and streamline integration with frameworks like NextJS.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of better-auth by commenting here.
  • If I do not hear back within 7 days, I will automatically close this issue.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Nov 13, 2025): Hi, @alexanderl19. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You requested a helper function to generate signed session cookies directly from session objects on the server. - The maintainer, frectonz, is working on adding a `returnCookies` option to API calls like `signInEmail` to provide cookie data directly. - You noted that some endpoints, such as `verifyOneTimeToken`, do not return cookies even with `returnHeaders` enabled. - frectonz agreed to address these endpoints after the main feature is integrated. - The goal is to improve cookie handling for server-side use and streamline integration with frameworks like NextJS. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of better-auth by commenting here. - If I do not hear back within 7 days, I will automatically close this issue. Thank you for your understanding and contribution!
GiteaMirror commented 2026-03-13 08:54:06 -05:00
Author
Owner
Copy Link

@alexanderl19 commented on GitHub (Dec 3, 2025):

@frectonz Could this issue be reopened? To my understanding, we are still waiting for upstream changes to be merged and this issue is still valid.

@alexanderl19 commented on GitHub (Dec 3, 2025): @frectonz Could this issue be reopened? To my understanding, we are still waiting for upstream changes to be merged and this issue is still valid.
GiteaMirror commented 2026-03-13 08:54:07 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Dec 3, 2025):

@Bekacru, the user @alexanderl19 has indicated that this issue is still valid and awaiting upstream changes despite being closed as stale. Could you please take a look and assist with reopening or addressing it?

@dosubot[bot] commented on GitHub (Dec 3, 2025): @Bekacru, the user @alexanderl19 has indicated that this issue is still valid and awaiting upstream changes despite being closed as stale. Could you please take a look and assist with reopening or addressing it?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1656
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?