I'm having trouble with the Facebook Chat plugin, it doesn't display in Safari, Firefox and Edge. I get the following error:
Refused to load https://www.facebook.com/v5.0/plugins/custo.......... because it does not appear in the frame-ancestors directive of the Content Security Policy.
I have created a content-security-policy for my site in the .htaccess file, but it still doesn't work. In safari, Edge or firefox, but works in Chrome:
# always follow the symlinks
Options +SymLinksIfOwnerMatch -MultiViews -Indexes
# X-Frame-Options to prevent clickjacking
Header always append X-Frame-Options SAMEORIGIN
# if you want to use mod_rewrite, set this 'On'
RewriteEngine On
<IfModule mod_fcgid.c>
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>
# Added by me
# Apply a CSP to all HTML and PHP files
<FilesMatch "\.(html|php)$">
Header set Content-Security-Policy "
default-src 'self' *.googleapis.com *.facebook.com *.marchex.io;
script-src 'self' *.cloudflare.com *.facebook.com *.marchex.io;
font-src 'self' *.googleapis.com *.gstatic.com;
img-src 'self' *.marchex.io ;
object-src 'none';
frame-ancestors 'self' *.facebook.com;
child-src 'self' *.facebook.com;
</FilesMatch>
# Block pages from loading when they detect reflected XSS attacks
Header always append X-XSS-Protection: 1; mode=block
# Prevent browsers from incorrectly detecting non-scripts as scripts
Header always append X-Content-Type-Options: nosniff
# Only connect to this site via HTTPS for the two years (recommended)
Header always append Strict-Transport-Security: max-age=63072000
#End of added by me
The Policy does work. If I just set default-src 'self' it stops a lot of content loading.
These are my response headers....
`Alt-Svc: quic=":443"; ma=2592000; v="39,43,46", h3-Q039=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-23=":443"; ma=2592000, h3-24=":443"; ma=2592000
Connection: Keep-Alive
Content-Encoding: br
Content-Length: 11870
Content-Security-Policy:
Content-Type: text/html; charset=UTF-8
Date: Mon, 16 Dec 2019 20:04:04 GMT
Referrer-Policy: origin
Server: LiteSpeed
Strict-Transport-Security: max-age=63072000
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: PHP/7.2.23
X-XSS-Protection: 1; mode=block`
Response Header from xfbml.customerchat.js
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-FB-Content-MD5
Alt-Svc: h3-24=":443"; ma=3600
Cache-Control: public,max-age=1200,stale-while-revalidate=3600
Content-Encoding: gzip
Content-Length: 73449
Content-MD5: 8glO44XsX1jOvEMLr37fng==
Content-Type: application/x-javascript; charset=utf-8
Date: Tue, 17 Dec 2019 16:51:17 GMT
ETag: "b96fb1ac645c4245492e2e35d1627232"
Expires: Tue, 17 Dec 2019 16:56:31 GMT
timing-allow-origin: *
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
x-fb-content-md5: e5d959939884b2030aba9a10101ef030
X-FB-Debug: X9f8fXUbI3MWGY8fKbKU98NkUhySqg+nshcn558TJFwxM2bgY4LaM8EjYRDH6Xh8IAqLfy9ogGBJxapQigrJMw==
X-Frame-Options: DENY
Response headers from customoerchat.php....
Alt-Svc: h3-24=":443"; ma=3600
Cache-Control: private, no-cache, no-store, must-revalidate
Connection: keep-alive
Content-Encoding: br
content-security-policy: default-src * data: blob: 'self';script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
content-security-policy: frame-ancestors https://mobilityservicesdirect.co.uk;
Content-Type: text/html; charset="utf-8"
Date: Tue, 17 Dec 2019 16:51:32 GMT
Expires: Sat, 01 Jan 2000 00:00:00 GMT
facebook-api-version: v5.0
Pragma: no-cache
Strict-Transport-Security: max-age=15552000; preload
timing-allow-origin: *
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-FB-Debug: P15E80pV8ZDmxEWhS4vE6VS4t9QYOE6dWQE9fZmdN24rvueuAYl4SvNeTO5+6iSJpLNoBOHPO/mZWV4riQuKoQ==
X-XSS-Protection: 0
The website is here if it helps.
Any help greatly appreciated!
The frame-ancestors directive is about who is allowed to frame a certain page, in this case it is the CSP of the chat bot that prohibits your page to frame it. Applying a CSP on your page doesn't change that.
According to the Troubleshooting Tips on the bottom of this page https://developers.facebook.com/docs/messenger-platform/discovery/customer-chat-plugin/ you must:
Check that the domain of the page the plugin is being rendered on has been whitelisted.
Make sure you didn't set the Referrer-Policy header to no-referrer.
Related
I have a page the includes an iframe.…
<!DOCTYPE html>
<html>
<body>
<!-- … -->
<iframe
src="/assets/js/pdfjs/web/viewer.html?file=2021-09-12_1200-file.pdf#zoom=page-width"
style="..."
></iframe>
<!-- … -->
</body>
</html>
That includes the following response headers…
HTTP/1.1 200 OK
Date: Tue, 26 Oct 2021 11:02:17 GMT
Server: Apache/2.4.38 (Debian)
X-Powered-By: PHP/7.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
X-DEBUGKIT-ID: 77761443-2882-4882-b0e1-01eea68deded
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 2349
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
If I change the file path in the iframe src attribute (e.g /assets/js/pdfjs/web/viewer.html?file=2021-10-26_1200-file.pdf#zoom=page-width - note the new timestamp), and reload the page, the old file is still returned, rather than the new one, despite the Cache-Control: no-store, no-cache, must-revalidate header.
Debugging the requests recevied by the server, I can see…
The parent page is requested and returned with the headers as above (with new Date & X-DEBUGKIT-ID header values), and the correct, updated iframe src value.
The iframe page is being requested with the original filename, rather than the new one (I'm assuming from the cached page).
If I reload using Cmd+Shift+R (to ignore the browser cache), then the correct iframe document is loaded.
What am I missing in this setup that is causing the page to be cached? I thought that the Cache-Control header we have should be sufficient here.
If I add a random query string to the parent page this correctly loads new documents, but I feel this is a hack that should not be needed.
I've also tried adding a Etag header containing a random string that's different for each request, but this seems to have no effect on the browser caching.
I am trying to add an IFrame to a page.
The page:
https://www.homedepot.com/order/view/tracking
The code I'm using to add this IFrame:
function createElementFromHTML(htmlString) {
var div = document.createElement('div');
div.innerHTML = htmlString.trim();
// Change this to div.childNodes to support multiple top-level nodes
return div.firstChild;
}
element = createElementFromHTML(`<div id='testing-iframe'>
<iframe src='chrome-extension://zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz/index.html'></iframe>
<div>`)
document.body.appendChild(element)
Now, notice the URL starts with chrome-extension://. Different protocol.
On the above homedepot.com page, when I inspect #testing-iframe, I see no IFrame. It's like the browser rejects the element.
On most other websites on the internet, such as https://example.com/, the IFrame element shows on inspection (no content though, as this is a dummy URL).
Please see screenshot:
See, on example.com I do get an IFrame. On homedepot.com I don't.
Another thing to point out, as said earlier this happens when I'm using a different protocol, chrome-extension. But, when I'm using an HTTPS URL such as https://www.texasauto.com/ it DOES WORK, on both pages.
So far regarding the problem.
My question is: What's causing it?
I assume this is some HTTP header.
First I was suspecting the Strict-Transport-Security header.
So, I tried to disable it with another extension, but it didn't fix it.
Then I tried to disable more headers, and also add the Access-Control-Allow-Origin: * header, yet it didn't work.
Any idea what's causing the problem?
Edit: Headers returned by homedepot.com:
access-control-allow-credentials: true
access-control-allow-headers: Authorization, Content-Type
access-control-allow-methods: POST, GET, OPTIONS, DELETE
access-control-allow-origin: http://localhost:8081
access-control-max-age: 0
cache-control: max-age=0, no-cache, no-store
content-encoding: gzip
content-language: he
content-type: text/html;charset=UTF-8
date: Sat, 29 May 2021 22:16:06 GMT
expires: Sat, 29 May 2021 22:16:06 GMT
pragma: no-cache
server-timing: cdn-cache; desc=MISS
server-timing: edge; dur=153
server-timing: origin; dur=75
set-cookie: AKA_A2=A; expires=Sat, 29-May-2021 23:16:06 GMT; path=/; domain=homedepot.com; secure; HttpOnly
strict-transport-security: max-age=86400; includeSubDomains; preload
vary: Accept-Encoding
x-akamai-transformed: 9 153137 0 pmb=mTOE,1mRUM,2
x-application-context: orders-purchases-ui:prod:8080
x-content-type-options: nosniff
x-device-type: desktop
x-frame-options: SAMEORIGIN
x-proto: secure
x-tm-zone: us-east4-a
x-xss-protection: 1; mode=block
I want display inline a pdf into iframe. It works on Chrome but not on Firefox (latest).
HTML
<iframe src="/3.pdf"></iframe>
Server HTTP response (see content-disposition: inline)
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
vary: Origin
access-control-allow-credentials: true
content-disposition: inline; filename=3.pdf
content-type: application/pdf
date: Fri, 20 Sep 2019 10:56:36 GMT
connection: close
transfer-encoding: chunked
result
You could try to use embed or object tags, like this:
<html>
<body>
<embed src="/3.pdf" width="500" height="375">
</body>
</html>
I have a Typo3 website (version 4.5.32). Sometimes (randomly) when I'm surfing around my website the browser shows the html code instead of showing the webpage.
For example it shows:
HTTP/1.1 200 OK
Date: Thu, 12 Feb 2015 11:36:29 GMT
Server: Apache
Set-Cookie: fe_typo_user=f4b8445b0719bd7490dcde98e7d8ff5b;
path=/; domain=.<my_domain>
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
bfee
<!DOCTYPE html>
<html lang="es-ES" xmlns="http://www.w3.org/1999/xhtml">
...
</html>
<!-- Cached page generated 12-02-15 12:35. Expires 13-02-15 12:35 -->
<!-- Parsetime: 0ms -->
0
when it should show the webpage.
Another example:
HTTP/1.1 200 OK
Date: Thu, 12 Feb 2015 11:41:19 GMT
Server: Apache
Set-Cookie: fe_typo_user=fd0199b1f48b719c097ef19418f18397; path=/; domain=.<my_domain>
Expires: 0
Last-Modified: Thu, 12 Feb 2015 11:41:19 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: be_typo_user=71e6061cabf0d60a03739493561b67d9; path=/
Vary: Accept-Encoding,User-Agent
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
9395
<!DOCTYPE html>
<html lang="es-ES" xmlns="http://www.w3.org/1999/xhtml">
...
</html>
<!-- Cached page generated 12-02-15 12:37. Expires 13-02-15 12:37 -->
<!-- Parsetime: 111ms -->
0
Thanks.
The extra character before the actual output (bfee, 9395) are the lengths of the following block of data. The header Transfer-Encoding: chunked also indicates that the output is cut into blocks (chunks).
All user agents (browsers, etcetera) must support chunked transfer encoding. Perhaps there is some proxy in between that ruins the experience? Anyway, it's the webserver that decides to use this transfer encoding and not TYPO3.
The only thing inside TYPO3 that could ruin things is when the content is retrieved using t3lib_div::getUrl(). This function only supports chunked data if you have cURL activated in the installation.
I have a problem with a website, where sometimes only the HTML text is displayed in the browser window, instead of the rendered HTML page. This happens sometimes in all browsers.
Example URL:
http://www.starkl.at/view/p-1258/Newsletter---Gartentipp/
The HTTP request headers from IE9 are (Cookies are not shown):
GET http://www.starkl.at/view/p-1258/Newsletter---Gartentipp/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://www.starkl.at/view/p-1931/Service/
Accept-Language: de-AT
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
DNT: 1
Host: www.starkl.at
Pragma: no-cache
The HTTP response headers are:
HTTP/1.1 200 OK
Date: Wed, 19 Sep 2012 07:43:49 GMT
Cache-Control: no-cache, no-store, must-revalidate, proxy-revalidate
Content-Type: text/html;charset=UTF-8
Content-Length: 21160
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Also the content length (in bytes) seems to match.
It's a Java 6/7 application running on a Tomcat 6/7, with an additional httpd 2.2.x in front.
Any idea what the problem could be????
Thanks in advance!
If the browser writes the code and not renders it is because it's being told to do so, probably your app is returning html encoded in a way that browser thinks it's plain text.
Open tools, options, email, email options, then uncheck "Read all standard mail in plain text." This is for Outlook 2003 so your version, if not 2003, might be slightly different.