-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Automatically set cookie secure
attribute, remove COOKIE_SECURE option
#26953
Changes from all 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. |
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry but it's not right.
Many users might not pass these header when they use Gitea behind a reverse proxy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can just parse
setting.AppURL
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. And:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least for nginx, we have been documenting for a long time to configure that header.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, only "At least". None of others are documented.
And even there is a document, many users do not follow that, they just like to write the config by their experiences.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would call it out in changelog and be done with it. It's the right way to check if connection is secure imho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought I do see parsing
AppURL
as the more forgiving option. In an application that does not have such a setting, the current method is the only one that can work, but given that we haveAppURL
we might as well use it.What only works with my method is to host the application on multiple domains and/or mixed http/https but I guess that is a seldomly used configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the solution in comment #26953 (comment) .
According to MDN, the
X-Forwarded-Proto
is not standard and there are many alternatives (Front-End-Https
/X-Forwarded-Protocol
/X-Forwarded-Ssl
/X-Url-Scheme
). IMO using the strong assumption withX-Forwarded-Proto
might cause many users unable to login and fail silently. Gitea should be able to be easy to setup and use out-of-box.My suggestion also works well with "host the application on multiple domains and/or mixed http/https", the site admin could set COOKIE_SECURE=false in their config, keep trusted HTTP requests and redirect untrusted HTTP requests to HTTPS, still no security risk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in summary: Keep
COOKIE_SECURE
but the AppUrl is https, switch it to true? I'm not sure such "magic" is good to do. Maybe I should just scrap the entire PR.