I'm trying to create a landing page on facebook with the Static HTML application, but the image does not appear in IE8 show only at 9 and other browsers like Chrome and Firefox.
The application link is: https://www.facebook.com/hyundainic/app_128953167177144.
Yet another application that looks like:
https://www.facebook.com/SomosEskimo/app_367456286664440.
This if displayed in all browsers, except that technically I do not know if it's the same.
I'm editing the html / css and occupy absolute and relative positioning, I thought that this could affect and remove it, but the problem persists forever.
Can someone help me with this?
I think the issue is probably that you are using an absolute, non-SSL URL for the image source, and the links you posted to the app use SSL. If you leave the protocol off (example: "//whatever.com/myimage.jpg" instead of "http://whatever" or "https://whatever") the browser will use https when needed.
However, it looks like your image doesn't work over SSL:
https://hyundai.com.ni/img/quickservice-fb.jpg?id=3
You can try viewing your app using http:// and confirm it displays ok in all targeted browsers to see if this is really your issue.
Related
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
On what browsers or user agents that channel URL is actually used, and what for?
I have no intention of having my site to work on Internet Explorer <= 8 (it is an HTML5 <canvas> game, and I am serving everything else as "application/xhtml+xml").
So, if channel is only useful on that old crap, I can gladly get rid of it...
Related (possibly): Channel URL Facebook
Because the social plugin is cross domain call, it needs a way to communicate. The wrokaround is to include a hidden iframe in the page for that. But, with this workaround, that iframe is loaded every time when page loads and will double the traffic reported. This is why channel url was done. What it does, it load the fb js in that page, and from that moment on, the js is available on your domain.
It will improve your loading times (cache) and will fix the reporting issue (you will see in reports channel page reported separately). But is not necessary for any html5 capable browser.
So, if you are using only HTML5 capable browsers, you are safe to ignore that. I am not sure about ie9, I will try to test it with my app by removing channel url and let you know.
Edit: By removing the channel URL from my app, I start getting double traffic reports from IE9. I think that is a good idea to keep the file there, is is just a simple html file with a single line. Better to be safe than sorry.
We are developing an app that makes posts on behalf of our users to Facebook. Within those posts, we want to put links to external (non-Facebook) websites.
Looking at the links in the status bar of the browser (usually Chrome), the correct URL is displayed. However, Facebook seems to wrap the actually-clicked link into some extra bells-and-whistles. Usually, this works correctly.
Sometimes, however, this URL wrapping ends up sending the click to a URL like:
http: //spywaresite.info/0/go.php?sid=2
(added space to make it non-browsable!) which generates Chromes severe warning message:
This happens very occasionally on Chrome, but very much more often in the iOS browser on the iPhone.
Does anyone have any pointers as to how to deal with this?
EDIT
For example, the URLs we put in the link is
http://www.example.com/some/full/path/somewhere
but the URL that actually gets clicked is:
http://platform.ak.fbcdn.net/www/app_full_proxy.php?app=374274329267054&v=1&size=z&cksum=fc1c17ed464a92bc53caae79e5413481&src=http%3A%2F%2Fwww.example.com%2Fsome%2Ffull%2Fpath%2Fsomewhere
There seems to be some JavaScript goodness in the page that unscrambles that and usually redirects correctly.
EDIT2
The links above are put on the image and the blue text to the right of the image in the screenshot below.
Mousing over the links (or the image) in the browser shows the correct link. Right-clicking on the link and selecting "Copy Link Address" gets the fbcdn.net link above (or one like it). Actually clicking on the link seems to set off some JavaScript processing of the fbcdn.net link into the right one... but sometimes that processing fails.
I'm not 100% sure what you're asking here, but i'll tell you what I know:- are you referring to this screen on Facebook?
(or rather, the variation of that screen which doesn't allow clickthrough?)
If you manually send a user to facebook.com/l.php?u=something they'll always see that message - it's a measure to prevent an open redirector
if your users are submitting such links, including the l.php link, you'll need to extract the destination URL (in the 'u' parameter)
If you're seeing the l.php URLs come back from the API this is probably a bug.
If links clicked on facebook.com end up on the screen it's because facebook have detected the link as suspicious (e.g. for URL redirector sites - the screen will allow clickthrough but warn the user first) or malicious/spammy (will not allow clickthrough)
In your app you won't be able to post links to the latter (an error will come back saying the URL is blocked), and the former may throw a captcha sometimes (if you're using the Feed dialog, this should be transparent to the app code, the user will enter the captcha and the dialog will return as normal)
If this isn't exactly what you were asking about please clarify and i'll update my answer
Rather than add to the question, I thought I'd put more details here.
It looks like the Facebook mention in the original title was mis-directed, so I've removed it.
We still haven't got to the bottom of the issue.
However, we used both Wireshark and Fiddler to look at the HTTP traffic between the Chrome browser (on the PC) and Facebook. Both showed that Facebook was returning the correct URL refresh.
Here's what Wireshark showed:
What we saw on Fiddler was that our server is issuing a redirect to the spywaresite.info site:
We are working with our ISP to figure out what is happening here.
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.
I'm trying to cache the mobile Gmail webpage because UIWebView does not cache the content itself (mobile safari does, but not UIWebView).
I tried the methods listed here Reading HTML content from a UIWebView basically saving the html either directly from URLRequest or from UIWebView itself. When I try to put the html saved back into UIWebView it is not the same page!
This is the page that I want to save
alt text http://img39.imageshack.us/img39/5679/screenshot20090830at123.png
This is the page that the html saved will display
alt text http://img39.imageshack.us/img39/8734/screenshot20090830at122.png
If you're loading using loadData:MIMEType:textEncodingName:baseURL: make sure you're setting baseURL correctly - that way, the WebView will know where to look for relative stylesheets and so on.
Edit: For example, if I was saving this page, I'd set the base URL to Just can't seem to fetch the mobile Gmail html, what is wrong?.
That looks like the same page to me, but with different stylesheets attached. If you're just re-displaying identical HTML from your local server, the relative stylesheet paths in Google's HTML would no longer be correct. Also, any AJAX requests meant to run after the page loads would no longer work (both because the relative paths to the scripts would be wrong, and also because Cross-Site Scripting restrictions would prevent them from contacting Google).
Attempting to scrape content from an AJAX-enabled application is no small undertaking. You'd have to replicate a lot of GMail's functionality to truly reproduce the exact page Google presents.