Buttons on the website are missing their style and that turns them invisible all thought they are still there but white and the customers can't see them.
The error is Mixed Content: The page at 'https://.com/mazhe/obleklo/dolnishta.html' was loaded over HTTPS, but requested an insecure stylesheet 'http://.com/theme_options/css/index/'. This request has been blocked; the content must be served over HTTPS.
Your question was not clear enough for me, but I think you can resolve it with add permissions in .htaccess file.
Related
I have a problem on my website developed with TYPO3. The problem is that CSS files and JavaScript and images not working. So many images and other functionality such as the slider are not working.
This is the first issue: Mixed content: load all resources via HTTPS to improve the security of your site
And this is the other issue: Ensure CORS requesting origin matches resource's allowed origin
The problem is because you have loaded the site through HTTPS protocol and images, CSS and JS files are loaded through HTTP protocol.
You have to set the correct protocol in TypoScript Setup configuration :
config.baseURL = https://www.you-site.com/
Then all your resources will be loaded through this URL.
I think that the CORS problem will also be solved with this configuration.
It looks like a recent Chrome update broke this by tightening mixed content (https/http) security policies, and I read that Firefox plans to do this too.
Here's the issue:
Say I set the Secure Canvas URL of my app to https://themediadudes.com/httpstest/
That page contains only a link to Google:
Google
When I view the app on Facebook and click the link, nothing happens. An error appears in the console:
[blocked] The page at https://apps.facebook.com/myappname/ ran insecure
content from http://www.google.com/.
I understand that having insecure scripts/stylesheets etc. on an https page isn't allowed, but a simple link to a different website shouldn't be blocked right?. I assume Facebook is running some scripts which do something with the page before sending the user there? Which causes the error.
If I set the target of the link to _top or _blank it works.
Ideally I want to be able to use a javascript window.location to send the user to this insecure URL, or header('Location: blah'); in PHP. But neither of those work either. And it looks like this is a bigger problem than that if even a simple link to an insecure URL doesn't work.
I thought it may be caused by whatever makes the 'fluid' canvas width and canvas height settings work. But I tried setting both width and height to fixed and the problem still happens.
Does anybody have a solution or workaround, or can anybody at least shed some more light on this?
Thanks
I've been struggling with a similar issue and the answer seems to be that it is not possible at all to reference any non-https resources from within your page tab app. Of course if a google link is all you require then that is simply resolved (as google has a https version of course) but referencing external non-https sites will always turn up this warning/block in chrome
Additionally, I should add that I have noticed that the 'page tab URL' section requires a url to a particular page, whereas the 'canvas URL' needs to link to a directory. This does not seem to be documented and will also give the insecure content message in chrome and prevent the page tab app from loading
For some reason, facebook's safe_image.php script isn't generating thumbnails, properly. It's generating a 1x1 image... even though the correct image is linked in the script's parameters.
Example:
<img class="img" alt="" src="https://s-external.ak.fbcdn.net
/safe_image.php?d=AQBtrCt_Es_KsED0&w=90&h=90&url=http%3A%2F
%2Fwww.southlapatriots.info%2Fimages%2FScamra%2FJayCastilleCouncil2.jpg"
The linked image is correct, but it is still only generating a 1x1 image.
Got the same problem today, in my case was an https issue.
I automatically redirect every http requests to https, and while the browser works this out normally, FB's safe_image.php doesn't. If you have such redirect as well, you may want to disable it for just your og:image file.
I also get into a similar problem. My problem is because of the image name has a "space" in it. so it is not appear in the facebook debugger and also in sharing.
So i fixed the issue by replace space with hyphen("-") through coding part. After that i debug the url in facebook debugger, it appears. That means Facebook wont show the image name with "space". But there is no logical reason behind this. Anyway it will help someone.
For more information check this answer posted by Patrick D'appollonio. It helps me.
Are you using any sort of gzip compression for your images? We are seeing a similar issue, but we compress our image with gzip and set the headers. Browsers are rendering fine, but Facebook is essentially displaying nothing.
safe_image script code doesn't support having a % in the app's image url (which is probably why the image turns into a 1x1 transparent pixel)
so the solution is here . Try to follow the instruction in the first comment by chris
In my case, the directory including genuine targeted images is under ".htaccess" control, in which images being called from external server is prohibited.
Example of blocking ".htaccess" file such as:
<FilesMatch "\.(jpg)$">
SetEnvIf Referer "^http://www.mysite.jp" ref_ok
order deny,allow
deny from all
allow from env=ref_ok
</FilesMatch>
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.
The main page of my mobile web app is a .jsp page. My app requires login (Google App Engine), so there is a Log In button when the user is not logged in and a Log Out button when the user is logged in, all handled by code on the .jsp page.
I load a lot of JS code on the page, so I used a .appcache file to cache that. Unfortunatelly, even though I added my .jsp page to the Network area, the page is being cached in a funny way, ignoring the content server from the server. That means that my Log Out button shows when users are Logged Out and vice-versa.
I tried to add no-cache directives as meta tags, but they are all being ignored.
Ideas?
According to dive into HTML5, the page that references the manifest is automatically included in the manifest.
http://diveintohtml5.ep.io/offline.html
Q: Do I need to list my HTML pages in my cache manifest?
A: Yes and no. If your entire web application is contained in a single page, just make sure that page points to the cache manifest using the manifest attribute. When you navigate to an HTML page with a manifest attribute, the page itself is assumed to be part of the web application, so you don’t need to list it in the manifest file itself. However, if your web application spans multiple pages, you should list all of the HTML pages in the manifest file, otherwise the browser would not know that there are other HTML pages that need to be downloaded and cached.
I have a similar issue, and I think I will end up loading the contents of the page via AJAX.
Caching in appCache is a two stage process: first the cache manifest is checked (in this case, as the page is loading), then if the content of it has changed, that content is reloaded. However, in your case, by that time, the stale page is already loaded and displayed.
The easiest fix would be to specifically exclude the page (but not the .js) from the appCache, so that only the js is cached, and not the page. I sounds like you might have figured that out, as you are trying to do it by putting the page in the network area. Check that that exclusion is correct, as that sounds like the problem, and that html cache attributes are being set correctly on that page.