-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Proposal : Permit modification of X-FRAME-OPTIONS headers #7951
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
Comments
I'd like to be able to individually control the My use case:
Currently I can't due to the |
Same problem here. I am running gitea and swagger editor in two different containers. I would like to load a .yaml file from gitea into the editor. Swagger complains about CORS blocking the request, but maybe the real problem is the X-FRAME-OPTIONS header. |
CORS has different headers that need to be added to allow cross origin requests |
I agree that having a way to control If you use nginx as a reverse proxy, it's possible to override it there (credits to https://serverfault.com/a/982013):
|
This PR provides a mechanism to set the X-FRAME-OPTIONS header. Fix go-gitea#7951 Signed-off-by: Andrew Thornton <[email protected]>
* Allow setting X-FRAME-OPTIONS This PR provides a mechanism to set the X-FRAME-OPTIONS header. Fix #7951 Signed-off-by: Andrew Thornton <[email protected]> * Update docs/content/doc/advanced/config-cheat-sheet.en-us.md Co-authored-by: John Olheiser <[email protected]> Co-authored-by: John Olheiser <[email protected]>
Hello,
I'd like to file a proposal concerning the HTTP headers sent by Gitea, due to a specific user case I'm running into.
Currently, Gitea always send the HTTP header "X-FRAME-OPTIONS" with the value "SAMEORIGIN" in all requests, which is a good security practice. However, I'm currently running into a case where I need to set this header to a value like "ALLOW-FROM <external_site>", to permit framing Gitea inside a portal I'm currently working on. Because I do not have control over the proxy serving Gitea, one of the solution I have is to set the header from Gitea directly. I could also mount a proxy on the same machine as Gitea to have this proxy serve the right headers instead of Gitea, but (in my view) this solution is a complicated workaround of a otherwise easy to fix issue.
I'm proposing to permit the configuration of this specific header with a line inside the app.ini, with a default value of SAMEORIGIN (to ensure the default behavior of Gitea isn't modified with the proposed change). This way, anyone could set the value of this header to the value which suits their need, without compromising the default security of the solution. I do understand my case is uncommon, but I think this evolution could be implemented very easily (due to the fact that I've already done it on my part). I can propose the PR if interested.
Thoughts?
The text was updated successfully, but these errors were encountered: