-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
Is there an existing issue for this?
- I have searched the existing issuesTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Describe the bug
SessionServiceCollectionExtensions.AddSession creates a cookie with the Path of "/", ignoring the path base of the web application. This is further complicated in that AddSession does not provide a way to access the HttpContext, so my code cannot easily set the cookie path to the desired value.
Documents cookie behavior of AddSession:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/app-state?view=aspnetcore-7.0#session-options
Documents the problem:
https://stackoverflow.com/q/54362266/4194514
Expected Behavior
The cookie created by SessionServiceCollectionExtensions.AddSession should use the path base of the web application, similarly to how antiforgery token does.
Steps To Reproduce
Give your web application a path base and use SessionServiceCollectionExtensions.AddSession to add session to the website, but do not specify a path of the session cookie. You will see in code that the path of the cookie is set by the framework to "/", which I believe comes from SessionDefaults.CookiePath.
Exceptions (if any)
No response
.NET Version
No response
Anything else?
I see 3 different ways to fix this issue.
- Automatically set the cookie Path to the application's PathBase, instead of SessionDefaults.CookiePath.
- Change the value of SessionDefaults.CookiePath from "/" to the application's path base.
- Add an additional signature to SessionServiceCollectionExtensions.AddSession that accepts the http context, so my custom code can determine the PathBase and set it as the cookie path.
Activity
Tratcher commentedon May 10, 2023
Here is what Antiforgery does:
aspnetcore/src/Antiforgery/src/Internal/DefaultAntiforgeryTokenStore.cs
Lines 79 to 99 in 4afe7f6
Changing the default for Session would be breaking.
Note we also use / for auth. I'm not sure why Antiforgery does something different.edit nevermind, auth also uses path base by default.
aspnetcore/src/Security/Authentication/Core/src/RequestPathBaseCookieBuilder.cs
Lines 22 to 38 in 4afe7f6
Coder3333 commentedon May 11, 2023
@Tratcher , I haven't tracked down the Microsoft source code, yet, but in my application AddAuthentication and AddAntiforgery are creating their cookies with the proper path base, even though I am not doing anything to control that value. So far, AddSession is the only one of these that is creating the cookie at "/".
ahaeber commentedon Feb 9, 2024
/azp run
wessleym commentedon Oct 25, 2024
I also would appreciate if
AddSession
acted in the same way asAddAuthentication
andAddAntiforgery
. Thank you.kvantetore commentedon Jun 24, 2025
Although I would love for the default to be more sensible, it is straight forward to use
RequestPathBaseCookieBuilder
to create session cookies:dineshmike commentedon Jun 25, 2025
This worked for me. Thanks 🙏
kvantetore commentedon Jun 25, 2025
@wessleym, in my case, I want the session cookie to have the same path as the auth cookie, which is the root of the application.
RequestPathBaseCookieBuilder
does exactly that by defaulting the path tocontext.Request.PathBase
when thePath
property is null. (see https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Core/src/RequestPathBaseCookieBuilder.cs#L28)kvantetore commentedon Jun 25, 2025
@wessleym, I am not entirely sure what you are trying to achieve, but from the source code of RequestPathBaseCookieBuilder it looks like it uses
context.Request.Path
every timeBuild(...)
is called.I suppose
SessionMiddleware
only creates a new session cookie if a session cookie is not found in the request header. Perhaps this is where it goes wrong for you? However, I struggle to see what other behaviour would be sensible?wessleym commentedon Jun 25, 2025
@kvantetore, after reading your comment and rereading the source code of RequestPathBaseCookieBuilder, I realized it does set the cookie path for every request. (I thought it just set it for the first request and reused that path later, even if
PathBase
had changed.) So I was wrong about that.Your directing us to
RequestPathBaseCookieBuilder
is helpful. Thank you. But I still hope session can act likeAddAuthentication
andAddAntiforgery
one day by default, as I know you do too.