I have recently encrypted a site for a client and am finding some people get insecure site warning in Chrome with the triangle icon.
My major problem tho is that the contact form php processor has a:
header('location:https://www.bioloo.co.nz/index.php/thanks');
but viewers get the warning instead of to the Thank You page. My webhost reports the certificate is valid and all absolute urls are set properly.
Do I have to set a no-cache tag?
Any ideas please?
Related
I found that anybody show their page to user, then 302 redirect to my site,
I want stop it.
I thought there would be referer in request header, but didn't!
I tested this in chrome72.0.3626.121 and ie11, and use fiddler to catch Request,
there have no referer header in all request.
And my server side code can't see referer too.
How can I stop 302 redirect to my site??
It's possible these days for sites to disable adding a referrer when a user follows a link. This is a privacy feature.
The result of sites using this feature is that you can't tell if:
A) A user opened your site directly from the addressbar
B) A user came to your site from somewhere else.
If you could tell the difference, it means the privacy feature is not working. Your only option is to block anyone with no referrer header, but then you might block a lot of other users as well.
There is one other common reason for this though, if you are running an insecure (http) site and you are being linked from secure (https://) site. It might be possible to get the referrer back in this case by upgrading your site to https.
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! :)
I have a web form which I have recently secured with an SSL Certificate.
Since installing the certificate, the form behaves differently - when it was unsecured http it would give an error message if any required field was not filled in eg "This field is required". However, as a secured https page it doesn't give this error message any more and it is possible to submit the form whether the fields are filled in or not.
I'm a little confused because nothing else has changed other than the form page is now secured https.
Any advice on why this might be and how I could fix it would be much appreciated. Many thanks!
If you are using JavaScript for validation, Open the web page with either Google Inspect or Firefox Firebug, Check whether any of the java script is blocking or not... Its looks like some of the .js file is not loading properly.
If the validation are using ASP.NET validator, then there shouldn't be any issues.
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.
Problem
I have an application driving a tab on a client's page. The application works correctly if the user has not enabled FB's "secure browsing" feature. If attempting to view over HTTPS, the iframe doesn't even appear (no errors, no mixed-content warnings). When correctly loading over HTTP, the div with the id "pagelet_app_runner" has an iframe inserted into it and the application content is loaded inside there. Over HTTPS, this div remains empty and the iframe is not inserted into the page. There are no Javascript errors appearing in Firebug or Chrome's equivalent console.
Why I'm Asking Here
The host has a valid SSL certificate and there is no 'mixed content' at the URL in question. I can successfully view the content over HTTP or HTTPS by visiting the URL directly, and I can do the same by visiting apps.facebook.com/canvasURL/tabURL. It is only when attempting to view within a Page Tab that the HTTPS load fails as described above. My application is configured with both regular and secure canvas and tab URLs.
Attempted Debugging
I've recorded some sessions with Charles but since the iframe isn't being inserted into the page, I think I'm coming at the problem after it's already occured. I'm no Charles expert so happy to be corrected here.
Apache isn't seeing any request (in either regular or ssl logs) for the affected loads. non-SSL loads come through as expected in access_log.
Plea for Help
I'm out of ideas for debugging this. Does anybody have any suggestions? What really obvious and stupid mistake might I have made? :)
edit: nicer formatting
Your app canvas URL is https://skinnycomp.nextstudio.com.au/skinnycowcomps/ , which send 404 error to Facebook proxy (request is going through proxy when viewing app via tab), also when viewing your app via apps (https://apps.facebook.com/122381834451561/), again 404... maybe Facebook proxy is ignoring 404 and posting blank...
Try changing canvas URL to https://skinnycomp.nextstudio.com.au/skinnycowcomps/tab, also you can check if your app is accessed via page tab, in signed_request there should be page_id...
23:51:15.379[549ms][total 1667ms] Status: 404[Not Found]
GET https://skinnycomp.nextstudio.com.au/skinnycowcomps/
This is a real longshot since I'm sure you've triple checked all the settings, but the blank page can happen if an invalid url is specified in the Page Tab URL field in the app settings. Since it only happens on https, it would imply something specifically with the Secure Page Tab URL entry. It might be worth checking that again, and maybe even re-saving it or changing it to something else to see if it helps.
I was using relative URLs for the regular and secure tab URL fields. From memory relative URLs here were mandatory at some point in the past. It appears now that a relative URL will still work for HTTP but not for HTTPs. Fix: absolute URLs. Hopefully FB update their field validation to match what's required too.