-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
X-Frame-Options warning in NC17beta2 #16893
Comments
Would you mind to add some basic information about your setup? Apache or Nginx version, how is PHP connected to the webserver, etc... |
Mind to add this information to your first post? Please also add the exact apache 2.4.x version (sometimes things are changed with minor versions). Its much easier to triage an issue with the issue template. |
Would you mind to share the output of
|
|
OK. I suspect that the heartbeat request is sent to the wrong url. Could you visit settings/admin/overview, open the development tools (e.g https://developers.google.com/web/tools/chrome-devtools/), go to network tab and reload the current page? If the request is going to yourdomin.com/heartbeat (without the subdirectory) please try |
OK. The behaviour changed from 16.04 to 17. Please remove the option from your webserver configuration. |
Thanks. Installed NC17 on Arch/NGINX, no issues/warnings there. Security setting are in NGINGX site config though, as proposed in https://docs.nextcloud.com/server/latest/admin_manual/installation/nginx.html#nextcloud-in-the-webroot-of-nginx |
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: Marc Gallet <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "set" in the .htaccess of Nextcloud leads to the situation where the headers are set twice! Which leads to warnings in the admin area. Using "setifempty" solves the problem. In the default case where the system admin didn't do anything, Nextcloud will add them automatically. On the other hand, when the system administrator has already set security headers, we should not add ours on top. See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues nextcloud#16893 nextcloud#16476 nextcloud#16938 nextcloud#18017 and discussion in PR nextcloud#19002 Signed-off-by: zertrin <[email protected]>
The headers might already be set by the system administrator at the http server level (apache or nginx) for some or all virtualhosts. Using "always set" in the .htaccess of Nextcloud leads to the situation where the headers might be set twice (once in the default 'onsuccess' table and once in the 'always' table)! Which leads to warnings in the admin area. Adding "onsuccess unset" solves the problem, and forces the header in the 'onsucess' table to be unset, and the header in the 'always' table to be set. NOTE: with this change, Nextcloud overrides whatever the system administrator might have already set See github issues #16893 #16476 #16938 #18017 and discussion in PR #19002 Signed-off-by: zertrin <[email protected]>
After upgrading from NC 16 to NC 17 beta2 settings/admin/overview urges me to set the X-Frame-Options header to SAMEORIGIN in the WEBSERVER? config. No explanation or link is given, docs/admin handbook says nothing. Here is what I see:
So I added it to my vhost config and double checked: It's now twice in the headers, and even then the warning is displayed, so is this an update issue or a regression (see #8207)?
Upon kesselb's request, I use the template to provide information. I omitted irrelevant entries:
Steps to reproduce
Install/Update Nextcloud to 17beta2, have it installed in a subdirectory (here: /cloud), so there are OTHER paths served. Check HTTP headers for URLs inside /cloud and outside /cloud.
Expected behaviour
X-Frame-Options header should be set to SAMEORIGIN by Nexcloud. That IS the case, so all fine for URLs inside /cloud. But no warning should be issued IMHO.
If that warning aims to nudge admins to set the header globally (which is fine also), then if the header is already set globally, it should not be set TWICE.
Actual behaviour
Although X-Frame-Options header IS set to SAMEORIGIN in the server config a warning is issued and URLs within /cloud are served with the twi identical X-Frame-Options header lines.
Server configuration
Operating system: debian 8 'jessie', current
Web server: Apache 2.4.10-10+deb8u15
Database: mySQL 5.5.62-0+deb8u1
PHP version: PHP 7.3.8-1+0-20190807.43+debian8-1.gbp7731bf via libapache2-mod-php7.3
Nextcloud version: 17beta2 (17.0.0.4)
Updated from an older Nextcloud/ownCloud or fresh install: updated from 16.0.4
Where did you install Nextcloud from: Updater app
Signing status: No errors have been found.
Nextcloud configuration: (removed irrelevant parts)
The text was updated successfully, but these errors were encountered: