When I try to validate social sharing tags using Linked in Post Inspector I get the following error for any page I submit, but no other information, it gives no clue as to what is wrong:
I found this post:
LinkedIn post inspector encountering server error on https URL
which says there are known issues with the Post Inspector, that post is over a year old is there really no update from Linked In on this?
I also found this:
Validating link in post-inspector linkedin in gives server error
I checked the certificate here:
https://www.sslshopper.com/ssl-checker.html
which reported that the hostname is correctly listed in the certificate.
Any advice on debugging this would be very welcome.
The 520 error seems to be related to Cloudflare, so this is possibly an issue with headers related to SSL - Cloudflare, certificate origin maybe?
I fixed it, finally.
I added the following changes to the web server config (as suggested by Cloudflare support):
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
limit_req zone=one burst=5
But this on it's own did not fix the issue, I also added some Cloud Flare Page Rules (which have sped up page loading), which did seem to fix the issue.
A final update from Cloudflare support is that the Page Rules would have reduced the number/size of cookies and so fixed the issue.
Related
We have a Facebook app that has been around for a long time. It's a page-based app, loading up in an iframe. Of late, it is failing to load, and this error appears in the Chrome console:
[Report Only] Refused to frame 'https://edit.ihouseelite.com/' because it violates the following Content Security Policy directive: "frame-src *.doubleclick.net *.google.com *.facebook.com www.googleadservices.com *.fbsbx.com".
You can see the problem in our test page:
https://www.facebook.com/Test-page-1158553550884937/app/451851288205481
First - this message starts with "Report Only". Does that mean that this error is not really an error, but perhaps an indication of future problems?
Assuming that it really is an error, how do I fix it? It seems like the CSP is something set by Facebook, so they only permit specific domains to load up in iframes within a Facebook page. Or am I reading that incorrectly? I figured that setting the domain in the App Settings (basic) would adjust the CSP, but it doesn't seem to have done that. We have a couple thousand customers who are using our app, so I would really like to figure out how to fix this. All suggestions welcome.
Yes it's a CSP of facebook, it publishes two CSPs: content-security-policy and content-security-policy-report-only, you can see it in the Dev tool:
Using CSP in Report-Only mode, facebook just test something, there is no real blocking just violation reports sending.
Facebook's CSP cannot be affected just like that, but when creating a legitimate application, facebook should automatically add app's domain to the frame-src directive.
I've been trying to get to bottom of this problem for a few hours but I can't seem to fix it, I've seen other questions similar to this and tried to use those to implement a fix for my problem but to no avail.
I've built a facebook contest canvas app which displays fine independantely but when I link it to a facebook page (as a link to a new contest) chrome no longer displays is and gives the following warning:
The page at 'https://www.facebook.com/contest/app_xxxxxxxx' was loaded over HTTPS, but ran insecure content from 'http://mydomain.com/': this content should also be loaded over HTTPS.
I've learned partly by trawling this site that the chrome security is fussier, and the app loads correctly, without errors in FireFox and IE but I can't find any resources that are loaded from a non https source.
I have been through with firebug checking in the net tab and checked that all of the loaded resources are using https (the png images, the jpg images, the css files and the jquery js files which are all hosted on the same server that has the certificate), I have even tried hosting the transitional dtd doc itself but nothing seems to make the warning go away and the app display correctly.
In the other similar questions it seems that there are either resources sourced from non-https sources or there are ssl switches used in the javascript library for facebook passed before the fb init.
The problem is that I am using only the php sdk not the js one (although I am using version 1.9 of jquery, hosted on my server) and I could find no similar ssl specific settings there.
If someone could give me a tip about how I could investigate further, what I might be missing or is familiar with this issue I'd be interested to hear about it.
Thanks a lot.
David
Facebook requires the app to come from https:// you need an ssl certificate on your server and to enable ssl. in the Facebook app settings change secure url to https://mydomain.com url
I did have a similar issue recently (but it only caused issues on IE10) and I resolved that by adding P3P header
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT');
Found the solution!
In the facebook app settings, if the page tab url is specific to a page e.g. https://www.mydomain.com/index.php, chrome doesn't complain with the insecure content message but if you reference a directory the error is propogated. I found this confusing since the 'canvas' urls need to be directories.
I hope this answer will save someone a few hours! :)
Humbly asking for any assistance people have time to give me on this one. Let me start by saying that I am aware there are previous questions about this on this site and elsewhere on the web; I have read a lot of them, and they are either unanswered/resolved, had a particular cause that doesn't apply to me, or suggests things I have already done.
Over the past few days, Facebook has suddenly stopped scraping my website posts successfully, so when I paste a link into Facebook it pulls nothing through - no thumb or description. I run the links through the FB lint/debugger, and it alternates between 403 and 503 response codes, but mainly 403. Previous links that Facebook has cached/successfully scraped still display with thumbs and desc, but still present as a 403 or 503 response.
My site is http://21stcenturyburlesque.com
One of the new URLs I have been testing is : http://21stcenturyburlesque.com/the-burlesque-top-50-2013/
I have checked with the server/host people. Nothing has changed, everything fine.
I have tried with the default wordpress theme. No change.
I have read threads about Bullet Proof Security causing issues, although why it suddenly would I don't know. It was deactivated on my site anyway, but I went through the removal process to remove the htaccess file with the BPS code in it. I have then run debug without an htaccess file present, and with a very basic htaccess present. No change.
Hotlinking protection is disabled in my cpanel.
I have experimented with adding/removing www. and / when I paste the link into lint as someone suggested. No change.
I use Facebook OGP Wordpress plugin. I spoke to the creator and he says the plugin is working as it should and to contact my host/server. See bullet one.
I tried creating a new FB App and using the new App Id number with the OGP plugin. No change.
Checked the cpanel error log. This came up three times tonight:
[Fri Nov 01 21:47:53 2013] [error] [client 193.242.149.35] File does not exist: /home/**/public_html/403.shtml
There are a few other things I ruled out but I've been at this for so long I can't remember all of them, so if someone suggests something else I've tried then I apologise for not mentioning it here in advance.
If anyone can suggest anything else, I would really appreciate it. I manage to fix most technical problems I come up against, but this has stumped me and my much more experienced colleague and it is really affecting my clickthrough rates and site traffic. If it comes down to adding things to my htaccess file, I would appreciate guidance on what to add/remove. Many thanks in advance.
I had the same problem. Drove me crazy for hours (maybe days). In your FB app settings make sure that the top Facebook url has http://
When I deploy my facebook app to a remote dev I seem to get a blank signed request returned but only in IE, any ideas on if this is a known IE bug?
Yup, this happens because of p3p policy and how internet explorer behaves with that. You can fix it by sending the following header data in your web application.
P3P: CP="CAO PSA OUR HONK"
You can find a detailed post on this in the following URL
http://hasin.wordpress.com/2011/09/30/story-about-blue-e-iframed-web-application-wastage-of-6-hours-and/
Hope it will help.
I'm implementing the facebook Comments plugin on my site. Users get the warning "Show all content" in IE9
This other publisher using the same plugin and it does not bring up the warning.
Can some please help me with this?
Asking users to turn of the mixed content warning in their IE9 is not an option.
We were just looking at this today and our workaround for now was to include the Facebook Library over https (even when the page itself is viewed over http). Although not ideal it gets rid of the mixed content warnings in IE9 until they have fixed their bug.
That seems to be how it was accomplished at www.vg.no linked in the original question, the library is linked via https.
From their code:
<script src="https://connect.facebook.net/nb_NO/all.js"></script>
I have the same problem:
I have a page that's 100% http. But, the facebook javascript (which I call over http), is returning assets (.js, images) over https, which is generating security warnings for IE(9) users.
I have figured out it's the comment widget from Facebook (
Here's an example of a live page on http: with the error:
http://app.gophoto.com/p?id=10173&rkey=CD01891B287792415384&s=1&a=6940
Here's one of the assets that Facebook returns over HTTPS
https://s-static.ak.facebook.com/rsrc.php/v1/y8/r/7Htnnss1mJY.js
(I'm unable to comment (for some reason?) on Joel's answer. But, his suggestion to fetch the initial all.js over https on http sites does not actually work. I've tried it, and it also inherently looks incorrect since even the initial js fetch violates the mixing up of http & https content.)