-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Automatically set cookie secure
attribute, remove COOKIE_SECURE option
#26953
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
c9cd3bf
b58bec7
ecebb8f
f302954
c625510
ac5dc18
bcea3bd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -101,15 +101,20 @@ func stripSlashesMiddleware(next http.Handler) http.Handler { | |
} | ||
|
||
func Sessioner() func(next http.Handler) http.Handler { | ||
return session.Sessioner(session.Options{ | ||
Provider: setting.SessionConfig.Provider, | ||
ProviderConfig: setting.SessionConfig.ProviderConfig, | ||
CookieName: setting.SessionConfig.CookieName, | ||
CookiePath: setting.SessionConfig.CookiePath, | ||
Gclifetime: setting.SessionConfig.Gclifetime, | ||
Maxlifetime: setting.SessionConfig.Maxlifetime, | ||
Secure: setting.SessionConfig.Secure, | ||
SameSite: setting.SessionConfig.SameSite, | ||
Domain: setting.SessionConfig.Domain, | ||
}) | ||
return func(next http.Handler) http.Handler { | ||
return http.HandlerFunc(func(resp http.ResponseWriter, req *http.Request) { | ||
handler := session.Sessioner(session.Options{ | ||
Provider: setting.SessionConfig.Provider, | ||
ProviderConfig: setting.SessionConfig.ProviderConfig, | ||
CookieName: setting.SessionConfig.CookieName, | ||
CookiePath: setting.SessionConfig.CookiePath, | ||
Gclifetime: setting.SessionConfig.Gclifetime, | ||
Maxlifetime: setting.SessionConfig.Maxlifetime, | ||
Secure: middleware.GetCookieSecure(req), | ||
SameSite: setting.SessionConfig.SameSite, | ||
Domain: setting.SessionConfig.Domain, | ||
}) | ||
handler(next).ServeHTTP(resp, req) | ||
}) | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not 100% sure this usage is correct, but it appears to work. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The "next" call is right, but the Sessioner is not designed to be used like this. eg: It starts a GC goroutine for every The sessioner expects there should be only one instance for all requests. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If this is suboptimal, I think the only other option is to let sessioner accept a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not only suboptimal, it breaks the Sessioner's design and would cause bugs. The Sessioner also has many internal states, it expects the only one instance do "Init" (eg: connect to redis) and do session management (eg: Lock, GC). Although we could make some changes to make a Sessioner work with dynamic Cookie Secure option, but I think it's too complex to do that, and "dynamic Cookie Secure" doesn't seem really bring enough benefit. The mentioned "AppURL + COOKIE_SECURE option" should be simple enough and I don't see any problem by doing that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not just cookie secure. If the backend wants for example to reconstruct the original URL a client used (for example for audit log), XFP is required for that as well. Maybe I'll look into sessioner accepting a function (typecheck with Reflect), that seems the simplest option. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Just use AppURL, in many cases, the backend doesn't have the HTTP request context. So, AppURL should always be correct. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unless the app runs on multiple URLs :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yup, but the AppURL should also be correct in this case, otherwise the nofication/mail/webhook would stop working. As long as the AppURL should be always right, then just use it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
} |
Uh oh!
There was an error while loading. Please reload this page.