This is a follow-up on this forum topic:
I have problems with the X-Frame-Options Header with this configuration:
Piwik Widget URL:
The widget won't be displayed in Chrome (e.g. 41.0.2272.76, Mac) due to this error (see console):
Multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, ') encountered when loading 'https://www.mysite.xy/piwik/index.php?module=Widgetize&action=i…e=today&disableLink=1&widget=1&token_auth=123456789'. Falling back to 'DENY'.
about:blank:1 Refused to display 'https://www.mysite.xy/piwik/index.php?module=Widgetize&action=i…e=today&disableLink=1&widget=1&token_auth=123456789' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN, '.
As far a I know this problem appears only in Webkit browsers, other browsers like FF/IE seem to ignore the empty X-Frame-Options Header and display the widget.
My workaround: hack core/View.php and remove line 245
// always sending this header, sometimes empty, to ensure that Dashboard embed loads (which could call this header() multiple times, the last one will prevail)
Common::sendHeader('X-Frame-Options: ' . (string)$this->xFrameOptions);
thanks for looking into this, but the enable_framed_pages option does not seem to change the X-Frame-Options Header for iFrame widgets, still getting the same message in Chrome error console.
now Piwik 2.12.1, Chrome 41, added enable_framed_pages = 1 in config.ini.php
PS. should it be possible for me to reopen this issue? I am new to GitHub, so I can't find the button :)
Did a quick investigation, I can verify that w/ this sort of server config, two identical headers can be sent (I couldn't reproduce the error, though w/ Chrome 43). I couldn't find a way to detect if the web server added a header from within PHP, so I think a config option is the only way to fix this.
@mattab Here is my proposal: we could add a new array option
do_not_send_response_headers that would allow users to prevent response headers from being sent by Piwik.
imho it's good solution here to change apache server config not to send this header, as it fixes the problem. I still leave the issue open but decrease priority
Any solution to this issue?
@citosid yes, we suggest to disable the x-frame-options header in your webserver
Hi @mattab I've also just discovered this issue in my Piwik setup too. However, I don't think your proposed solution (disable the header in Apache) is correct.
The problem is this: my website is actually delivering two separate X-Frame-Options headers, and they are both different. The first one comes from my .htaccess and it has a value of SAMEORIGIN which is what I want/need it to be.
The second one comes from Piwik, I believe, and it has no value at all. It's blank. Which I believe is an invalid response.
It looks like @thilohermann also had this issue too (one valid header using SAMEORIGIN and the other header being empty) - according to his screenshot of his Chrome Console in his post above, which shows the two different header values he's getting ('SAMEORIGIN, ')
So the problem is that I can't simply disable the header outright, as I need it there for security reasons on my website. What I don't need is Piwik creating a 2nd header, and more so with an invalid empty value.
Additional info: I'm running WordPress and using the WP Piwik plugin, and I found that this bogus extra header, generated by Piwik, is only there when I set "Piwik Mode" to "Self-hosted (PHP API)" in the plugin settings. However, if I change Piwik Mode to "Self Hosted (HTTP API)", then the bogus extra header is no longer generated. No idea why. Everything else works perfectly well, and I'd prefer to keep using the PHP API mode if I can.
Any thoughts about why this is happening?