You need to log in before you can comment on or make changes to this bug.
If you enable "Secure Browsing (https)" in your Facebook Account Settings iframes on pages will cease to function.
It's also broken if the user just happens to hit the https page rather than http (even if an https canvas URL is provided in the app settings) To repro just go to https://www.facebook.com/hatchlings and click "Easter Egg Hunt" on the left-hand menu.
Thank you for the report. It appears that a url was added the Secure Canvas URL, however the cert is not valid. Please reopen if you can repo with a valid cert. To see the error, please go directly to your https canvas URL.
Jason - the cert is valid (the canvas page works with https, check https://apps.facebook.com/egghunt ) I think what you are seeing is that there are resources that are not secure on the page -- if this is an issue shouldn't it also be when showing the regular https canvas page?
I changed the page to a test page that contains no unsecure resources and the error is the same. https://www.hatchlings.com/egghunt/basketPage.php https://apps.facebook.com/egghunt/basketPage.php
Created an attachment (id=3644) [details] Screenshot
(From update of attachment 3644 [details]) The following URL is the only insecure URL when loading my iframe tab over SSL http://static.ak.facebook.com/platform/page_proxy.php?v=2#app_runner_fb_https_4d5ab6867f4311052663858
Thanks for the additional information. I'm seeing the same issue -- we will look into this.
I have been seeing this also. Here is an example: https://www.facebook.com/pages/Faceil-Page-Sandbox/115660408455793?sk=app_170626422983021
Any ETA on a fix for this bug?
No ETA yet, but it is active, and assigned to engineering to investigate.
*** Bug 15209 has been marked as a duplicate of this bug. ***
A note for the debuggers: No request is ever made to the canvas URL when accessing the app running in a tab. When running from the app's own page, the canvas is called up OK, but in a tab, running SSL, we never see a FB request for the page on our servers.
Probably the same issue as http://bugs.developers.facebook.net/show_bug.cgi?id=15317 This issue also is also present on the current beta tier ('HPHP - 277 - Ha7w-2J2peEIe3VJ5Oy74A - 2239008').
See also: http://bugs.developers.facebook.net/show_bug.cgi?id=15379
*** Bug 15317 has been marked as a duplicate of this bug. ***
*** Bug 15379 has been marked as a duplicate of this bug. ***
I didn't want to lose the detail I added to my duplicate bug submission. Firebug identifies the problem in that the proxy script that Facebook renders is setting the document domain to "http://facebook.com" rather than "https://facebook.com" if the user has SSL enabled. Break on Error Permission denied for <http://static.ak.facebook.com> (document.domain=<http://facebook.com>) to get property Window.PlatformAppController from <https://www.facebook.com> (document.domain=<https://facebook.com>). All browsers are prohibiting the proxy script from talking to the "Window.PlatformAppController" because the script is being served via HTTP while the window is HTTPS. Hope you guys can fix this soon. Thanks!
(In reply to comment #0) > If you enable "Secure Browsing (https)" in your Facebook Account Settings > iframes on pages will cease to function. ? Will it still fail if you have an ssl cert on the iFrame URL?
Paul - yes.
Guys, is there any progress on this? It's going to become a bigger deal as people are moving to iframe....
*** Bug 15422 has been marked as a duplicate of this bug. ***
Any chance of a fix for this getting rolled out with the fix for 15166? http://bugs.developers.facebook.net/show_bug.cgi?id=15166
Unfortunately this is a different bug. We're making good progress on the fix, but do not have an ETA on a release yet.
Thanks Jason, my support team tells me we've had quite a few users complaining about "blank pages" related to this. I wish there was at least some sort of error message to let them know what the problem is. So far our only response has been to tell them to turn off the secure browsing setting but that's not ideal with things like Firesheep floating around out there.
(In reply to comment #26) Same for us - users think it's the app at fault. Be great to get this one fixed.
Created an attachment (id=3765) [details] Tab URL hardcoded to HTTP Only on Facebook Integration It appears that the tab url setting on the facebook integration page may be causing this problem. You can put in a secure and non-secure URL at the top, but the Tab URL setting is hardcoded to http:// only
Ok, so you mean I am now using your new cool iframe thing because you told me to and it is broken.... very sad. Is there a work around using fbml?
Don't be a Facebook platform developer and an early adopter at the same time! I just found out that iframe applications don't work in Internet Explorer at all! This is getting more and more ridiculous by the minute! Facebook advertised their great iframes to developers but failed to mention: - iframes do not work over HTTPS - iframes do not work on pages with old layout - iframes do not work in Internet Explorer - iframes do not work if users are not logged in I am terribly disappointed! My app is broken now and I am losing users!
(In reply to comment #30) > Don't be a Facebook platform developer and an early adopter at the same time! > > I just found out that iframe applications don't work in Internet Explorer at > all! Actually my contest works fine in IE: http://www.facebook.com/rcwilley?sk=app_149694955091858 however I had to hack around the fact that my session cookies were getting blocked on some clients because of IE's 3rd party cookies policy (not facebook's fault). I had to post all the data all the way through. However amen to everything else you said. So surprised that a critical bug like this should languish for 14 days... Ugh!
(In reply to comment #11) > Any ETA on a fix for this bug? hey guys, im new at bugtracker - could u xplain me what ETA is? thx
I have the same issue...my iframe tab is not working with HTTPS.
Please add my vote. Some of my clients are https folks. This will cause problems. Thanks.
(In reply to comment #32) > (In reply to comment #11) > > Any ETA on a fix for this bug? > hey guys, im new at bugtracker - could u xplain me what ETA is? thx ETA means "Estimated Time for Arrival" or "When is this going to be fixed?"
big vote for this bug... pretty horrible. It can't be difficult to force https for your page_proxy.php script. It's very clearly no fault of the tab/canvas url, and now that you're pushing people to activate the forced https setting in accounts you're essentially disabling page tabs across the board until this is fixed. Unsafe JavaScript attempt to access frame with URL https://www.facebook.com/thesafechoice?sk=app_193093747379875 from frame with URL http://static.ak.facebook.com/platform/page_proxy.php?v=2#app_runner_fb_https_4d6d6081de8ad0175265577. Domains, protocols and ports must match. Unsafe JavaScript attempt to access frame with URL http://static.ak.facebook.com/platform/page_proxy.php?v=2#app_runner_fb_https_4d6d6081de8ad0175265577 from frame with URL https://www.facebook.com/thesafechoice?sk=app_193093747379875. Domains, protocols and ports must match. Please fix this!
I have the same issue.
2 hands up vote on this issue as well! There are more people going https. i see people posting it everyday on their feeds. We need this fixed asap. My clients are jumping!!!!
I have the same problem.
Same problem for me. Is there a workaround that we can use until this bug gets fixed?
I have the same issue, desperately need this fixed! More and more people are switching to https... Please VOTE!
(In reply to comment #35) > (In reply to comment #32) > > (In reply to comment #11) > > > Any ETA on a fix for this bug? > > hey guys, im new at bugtracker - could u xplain me what ETA is? thx > > ETA means "Estimated Time for Arrival" or "When is this going to be fixed?" @mike thx btw, i have the same problem.
Why has this bug not even an importance yet? Isn't it important enough that everyone can see the new iframes??
If you scroll through the comments, Facebook HAS acknowledged that this is a bug and that they're working on it. They have indicated that the fix is non-trivial an we have to take their word on that. That said, it would certainly be appreciated if Facebook (Jason? Anyone?) would post an update. As for everyone else, keep the votes for this bug coming in.
We believe we have identified the issue and are testing a fix. If all goes well we expect to deploy this on the Beta tier Sunday evening, and, into production Tues evening. More information on testing against beta here: https://developers.facebook.com/blog/post/438/ (note: we've been treating this as a P2 since it was opened)
(In reply to comment #45) > We believe we have identified the issue and are testing a fix. If all goes > well we expect to deploy this on the Beta tier Sunday evening, and, into > production Tues evening. More information on testing against beta here: > https://developers.facebook.com/blog/post/438/ > (note: we've been treating this as a P2 since it was opened) Thank you... Looking forward to testing.
I noticed that when in HTTPS mode, some app show a warning from Facebook ("Switch to HTTP?"). How can I reproduce this and why is this only on certain app? (Example at https://apps.facebook.com/tacobellhaloreach/teams.php)
Ebpo, the example you just posted is an HTTPS CANVAS APP, not an in-tab profile page app. The problem occurs when you add an IFRAME-based app to your fan page and then try to view that tab with Facebook SSL enabled. When they serve IFRAME-based profile apps, Facebook first serves up a proxy script that performs an HTTP POST to your application. That proxy script is being served by static Akamai servers. The script tries to talk back out of the IFRAME to the parent Facebook page but this violates the same-source rule. The reason these types of apps might be hard to come by is that most developers haven't switched off of FBML (which works via SSL because there is no IFRAME and no proxy script). If we switch our app to IFRAME, it'll break because many of our users have SSL enabled all-the-time as a security precaution.
Yes, I can confirm this bug also. Id like to ask facebook to consider having programmers "at the ready" when they make such a huge architectural change. Its difficult enough to get things running and with facebook bugs it makes it even harder.
(In reply to comment #45) > We believe we have identified the issue and are testing a fix. If all goes > well we expect to deploy this on the Beta tier Sunday evening, and, into > production Tues evening. The fix has not been deployed to the Beta tier yet, right?
It doesn't appear this went into beta yesterday. This is a pretty serious problem - please fix it soon!
We confirm the problem also. In SSL mode, the application can't be viewed from a "fan page". Best regards,
The severity of this bug is increasing now that Facebook is actively prompting users to upgrade to SSL all-the-time. No one denies that SSL all the time is good for users - so long as this bug is fixed as soon as possible! Jason, or anyone at Facebook, can you give us an update? It sounds like the fix didn't make it to Beta Tier last night.
Jason- I can also confirm that the fix did not roll out in beta: https://beta.facebook.com/KenHoodTV?sk=app_138343182899713 I'm sure you guys are working frantically to fix this. Could you pop into the thread and just confirm that it is still a priority (I know... it says P2 still) and more importantly.. a next eta for beta fix? We have clients eating us alive right now. :)
As per everyone else above this has not been fixed in the latest beta push. Why? Can we please get some information on this? We were required to develop our latest tab in this method but now are getting a ton of pressure as to why it doesn't work for some users (most of them don't even know they are using the https version!).
Yes, I too would like to see this fixed.
Jason and team... we have liftoff. It's working now in beta... thanks so much. https://beta.facebook.com/KenHoodTV?sk=app_138343182899713
imho it's still buggy, because while displaying the iframe, depending on your browser's security settings you will get lots of warnings because in fact the connection will be partially unencrypted: s-static.ak.beta.facebook.com (ssl_error_bad_cert_domain) is not secure. And of course in case you are using social plugins, e.g. a like button pointing to a canonical non-secure url, it will warn again. So the client has to allow explicit security exceptions several times. The latter obviously already happened in old fbml.
(In reply to comment #58) > imho it's still buggy, because while displaying the iframe, depending on your > browser's security settings you will get lots of warnings because in fact the > connection will be partially unencrypted: > > s-static.ak.beta.facebook.com > > (ssl_error_bad_cert_domain) > > is not secure. Oh, I just checked: after allowing s-static.ak.beta.facebook.com it tries to load the iframe already from the non-secure canvas url, only with https a protocol prepended, e.g. in our case: https://www.blacktrash.org/fb/blacktrashproductions/ instead of, as per given settings: https://blacktrash-org.prossl.de/fb/blacktrashprodutions/ I'd still call this a bug.
(In reply to comment #59) > (In reply to comment #58) > > imho it's still buggy, because while displaying the iframe, depending on your > > browser's security settings you will get lots of warnings because in fact the > > connection will be partially unencrypted: > > > > s-static.ak.beta.facebook.com > > > > (ssl_error_bad_cert_domain) > > > > is not secure. > > Oh, I just checked: after allowing s-static.ak.beta.facebook.com it tries to > load the iframe already from the non-secure canvas url, only with https a > protocol prepended, e.g. in our case: > > https://www.blacktrash.org/fb/blacktrashproductions/ > > instead of, as per given settings: > > https://blacktrash-org.prossl.de/fb/blacktrashprodutions/ > > I'd still call this a bug. Similar behaviour happens when you are using e.g. fb:recommendations on your site which points to a non-secure canonical url (which you have to, otherwise recommendations won't be accumulated). People who do care about secure connections and do just want a https prepended will not see your page - unless you turn fb:recommendations off for https. But then, why would you even care to load the connect script from a secure connection? http://bugs.developers.facebook.net/show_bug.cgi?id=15642 So the choice seems to be: either cheat the audience into _believing_ they are secure (most people won't care) or not letting them see anyting. As this is already the case for fbml, one could argue that it would be more honest and less dangerous to adivise: do not use Facebook over a secure connection!
(In reply to comment #58) > imho it's still buggy, because while displaying the iframe, depending on your > browser's security settings you will get lots of warnings because in fact the > connection will be partially unencrypted: > > s-static.ak.beta.facebook.com > > (ssl_error_bad_cert_domain) > > is not secure. And of course in case you are using social plugins, e.g. a like > button pointing to a canonical non-secure url, it will warn again. So the > client has to allow explicit security exceptions several times. The latter > obviously already happened in old fbml. I agree that this system is not 'fixed'. I too am getting browser warnings about security, even though I'm using secure URLs to my iframe content and have added the secure canvas URL in the app set-up. The strange thing is though that when viewing the content (in this case based at: https://web232.secure-secure.co.uk/koss.co.uk/fbapps/abbierodgers/) in apps.facebook (which is still in an iframe) the warnings don't appear and the content does; for example: https://apps.facebook.com/abbierodgers/ But when viewing the Facebook Page that contains the iframed app, the content does not appear but a warning does; https://beta.facebook.com/kossuk?sk=app_206528179360569 Additionally, I have seen some beta tests of https content that loads one minute and then stutters the next, stumbling at secure-media-sf2p.facebook.com I, like many designers / page admins, are quite anxious about this and hope you guys at FB HQ are working out how all these issues can be resolved. It is far to 'buggy' right now. Martin
I can report the same root problem, as well as beta.fb not having the proposed fix. Do we have an ETA on this? As with other users on here, we have clients who are very concerned about the dev time spent on their fb applications. -> semi-unrelated: SWF file pulled from a non-ssl external src works in SSL-tab when using FBML, which I also found strange.
It's working in beta here after some settings tweaks to my app. Most importantly I had to switch my canvas callback URL from my IP address to my domain name or the iframe wouldn't display at all.
Martin - the page you posted is working here with no warnings on Chrome.
(In reply to comment #64) > Martin - the page you posted is working here with no warnings on Chrome. Maybe it was just the timing (couple of minutes before changes went to beta), but it's working for me now as well. I didn't have to change anything on my app settings though.
Thought I better add that this app now works on the beta URL after I added a dedicated SSL certificate on my server. As soon as I did that, it worked. Obviously 'shared' SSL certificates by hosts are not adequate.
It's only workingwithout an error, when you access the page manually via https://www.beta.facebook.ocm/ An ssl-error (like described in #58) occurs, if you change your account settings ("Browse Facebook on a secure connection (https) whenever possible") to force ssl-encrypton. So bug is still present and not fixed. Sorry Guys ;)
(In reply to comment #65) > (In reply to comment #64) > > Martin - the page you posted is working here with no warnings on Chrome. > > Maybe it was just the timing (couple of minutes before changes went to beta), > but it's working for me now as well. I didn't have to change anything on my app > settings though. yeah ur site works. but one of my sites still not work, although there is only one pic and a button. https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534
(In reply to comment #68) > (In reply to comment #65) > > (In reply to comment #64) > > > Martin - the page you posted is working here with no warnings on Chrome. > > > > Maybe it was just the timing (couple of minutes before changes went to beta), > > but it's working for me now as well. I didn't have to change anything on my app > > settings though. > > yeah ur site works. > > but one of my sites still not work, although there is only one pic and a > button. > https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534 You're getting the same sort of SSL error I was getting prior to buying a dedicated SSL certificate: faisman.de uses an invalid security certificate. The certificate is only valid for the following names: *.kasserver.com , kasserver.com (Error code: ssl_error_bad_cert_domain) Is that a shared certificate?
(In reply to comment #69) > (In reply to comment #68) > > (In reply to comment #65) > > > (In reply to comment #64) > > > > Martin - the page you posted is working here with no warnings on Chrome. > > > > > > Maybe it was just the timing (couple of minutes before changes went to beta), > > > but it's working for me now as well. I didn't have to change anything on my app > > > settings though. > > > > yeah ur site works. > > > > but one of my sites still not work, although there is only one pic and a > > button. > > https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534 > > You're getting the same sort of SSL error I was getting prior to buying a > dedicated SSL certificate: > > faisman.de uses an invalid security certificate. > > The certificate is only valid for the following names: > *.kasserver.com , kasserver.com > > (Error code: ssl_error_bad_cert_domain) > > Is that a shared certificate? i think so, but i dont really know coz kasserver is my webhosting provider. So, do i need a ssl-certificate?
(In reply to comment #70) > > > > Is that a shared certificate? > > i think so, but i dont really know coz kasserver is my webhosting provider. So, > do i need a ssl-certificate? It certainly sorted mine out. I was using the same sort of 'shared' SSL certificate and got the warnings - plus the content didn't appear. I got my own SSL certificate this morning (my host sells them and installs them for a reasonable price) and, as soon as it was active, my secure apps in iframes all worked (in beta.facebook of course). I would recommend you take a look at the services your host can provide. Mine was £40 + VAT per year but now means everything on my domain can become secure via https.
(In reply to comment #71) > (In reply to comment #70) > > > > > > Is that a shared certificate? > > > > i think so, but i dont really know coz kasserver is my webhosting provider. So, > > do i need a ssl-certificate? > > It certainly sorted mine out. I was using the same sort of 'shared' SSL > certificate and got the warnings - plus the content didn't appear. > > I got my own SSL certificate this morning (my host sells them and installs them > for a reasonable price) and, as soon as it was active, my secure apps in > iframes all worked (in beta.facebook of course). > > I would recommend you take a look at the services your host can provide. Mine > was £40 + VAT per year but now means everything on my domain can become secure > via https. Hey Martin, thx for ur information. i just activated ssl-proxy for my domain and tada it works now on beta. https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534
(In reply to comment #72) > (In reply to comment #71) > > (In reply to comment #70) > > Hey Martin, thx for ur information. > i just activated ssl-proxy for my domain and tada it works now on beta. > https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534 It sure does! I think we're all 'gradually' getting sorted!
I can confirm that it is working via SSL-all-the-time on beta for our application. Firefox initially warned me that the SSL certificate that *Facebook* is using on their beta server doesn't match the site, but after I confirmed the security exception, our tab loaded properly via SSL. Hooray! Thanks Facebook devs. Is the plan to push this into production tonight still in effect?
Appears to work perfectly! IMHO please push to production asap, even if some apps have security warnings it's better than a blank screen ;)
(In reply to comment #74) > I can confirm that it is working via SSL-all-the-time on beta for our > application. > > Firefox initially warned me that the SSL certificate that *Facebook* is using > on their beta server doesn't match the site, but after I confirmed the security > exception, our tab loaded properly via SSL. Hooray! But that means you give your users the illusion of a secure connection. Anyway, my iframes are still loaded from the insecure Canvas url, and once you try using social plugins - the use of which is encouraged - the fun is over anyway. This is an iframe with temporarily disabled social plugins: https://blacktrash-org.prossl.de/fb/blacktrashproductions/index.php This is the same "in action": https://www.beta.facebook.com/apps/application.php?id=153629891361325&sk=app_153629891361325 This is an iframe with a fb:like and a fb:share-button tag: https://blacktrash-org.prossl.de/fb/blacktrashproductions/baustellen.php already insecure because of the social plugins.
Christian Ebert, sorry my comments were not clear. The reason you're getting that security exception in BETA is that the certificate Facebook has deployed to their static Akamai servers is the same certificate they deployed to beta.facebook.com. There is a naming mismatch on the certificate that your browser is warning you about. Visit https://s-static.ak.beta.facebook.com/ and inspect the certificate - it's setup for use on *.beta.facebook.com, not for multiple subdomains (e.g. *.*.beta.facebook.com). If you inspect the certificate that will actually be used in production (https://s-static.ak.facebook.com), it appears that everything is signed properly and ready to go. So, again, I believe those security exceptions I reported were simply because Facebook is using 'temporary' certificates in beta. In production, I would expect NO such exceptions - it should all just work seamlessly.
(In reply to comment #77) > Christian Ebert, sorry my comments were not clear. > > The reason you're getting that security exception in BETA is that the > certificate Facebook has deployed to their static Akamai servers is the same > certificate they deployed to beta.facebook.com. There is a naming mismatch on > the certificate that your browser is warning you about. Visit > https://s-static.ak.beta.facebook.com/ and inspect the certificate - it's setup > for use on *.beta.facebook.com, not for multiple subdomains (e.g. > *.*.beta.facebook.com). > > If you inspect the certificate that will actually be used in production > (https://s-static.ak.facebook.com), it appears that everything is signed > properly and ready to go. > > So, again, I believe those security exceptions I reported were simply because > Facebook is using 'temporary' certificates in beta. In production, I would > expect NO such exceptions - it should all just work seamlessly. ok, still leaves the problem why my secure canvas url setting is simply ignored - once I accept the exception for s-static.ak.beta.facebook.com/, the next exception would be for my insecure canvas url. Supposing this gets fixed, I still have to turn off social plugins, even though I specify loading of the connect script via location protocol ... "seemlessly", hm, I might have a different unterstanding of that word ;-)
Christian, I just looked at your "in action" Facebook page. https://www.beta.facebook.com/apps/application.php?id=153629891361325&sk=app_153629891361325 The problem is that your Facebook app is trying to load from https://blacktrash.org, not https://blacktrash-org.prossl.de/fb/blacktrashproductions/baustellen.php The SSL certificate you are serving is for prossl.de, not blacktrash.org, so that's why you're getting the security exception. Perhaps I'm stating the obvious, but if you change your application's settings Secure Canvas URL to include "https://blacktrash-org.prossl.de", you're security exception should go away. Or is this a case where you've already done that, but the change hasn't taken effect yet? Maybe there is a time delay in beta? In our tests, our server has a valid SSL certificate for our domain name and it's working correctly. Good luck!
(In reply to comment #79) > Christian, I just looked at your "in action" Facebook page. > > https://www.beta.facebook.com/apps/application.php?id=153629891361325&sk=app_153629891361325 > > The problem is that your Facebook app is trying to load from > https://blacktrash.org, not > > https://blacktrash-org.prossl.de/fb/blacktrashproductions/baustellen.php I know. > The SSL certificate you are serving is for prossl.de, not blacktrash.org, so > that's why you're getting the security exception. Yes. I believe I said so, maybe somewhere else in this thread. > Perhaps I'm stating the obvious, but if you change your application's settings > Secure Canvas URL to include "https://blacktrash-org.prossl.de", you're > security exception should go away. Or is this a case where you've already > done that, but the change hasn't taken effect yet? Maybe there is a time delay > in beta? The Secure Canvas URL is set to http://blacktrash-org.prossl.de/fb/blacktrashproductions/ since I created the app. That's why I wrote that the setting is simply ignored. Additionally, even when going to the iframe directly, I now found out that not only social plugins make the connection insecure, but also just a call to FB.Canvas.setSize() ... > Good luck! I'm in bad need of it, it seems.
(In reply to comment #80) > The Secure Canvas URL is set to > http://blacktrash-org.prossl.de/fb/blacktrashproductions/ since I created the > app. sorry, typo, but not in my settings: https://blacktrash-org.prossl.de/fb/blacktrashproductions/
(In reply to comment #80) > The Secure Canvas URL is set to > https://blacktrash-org.prossl.de/fb/blacktrashproductions/ since I created the > app. > > That's why I wrote that the setting is simply ignored. > > Additionally, even when going to the iframe directly, I now found out that not > only social plugins make the connection insecure, but also just a call to > FB.Canvas.setSize() ... I guessed wrong, it's not the social plugins, it's FB.Canvas.setSize(). Probably because again it tries to retrieve the wrong canvas. oh well.
Christian - we have FB.Canvas.setSize working in https under beta https://beta.facebook.com/hatchlings?sk=app_127007970705038
I'm also having a problem with our Secure Canvas URL setting being ignored: Canvas URL: http://example.com/... Secure Canvas URL: https://secure.example.com/... When viewing the tab in FireFox, I'm prompted to add a certificate exception for https://example.com. Has anybody else gotten this to work using a secured subdomain?
(In reply to comment #83) > Christian - we have FB.Canvas.setSize working in https under beta > https://beta.facebook.com/hatchlings?sk=app_127007970705038 Don't make my mouth water ;-) Anyway, I guess you don't have the problem with the Secure Canvas setting being ignored, so retrieving the canvas is secure ... in your case.
It's probably getting ignored for us too but since our secure page is just https prepended to our regular page it still works.
I've been following this bug from nearly the start, and glad it's (almost) fixed. But now I have another issue. I've been able to see my iframe page app using the secure connection: https://www.beta.facebook.com/pages/Test-Hotel/191413584223737?sk=app_157050517660807, but now it seems to be no longer working under non-secure browsing, which it did before: http://www.beta.facebook.com/pages/Test-Hotel/191413584223737?sk=app_157050517660807. Afterthought: I've checked on production and see exactly the same, so now my app can't be seen by anybody not using secure browsing. I guess that's not so bad, but it's going to annoy a lot of people.
I'm seeing the same issue as of this morning.
Same problem here. Do you have an ETA for a FIX ?
I've looked at some other pages with apps from this thread and they seem not to have the same issue I'm having. This seems to be the one everyone's using... https://www.facebook.com/hatchlings?sk=app_7176719309 compared to: http://www.facebook.com/hatchlings?sk=app_7176719309. The other thing that may possibly be affecting mine but not yours is that both my canvas URL and secure canvas URL are the same secure connection. This is needed because the server my app is on only can be connected to on a secure connection. Unfortunately I only know a little about secure connections, so I'm not sure, but I wouldn't think that would stop it working would it? I have tried changing the canvas URL to http, but it doesn't work because my server won't connect properly. So.... does anybody know if there's something I can do to my app to fix the issue, or is the bug not fixed?
Hello, Can you try https://beta.facebook.com in place of https://www.beta.facebook.com ? Have you the same problem ? Regards, Serge
(In reply to comment #91) > Can you try https://beta.facebook.com in place of https://www.beta.facebook.com > ? Have you the same problem ? Same problem. Secure Canvas URL setting is ignored. The POST request goes to "https://example.com" instead of "https://secure.example.com". I can see it in the Firebug net panel.
We noted that the Comments Box social plugin <fb:comments>, when using an external CSS, does not load this plugin securely. Is anyone experiencing this and also can confirm? This means everyone using IE gets the warning about unsecure content. It would be helpful if Facebook would also import the style sheet via https. Here is an example of the external CSS URL that gets loaded inside of the fb:comments iframe: http://external.ak.fbcdn.net/fbml_static_get.php?src=https%3A%2F%2Fwww.website.com%2Fcss%2Fstyles.css&appid=#################&pv=1&sig=HASH&filetype=css&cb=2
So it looks like the fix has been pushed to production. As of this morning I am able to see our profile page applications with SSL all-the-time enabled. Thanks Facebook!
Confirmed, appears to be working for us. Thank you Facebook team
(In reply to comment #92) > Same problem. Secure Canvas URL setting is ignored. The POST request goes to > "https://example.com" instead of "https://secure.example.com". I can see it in > the Firebug net panel. Some problem for me. Anybody an idea for fixing this?
On production and beta I'm still having problems with the ssl pages not showing. Here's my setup: - I am using iframes on a page with the new tabs-on-the-left layout, pulling aspx pages from an IIS7 server - My non-HTTPS canvas URL is set to http://fb.example.com - My HTTPS canvas URL is set to https://secure.example.com (using a dedicated SSL certificate) When I go to a page with my app using HTTPS on Firefox the iframe loads and says "You have asked Firefox to connect securely to fb.example.com, but we can't confirm that your connection is secure." So apparently it's trying to load the non-secured URL. Any help would be appreciated.
This has not been resolved for my app. When going to my Facebook page under https:// (logged in and logged out)the app is not displayed in any browser. I get a different error for each browser type. This app should show when connected with http:// or https: and when logged in or out. What is the point of building an app if half can see it and half cannot? What do I do to make sure my app shows up NO MATTER WHAT!! Thank you. JP
It has not been fixed for me
Facebook Team: it's all working fine as rain. Thanks! I have read every comment and reply. I appreciate the pain... it's been a tough road and a long wait. Thanks to Martin Koss, my Sys Admins at Mailjol, and some dumb luck. But I have it all working now. I will leave this test app up for 24 hours in case it helps anyone. Check out these links in a logged out or logged in state, and in IE, FF and Chrome. There will be no mismatched cert warnings and everything loads. I am using the Facebook provided resizing javascript and I do not need to provide a specific height. I *do* see a brief scroll bar until the javascript kicks in... no big deal. Anyway, here you go: http://www.facebook.com/KenHoodTV?sk=app_186853371356033 https://www.facebook.com/KenHoodTV?sk=app_186853371356033 Here's what you *must* do. I've tried everything else talked about in this thread and things will not work unless you do it *exactly* this way: 1) Apps ~ Edit Settings ~ Facebook Integration. 2) Canvas URL: http://yoursecureform.com/fb/009/ 3) Secure Canvas URL: https://yoursecureform.com/fb/009/ 4) The cert must be on a dedicated IP. 5) You cannot use https url in the Canvas URL field. 6) The paths must be identical. You cannot use a different path in the Secure Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* I tried that and it didn't work. Willing to be corrected on this point. 7) The javascript path needs to be secure at: https://connect.facebook.net/en_US/all.js 8) Pictures must be secure path like https://yoursecureform.com/fb/009/sign-mlhi.jpg OK... I know that I may be corrected on several points... and I would be gratefl if I were (assuming I'm wrong or incomplete on some points. This thread has very helpful... I hope this adds a bit of help to someone else. :)
(In reply to comment #100) > Facebook Team: it's all working fine as rain. Thanks! > > I have read every comment and reply. I appreciate the pain... it's been a tough > road and a long wait. Thanks to Martin Koss, my Sys Admins at Mailjol, and some > dumb luck. But I have it all working now. > > I will leave this test app up for 24 hours in case it helps anyone. Check out > these links in a logged out or logged in state, and in IE, FF and Chrome. :) I am confused here. So I have to order a secure cert and get a dedicated server in order for my App to display to all users on Facebook, logged in or out, http or https? Am I leaving anything out? What do I have to do to make it possible for all users on Facebook to easily few my App on my Facebook Page?
(In reply to comment #101) > (In reply to comment #100) > > Facebook Team: it's all working fine as rain. Thanks! > > > > I have read every comment and reply. I appreciate the pain... it's been a tough > > road and a long wait. Thanks to Martin Koss, my Sys Admins at Mailjol, and some > > dumb luck. But I have it all working now. > > > > I will leave this test app up for 24 hours in case it helps anyone. Check out > > these links in a logged out or logged in state, and in IE, FF and Chrome. :) > > I am confused here. So I have to order a secure cert and get a dedicated server > in order for my App to display to all users on Facebook, logged in or out, http > or https? > > Am I leaving anything out? What do I have to do to make it possible for all > users on Facebook to easily few my App on my Facebook Page? You do not need a dedicated server, but you will need a hosting plan somewhere that will let you assign a dedicated IP address to your domain. Once you have that... you should be "good to go." But there is no way that I can see (I've tried) to get around having a dedicated IP that has a SL Certificate applied to it.
(In reply to comment #102) > (In reply to comment #101) > > (In reply to comment #100) > > > Facebook Team: it's all working fine as rain. Thanks! > > > > You do not need a dedicated server, but you will need a hosting plan somewhere > that will let you assign a dedicated IP address to your domain. Once you have > that... you should be "good to go." But there is no way that I can see (I've > tried) to get around having a dedicated IP that has a SL Certificate applied to > it. I have a VPS with dedicated IP addresses. I have a little ole App I designed that you can see here --> http://www.facebook.com/pages/IRJP-Web-Design-and-Development/102094913205476 It cannot be viewed by anyone logged in or out when using the https URL. Are we on the same page here? My App is not an App that others will add to their Facebook page. It is only for my Facebook page. Thank you, JP
(In reply to comment #103) > (In reply to comment #102) > > (In reply to comment #101) > > > (In reply to comment #100) > > > > Facebook Team: it's all working fine as rain. Thanks! > I have a VPS with dedicated IP addresses. I have a little ole App I designed > that you can see here --> > http://www.facebook.com/pages/IRJP-Web-Design-and-Development/102094913205476 > > It cannot be viewed by anyone logged in or out when using the https URL. > > Are we on the same page here? My App is not an App that others will add to > their Facebook page. It is only for my Facebook page. > > Thank you, > JP Hi JP.. ok you are close. And it doesn't matter that your App "is not an App that others will add to their Facebook Page." An App is an App. You seem to have set it up just fine. :) Except... Your non secure browsing viewers are seeing this page: http://itabdit.com/itabdit_app/index.php just fine. But when they browse using https, they get this error (at least in Firefox): SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) So the problem is either: a) you do not have that domain mapped to a dedicated IP that has a valid cert installed on it, or b) you *do* have a dedicated IP and a valid cert on that domain, but there is some kind of problem with the cert, or c) it is none of the above and you did not follow instructions in the facebook Integration part of my step by step. My money is on either a or b. If you do not understand dedicated IP and ssl certificates... you may need to partner with someone who does. Best of luck... I know... this stuff is no fun. :) b) you do
(In reply to comment #104) > (In reply to comment #103) > > (In reply to comment #102) > > > (In reply to comment #101) > > > > (In reply to comment #100) > > > > > Facebook Team: it's all working fine as rain. Thanks! > > So the problem is either: > > a) you do not have that domain mapped to a dedicated IP that has a valid cert > installed on it, or > b) you *do* have a dedicated IP and a valid cert on that domain, but there is > some kind of problem with the cert, or > c) it is none of the above and you did not follow instructions in the facebook > Integration part of my step by step. > > My money is on either a or b. > > If you do not understand dedicated IP and ssl certificates... you may need to > partner with someone who does. > > Best of luck... I know... this stuff is no fun. :) That is what I was getting at. In order for everyone to view my app NO MATTER WHAT, I have to purchase a Secure Cert and redo the app under the cert. So this means every single App developer on Facebook, has to purchase or already own a Secure cert and have deicate IP's?
(In reply to comment #70) > (In reply to comment #69) > > (In reply to comment #68) > > > (In reply to comment #65) > > > > (In reply to comment #64) > > > > > Martin - the page you posted is working here with no warnings on Chrome. > > > > > > > > Maybe it was just the timing (couple of minutes before changes went to beta), > > > > but it's working for me now as well. I didn't have to change anything on my app > > > > settings though. > > > > > > yeah ur site works. > > > > > > but one of my sites still not work, although there is only one pic and a > > > button. > > > https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534 > > > > You're getting the same sort of SSL error I was getting prior to buying a > > dedicated SSL certificate: > > > > faisman.de uses an invalid security certificate. > > > > The certificate is only valid for the following names: > > *.kasserver.com , kasserver.com > > > > (Error code: ssl_error_bad_cert_domain) > > > > Is that a shared certificate? > i think so, but i dont really know coz kasserver is my webhosting provider. So, > do i need a ssl-certificate? (In reply to comment #72) > (In reply to comment #71) > > (In reply to comment #70) > > > > > > > > Is that a shared certificate? > > > > > > i think so, but i dont really know coz kasserver is my webhosting provider. So, > > > do i need a ssl-certificate? > > > > It certainly sorted mine out. I was using the same sort of 'shared' SSL > > certificate and got the warnings - plus the content didn't appear. > > > > I got my own SSL certificate this morning (my host sells them and installs them > > for a reasonable price) and, as soon as it was active, my secure apps in > > iframes all worked (in beta.facebook of course). > > > > I would recommend you take a look at the services your host can provide. Mine > > was £40 + VAT per year but now means everything on my domain can become secure > > via https. > Hey Martin, thx for ur information. > i just activated ssl-proxy for my domain and tada it works now on beta. > https://beta.facebook.com/Crossfit.am.Rhein?sk=app_112743272133534 I just clicked on your URL and your page doesn't display at all. It says "The webpage cannot be found HTTP 404 Most likely causes: •There might be a typing error in the address. •If you clicked on a link, it may be out of date"
(In reply to comment #105) > (In reply to comment #104) > > (In reply to comment #103) > > > (In reply to comment #102) > > > > (In reply to comment #101) > > > > > (In reply to comment #100) > > > > > > Facebook Team: it's all working fine as rain. Thanks! > > > > So the problem is either: > > > > a) you do not have that domain mapped to a dedicated IP that has a valid cert > > installed on it, or > > b) you *do* have a dedicated IP and a valid cert on that domain, but there is > > some kind of problem with the cert, or > > c) it is none of the above and you did not follow instructions in the facebook > > Integration part of my step by step. > > > > My money is on either a or b. > > > > If you do not understand dedicated IP and ssl certificates... you may need to > > partner with someone who does. > > > > Best of luck... I know... this stuff is no fun. :) > > That is what I was getting at. In order for everyone to view my app NO MATTER > WHAT, I have to purchase a Secure Cert and redo the app under the cert. So this > means every single App developer on Facebook, has to purchase or already own a > Secure cert and have deicate IP's? JP- You are correct on *both* counts. Unless Facebook changes their "fix" but I wouldn't hold my breath. But you only need *one* domain with a dedicated IP, since each client of yours will have their own folder, such as xyz123.com/fb/johndoe/ This has overwhelmed me too, since I have over 100 clients with custom FBML tabs, and each of them has at least 3 tabs, so do the math... I am looking at creating 300 separate apps using this cumbersome solution. Good news: I have seen a few developers coming out with turnkey solutions whereby you can just pop your html and css files into their app, and associate with a specific page, and bingo.. it will work. That's how my forms on facebook.com/kenhoodtv work (the cool ones not the test apps). I had my developers custom make me these apps so I can use let's say, the Auto Quote app for multiple instances/pages. I will be reviewing these solutions on my Facebook page next week sometime, so follow me there if you want to get a summary of what's out there for plug n play solutions for guys like us.
(In reply to comment #100) > Here's what you *must* do. I've tried everything else talked about in this > thread and things will not work unless you do it *exactly* this way: > > 1) Apps ~ Edit Settings ~ Facebook Integration. > 2) Canvas URL: http://yoursecureform.com/fb/009/ > 3) Secure Canvas URL: https://yoursecureform.com/fb/009/ > 4) The cert must be on a dedicated IP. > 5) You cannot use https url in the Canvas URL field. > 6) The paths must be identical. You cannot use a different path in the Secure > Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* > I tried that and it didn't work. Willing to be corrected on this point. > 7) The javascript path needs to be secure at: > https://connect.facebook.net/en_US/all.js > 8) Pictures must be secure path like > https://yoursecureform.com/fb/009/sign-mlhi.jpg Thanks for posting this Ken, it's been helpful. BUT: When it comes to step 5 "You cannot use https url in the Canvas URL field.", I run into a problem. The way our server if set up, it requires a https connection. If I put in a http address, our server will automatic redirect it to the https site, and then the app does not authenticate in facebook properly. I'm looking into this in my app code now, hopefully I'll have a solution soon. Any suggestions?
(In reply to comment #108) > (In reply to comment #100) > > Here's what you *must* do. I've tried everything else talked about in this > > thread and things will not work unless you do it *exactly* this way: > > > > 1) Apps ~ Edit Settings ~ Facebook Integration. > > 2) Canvas URL: http://yoursecureform.com/fb/009/ > > 3) Secure Canvas URL: https://yoursecureform.com/fb/009/ > > 4) The cert must be on a dedicated IP. > > 5) You cannot use https url in the Canvas URL field. > > 6) The paths must be identical. You cannot use a different path in the Secure > > Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* > > I tried that and it didn't work. Willing to be corrected on this point. > > 7) The javascript path needs to be secure at: > > https://connect.facebook.net/en_US/all.js > > 8) Pictures must be secure path like > > https://yoursecureform.com/fb/009/sign-mlhi.jpg > > Thanks for posting this Ken, it's been helpful. > > BUT: When it comes to step 5 "You cannot use https url in the Canvas URL > field.", I run into a problem. The way our server if set up, it requires a > https connection. If I put in a http address, our server will automatic > redirect it to the https site, and then the app does not authenticate in > facebook properly. I'm looking into this in my app code now, hopefully I'll > have a solution soon. Any suggestions? I think I've worked it out, it's a problem with the way our server redirects to https, we aren't POSTing the signed_request to the secure server. I guess that's better than a facebook bug, because now I'm not waiting for facebook to fix it, but it means I need to do some work *sigh*.
(In reply to comment #109) > (In reply to comment #108) > > (In reply to comment #100) > > > Here's what you *must* do. I've tried everything else talked about in this > > > thread and things will not work unless you do it *exactly* this way: > > > > > > 1) Apps ~ Edit Settings ~ Facebook Integration. > > > 2) Canvas URL: http://yoursecureform.com/fb/009/ > > > 3) Secure Canvas URL: https://yoursecureform.com/fb/009/ > > > 4) The cert must be on a dedicated IP. > > > 5) You cannot use https url in the Canvas URL field. > > > 6) The paths must be identical. You cannot use a different path in the Secure > > > Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* > > > I tried that and it didn't work. Willing to be corrected on this point. > > > 7) The javascript path needs to be secure at: > > > https://connect.facebook.net/en_US/all.js > > > 8) Pictures must be secure path like > > > https://yoursecureform.com/fb/009/sign-mlhi.jpg > > > > Thanks for posting this Ken, it's been helpful. > > > > BUT: When it comes to step 5 "You cannot use https url in the Canvas URL > > field.", I run into a problem. The way our server if set up, it requires a > > https connection. If I put in a http address, our server will automatic > > redirect it to the https site, and then the app does not authenticate in > > facebook properly. I'm looking into this in my app code now, hopefully I'll > > have a solution soon. Any suggestions? > > I think I've worked it out, it's a problem with the way our server redirects to > https, we aren't POSTing the signed_request to the secure server. I guess > that's better than a facebook bug, because now I'm not waiting for facebook to > fix it, but it means I need to do some work *sigh*. Andy- I'm glad I saw this before replying to your earlier comment... and even though it is a "sigh" moment... at least now you know what's gotta be done. This is helpful working out our frustrations in public because it will save someone else some grief. Thanks for letting us know... :)
(In reply to comment #100) > Facebook Team: it's all working fine as rain. Thanks! ? > 6) The paths must be identical. You cannot use a different path in the Secure > Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* > I tried that and it didn't work. Willing to be corrected on this point. Exactly. The Secure Canvas URL setting is simply ignored and instead the protocol for the "normal" Canvas URL is exchanged. What's the use of the Secure Canvas URL setting then?
(In reply to comment #111) > (In reply to comment #100) > > Facebook Team: it's all working fine as rain. Thanks! > > ? > > > 6) The paths must be identical. You cannot use a different path in the Secure > > Canvas URL (like https://secure.yoursecureform.com/fb/009/) At least I *think* > > I tried that and it didn't work. Willing to be corrected on this point. > > Exactly. The Secure Canvas URL setting is simply ignored and instead the > protocol for the "normal" Canvas URL is exchanged. What's the use of the Secure > Canvas URL setting then? I *think* I agree.. if I understand your comment. But this "bug fix" ends up giving us what we *need* which is an iframe app that displays properly in all browsers and the https browsing selection that so many users are choosing. It does seem to be a funny way to get it done. And as some seem to be suggesting (as you do I think) that it's not even a proper way to fix this bug. All that said... my clients will be able to see my stuff. And maybe I'm easily pleased... but I'm thankful for *any* fix that let's me get about the business of selling. So I stand by my original "thank you" to facebook... and I hope the "real coders" push for better fixes.
> All that said... my clients will be able to see my stuff. And maybe I'm easily > pleased... but I'm thankful for *any* fix that let's me get about the business > of selling. So I stand by my original "thank you" to facebook... and I hope the > "real coders" push for better fixes. It's not really a matter of calling for "real coders" - the secure canvas URL is ignored, and instead, the standard canvas URL is called with https instead. Yes, you can work around this, but calling it a fix is probably pushing it ;o) It's not that we can't get things to work now, but we have to mess with a lot of Apache configuration just to please facebook, which seems backwards. So, could we just use the secure canvas URL instead, actually doing what the documentation suggests?
(In reply to comment #113) > > All that said... my clients will be able to see my stuff. And maybe I'm easily > > pleased... but I'm thankful for *any* fix that let's me get about the business > > of selling. So I stand by my original "thank you" to facebook... and I hope the > > "real coders" push for better fixes. > > It's not really a matter of calling for "real coders" - the secure canvas URL > is ignored, and instead, the standard canvas URL is called with https instead. > Yes, you can work around this, but calling it a fix is probably pushing it ;o) > > It's not that we can't get things to work now, but we have to mess with a lot > of Apache configuration just to please facebook, which seems backwards. > > So, could we just use the secure canvas URL instead, actually doing what the > documentation suggests? "Real coders" was just a tongue in cheek comment... sorry... I get that way sometimes. Apologies. :) To your comment "seems backwards" I agree. I think we all do. To your question "could we just use the secure canvas URL instead" one would think "yes" but when I tried it yesterday... no go. At least if what you mean is that the "Canvas URL and the "Secure Canvas URL" fields are both populated with the same secure url. I'm wishing someone would tell us a better workaround. But until then, I have some designer friends who have been waiting for *any* solution that would let them get going. So I thought by sharing what worked for me... however convoluted, it might help someone in need. btw... in my PLESK panel, I am allowed to use a single directory for housing SSL and non-SSL content, so I am able to publish one set of files to just my http folder. That saves a bit of trouble. Not sure if cpanel or others allow for that. Been a PLESK guy for 5 years.
(In reply to comment #113) > So, could we just use the secure canvas URL instead, actually doing what the > documentation suggests? This is the solution we need as well. We have a load-balancer that currently doesn't support SSL. We want our canvas url to point to the load balancer and the secure canvas url to point directly to a server. But as noted, the page tab loads the canvas url with https and not the secure canvas url. So we currently have to point all of our traffic to one server.
We're seeing the same problem here. The iframe URLs are : non-secure : http://www.celtichound.co.uk secure : https://secure.celtichound.co.uk secure.celtichound.co.uk has a valid certificate, tested and working. However, when someone using https login on Facebook accesses the app, the iframe points them at https://www.celtichound.co.uk completely ignoring the secure canvas url setting. This bug needs fixed before we can deploy our app. A work round is not possible as the secure.celtichound.co.uk name is used elsewhere, and we cannot deploy two cerificates on the same machine. Could we please have an ETA of when this bug will be fixed? Regards, Graham Robinson
Workround for the secure canvas url being ignored : Added redirect from http://secure.celtichound.co.uk to https://secure.celtichound.co.uk in webserver. Set http://secure.celtichound.co.uk as non-secure canvas url on facebook. Everyone now uses the secure version of the iframe. Hope this helps someone else...
Another part of the problem is: If your account is set to non-secure browsing (without automatic redirect to https) and you just type in an https canvas url, Facebook itself is serving invalid markup by adding this tracking pixel from an non-secure http url... With secure browsing enabled this does not happen. <img src="http://www.facebook.com/campaign/impression.php?campaign_id=108384999181205" class="tracking_pixel"> This only happens on the canvas part on applications, not on the tabs. You can see this happening on any canvas page of my app here (I haven't tried other apps): http://www.facebook.com/menutab
This is a very severe bug! Can you let us know when we it is scheduled to be fixed?
Some of the additional issues described here may be fixed by the 15 March push -- you can verify by checking against beta today. If not, please make sure to open new issues in new bugs -- even if they seem closely related. Thanks!
The beta tier tells me, that the iframe is blocked by chrome. In firefox it said, that the certificate from beta.facebook.com is not valid.
I've created an issue for the ignoring of the Secure Canvas URL: http://bugs.developers.facebook.net/show_bug.cgi?id=15850
The fix seems to reverse the problem. On my app, I switched both URL's to "https://example.com/facebook/app". That seemed to work until now. Now, if the user is NOT on a secure connection (using http) they WILL NOT see my iframe. So, only secure users see it. My secure server, which is where the app is currently located, does not allow insecure connections, so I can't just switch back and forth. I'll fix it by changing that on my side, but I thought I should mention it.
(In reply to comment #123) > The fix seems to reverse the problem. On my app, I switched both URL's to > "https://example.com/facebook/app". That seemed to work until now. Now, if > the user is NOT on a secure connection (using http) they WILL NOT see my > iframe. So, only secure users see it. My secure server, which is where the > app is currently located, does not allow insecure connections, so I can't just > switch back and forth. I'll fix it by changing that on my side, but I thought > I should mention it. Half of these URL's work while the other half show blank pages. http://beta.facebook.com/ksltv?sk=app_184621824909531 https://beta.facebook.com/ksltv?sk=app_184621824909531 http://www.facebook.com/ksltv?sk=app_184621824909531 https://beta.facebook.com/ksltv?sk=app_184621824909531
When enabling the HTTPS setting on Facebook, the associated text reads "Browse Facebook on a secure connection (https) whenever possible". In my opinion, Facebook should check the canvas URLs and if no HTTPS URL is provided, it should fall back to regular HTTP to support the application and then revert back to HTTPS once users browse other areas of the Facebook site or applications that do support HTTPS, as advertised when you set the HTTPS option within your settings. When you have different domains for each of your clients rather than sub-folders, it will work out extremely costly to have to purchase an SSL certificate for every single one of them.
(In reply to comment #125) > In my opinion, Facebook should check the canvas URLs and if no HTTPS URL is > provided, it should fall back to regular HTTP to support the application In my opinion, Facebook should never fall back to HTTP if I tell it to always use HTTPS. Whenever the session data is transferred via HTTP, there is the possibility for them to be stolen by programs like Firesheep.
I'm puzzled to see so many people still adding to this bug. It's fixed, isn't it? I haven't seen a https related issue (or any kind of error, Security Warning) on any of my pages or clients' pages for quite some time and that is hammering them with tests of every imaginable form.. I did a video about some for the common issues with security warnings etc., It might help.. Don't worry, I don't ask you to like the page or subscribe in order to view it... I'm just trying to be helpful. http://www.facebook.com/video/video.php?v=10150158428455280 I am so confident with Facebook's upgrades that I now guarantee all pages I design will have no errors, no warnings, no scrollbars, etc., Martin
Created an attachment (id=3948) [details] Still blocking content when Secure Browsing is enabled This issue is not fixed. Here's the situation: If the user has set their Account Settings -> Account Security -> Secure Browsing (https) to on; they will not be able to view iframe tab applications that do not have an ssl certificate. The system will replace the protocol with https for that tab src. So if you've set your Canvas URL to http://www.yourdoamin.com/your/application/ the system will look for https://www.yourdomain.com/your/application/ and your browser will deem the iframe as insecure and block the content. There was an update done last night that now allows you to set your full iframe tab URL explicitly, but it still does not allow a viewer with secure browsing enabled to view iframe tab applications that do not have an ssl certificate. I agree with Ashley Kleynhans that the system should detect the protoccol set in the application settings and reload the page using that protocol when the user has chosen the secure browsing enabled option.
(In reply to comment #128) > Created an attachment (id=3948) [details] [details] > Still blocking content when Secure Browsing is enabled > > This issue is not fixed. > > > There was an update done last night that now allows you to set your full iframe > tab URL explicitly, but it still does not allow a viewer with secure browsing > enabled to view iframe tab applications that do not have an ssl certificate. > "does not allow a viewer with secure browsing enabled to view iframe tab applications that do not have an ssl certificate." Surely that is the way SSL and Browser's are supposed to work? How can anyone expect Facebook to make possible what isn't possible? Expecting to be able to use NON-SSL content in a SECURE (https) connection goes against everything SSL (and browser security) is designed to do / protect users from. This is not something we can ask or expect Facebook to change because it is basic SSL logic that any content used IN a https connection must be secure else the browser will detect that not all the content is verifiably secure and not display it. Yes, you need a valid SSL on the domain where your content is hosted. That is NOT Facebook's fault - that is SSL and Browser's doing the job they are supposed to do - keeping the user./viewer/reader secure and respecting their choice to browse Facebook via a HTTPS connection. -Martin http://www.facebook.com/#!/video/video.php?v=10150158428455280
(In reply to comment #129) > (In reply to comment #128) > > Created an attachment (id=3948) [details] [details] [details] > > Still blocking content when Secure Browsing is enabled > > > > This issue is not fixed. > > > > > > There was an update done last night that now allows you to set your full iframe > > tab URL explicitly, but it still does not allow a viewer with secure browsing > > enabled to view iframe tab applications that do not have an ssl certificate. > > > > "does not allow a viewer with secure browsing enabled to view iframe tab > applications that do not have an ssl certificate." > > Surely that is the way SSL and Browser's are supposed to work? > > How can anyone expect Facebook to make possible what isn't possible? > > Expecting to be able to use NON-SSL content in a SECURE (https) connection goes > against everything SSL (and browser security) is designed to do / protect users > from. > > This is not something we can ask or expect Facebook to change because it is > basic SSL logic that any content used IN a https connection must be secure else > the browser will detect that not all the content is verifiably secure and not > display it. > > Yes, you need a valid SSL on the domain where your content is hosted. > > That is NOT Facebook's fault - that is SSL and Browser's doing the job they are > supposed to do - keeping the user./viewer/reader secure and respecting their > choice to browse Facebook via a HTTPS connection. > > -Martin > http://www.facebook.com/#!/video/video.php?v=10150158428455280 Thats totally not the point I or Ashley was trying to make. Obviously Facebook can't change the way SSL works. The option in your settings states "Browse Facebook on a secure connection (https) whenever possible " so what we are suggesting is that facebook CAN detect the settings for each iframe application, so they could easily detect if the application has a Secure Canvas URL or a secure protocol set for their iframe tab URL. They could easily then reload the page with Secure Browsing turned off. This would be compliant to the "whenever possible" part of the statement. Then when the user navigates away from the "unsecure" content they could reload the page again with Secure Browsing turned on.
(In reply to comment #130) > (In reply to comment #129) > > (In reply to comment #128) > > > Created an attachment (id=3948) [details] [details] [details] [details] > > > Still blocking content when Secure Browsing is enabled > > > > > > This issue is not fixed. > > > > > > > > > There was an update done last night that now allows you to set your full iframe > > > tab URL explicitly, but it still does not allow a viewer with secure browsing > > > enabled to view iframe tab applications that do not have an ssl certificate. > > > > > Thats totally not the point I or Ashley was trying to make. Obviously Facebook > can't change the way SSL works. > > The option in your settings states "Browse Facebook on a secure connection > (https) whenever possible > " so what we are suggesting is that facebook CAN detect the settings for each > iframe application, so they could easily detect if the application has a Secure > Canvas URL or a secure protocol set for their iframe tab URL. Got ya! I see what you're saying. I'll kick myself in the shins on your behalf... Yes... The 'wherever possible' is the bit that isn't working. That would suggest to us devs that if we omit a secure URL, our page/app would be presented without the https and the viewer given the option to dip out of secure setting temporarily. Good point. Well said. Well raised. Me sticking my nose in without reading the entire thread was a blip in the system...
(In reply to comment #126) > (In reply to comment #125) > > In my opinion, Facebook should check the canvas URLs and if no HTTPS URL is > > provided, it should fall back to regular HTTP to support the application > > In my opinion, Facebook should never fall back to HTTP if I tell it to always > use HTTPS. Whenever the session data is transferred via HTTP, there is the > possibility for them to be stolen by programs like Firesheep. Facebook could totally switch back and forth between HTTPS and HTTP if they used two session cookies (one secure and one not), and require the secure one when posting etc. It works great for my site.
FB *is* doing something similar to this on regular Canvas iframe apps I noticed - sometimes I get an error saying "This app is not available over SSL" with a button I can click to switch to regular HTTP to view the App. They do not appear to have this implemented for Tab iframe apps yet though. But I think this is the solution, and they will get it on the Tabs before too long. (*ahem* please?)
(In reply to comment #133) > FB *is* doing something similar to this on regular Canvas iframe apps I noticed > - sometimes I get an error saying "This app is not available over SSL" with a > button I can click to switch to regular HTTP to view the App. > > They do not appear to have this implemented for Tab iframe apps yet though. But > I think this is the solution, and they will get it on the Tabs before too long. > (*ahem* please?) This may be an edge-case but it's one that I've encountered and it's worth noting. There are users (including many inside of secured IT environments, corporations, etc) for whom browser/OS settings are fixed to always access a site via HTTPS if it is available. This means that, regardless of the HTTPS setting in the Facebook Account Settings > Account Security, users that either choose-to or are required-to use HTTPS will ALWAYS access Facebook via HTTPS. In those cases the users may not have the choice to switch between secure and insecure settings. My suggestion is to expand the scope of the "switch to http" messaging so that it is triggered on a tab page as well as a Canvas page and expand the messaging to include an explanation for those who by-choice or automatically force HTTPS connections. This messaging could be conditional, based on Facebooks' ability to detect the users' secure browsing setting in Account Settings > Account Security. If the user has chosen to enable the Facebook secure browsing setting then they would get the existing messaging (switch to http). If the user is manually or automatically forcing access to Facebook via HTTPS and their secure browsing Account Setting is not enabled then the messaging could be altered to state that the user will need to disable forced https to view the application. As much as SSL can be a barrier to Facebook application development it appears that Facebook is approaching it as a "cost of doing business" but IMHO the ramifications of this change to developers should have been far better communicated, far better documented and been given a much more sufficient timeline for implementation.
I actually have my browsers configured with extensions to force SSL (since the firesheep scare), and yes it does cause problems but I always figured I was an edge case so I've never opened a bug or anything out that. When I am faced with one of those "Stop using SSL" messages for non-secure apps I end up in an endless loop ;) Adding some text to the "stop using SSL" message on Apps (tab and Canvas) would not be a bad idea for folks who forgot that they are running a force-SSL extension.
And now the menu icons to the iframe apps have just disappeared when https is on. Great! Resolved!
(In reply to comment #136) > And now the menu icons to the iframe apps have just disappeared when https is > on. Great! Resolved! Hi... I almost had heart failure too... Until I checked the app itself. If you look at Facebook Integration, the bottom section, you will see that they have added a couple new fields. It's intuitive... make a couple changes and you should be good to go. I was. Whew.
(In reply to comment #137) > (In reply to comment #136) > > And now the menu icons to the iframe apps have just disappeared when https is > > on. Great! Resolved! > > Hi... I almost had heart failure too... Until I checked the app itself. If you > look at Facebook Integration, the bottom section, you will see that they have > added a couple new fields. It's intuitive... make a couple changes and you > should be good to go. I was. Whew. Whew indeed. Thank you Facebook pros for keeping us amateurs always up to date ;-)
(In reply to comment #137) > (In reply to comment #136) > > And now the menu icons to the iframe apps have just disappeared when https is > > on. Great! Resolved! > > Hi... I almost had heart failure too... Until I checked the app itself. If you > look at Facebook Integration, the bottom section, you will see that they have > added a couple new fields. It's intuitive... make a couple changes and you > should be good to go. I was. Whew. The only problem now is that Facebook is forcing us to have an SSL url for old FBML apps. Should this be the case? The user never directly communicates to the app server only to the Facebook server. Also it seems Facebook is appending the Tab URL/Secure Tab URL to the Canvas URL which is now a problem because the secure tab url field only accepts urls with https.
I've followed this thread and it has been very helpful, especially the info about the extra field for the secure tab url. That said there never really was a bug Facebook has suggested people set to secure so that have a safer trip through Facebook. Users have followed the advice and are traveling securely. So the result is if you want to be a developer on Facebook you will need a secure url. If you don't get one you won't be able to play on the playground anymore. What does this mean for Developers, that people will be coming to us for the solutions and we will have more opportunities. If you are just looking for a stable Iframe to put your content in that I have made and I will post that solution here shortly. I only started last week as a Developer and the only thing that saved me in all this was I am a PHP programmer so I could pick up bits and pieces and put it together. Bottom line is get a Certificate and make your offerings seamless for everyone and don't make them have to choose between you and their security level. Martin
(In reply to comment #140) > > Bottom line is get a Certificate and make your offerings seamless for everyone > and don't make them have to choose between you and their security level. > > Martin Hi Martin. You summed it up absolutely perfectly really, and also within your comment that is some interesting points made. But, ultimately, Facebook has provided the enhanced security that users will adopt as more and more of them become aware of the setting, and we as developers have to do whatever we have to do for our clients to ensure that their content remains visible no matter whether the next reader is using HTTP, HTTPS, if they are logged in or not, if they like the page or not. But going back to your summary, the most important word in there is "seamless"! We have to make it seamless for every reader that visits one of our pages or one of our clients pages. That is the bottom line. How we do that can be somewhat confusing and does require a little bit of tweaking of the code used in our I frame content. Having a security certificate is one important part, and I wrote about a number of code edits that I have found to be extremely useful; here is a link to my note on Facebook: http://www.facebook.com/note.php?note_id=10150133881999417 don't worry you don't have to like my page will subscribe to anything to read it. Martin
In the Facebook Integration page, in the new fields at the bottom, it says "Facebook pulls content for your tab from this URL, which must be relative to your Canvas Page" next to the Tab URL field. Do we put the entire iFrame URL in that field http://mydomain.com/mydirectory/index.php or just the "index.php" part? In the Secure Tab URL field, it seems to need the entire iFrame URL, ie. https://mydomain.com/mydirectory/index.php. Is this correct?
(In reply to comment #142) > In the Facebook Integration page, in the new fields at the bottom, it says > "Facebook pulls content for your tab from this URL, which must be relative to > your Canvas Page" next to the Tab URL field. > > Do we put the entire iFrame URL in that field > http://mydomain.com/mydirectory/index.php or just the "index.php" part? > > In the Secure Tab URL field, it seems to need the entire iFrame URL, ie. > https://mydomain.com/mydirectory/index.php. Is this correct? Yes. You do now. Previously it was just the file but now it's the entire URL.
I thought I would pass this on for the developers using PHP. This is what I do to deal with knowing whether I should be using HTTP or HTTPS: $ref=@$HTTP_REFERER; if($ref[4]=='s')$usehttps=1; $facebookconnect=($usehttps) ? 'https://connect.facebook.net/en_US/all.js' : 'http://connect.facebook.net/en_US/all.js'; Martin
(In reply to comment #139) > (In reply to comment #137) > > (In reply to comment #136) > > > And now the menu icons to the iframe apps have just disappeared when https is > > > on. Great! Resolved! > > > > Hi... I almost had heart failure too... Until I checked the app itself. If you > > look at Facebook Integration, the bottom section, you will see that they have > > added a couple new fields. It's intuitive... make a couple changes and you > > should be good to go. I was. Whew. > > The only problem now is that Facebook is forcing us to have an SSL url for old > FBML apps. Should this be the case? The user never directly communicates to > the app server only to the Facebook server. > > Also it seems Facebook is appending the Tab URL/Secure Tab URL to the Canvas > URL which is now a problem because the secure tab url field only accepts urls > with https. Looks like a fix for the FBML secure tab url was pushed sometime last night. FYI you don't need a SSL certificate for FBML apps.
(In reply to comment #145) > (In reply to comment #139) > > (In reply to comment #137) > > > (In reply to comment #136) > > > > And now the menu icons to the iframe apps have just disappeared when https is > > > > on. Great! Resolved! > > > > > > Hi... I almost had heart failure too... Until I checked the app itself. If you > > > look at Facebook Integration, the bottom section, you will see that they have > > > added a couple new fields. It's intuitive... make a couple changes and you > > > should be good to go. I was. Whew. > > > > The only problem now is that Facebook is forcing us to have an SSL url for old > > FBML apps. Should this be the case? The user never directly communicates to > > the app server only to the Facebook server. > > > > Also it seems Facebook is appending the Tab URL/Secure Tab URL to the Canvas > > URL which is now a problem because the secure tab url field only accepts urls > > with https. > > Looks like a fix for the FBML secure tab url was pushed sometime last night. > FYI you don't need a SSL certificate for FBML apps. I lied, I thought it was working but it's still the same. This is what I get, as you can see it's still appending the tab url to the canvas url for FBML apps. App temporarily unavailable The URL http://xxxxxxx.live.xxx.com.au/offers/http://xxxxxxx.live.xxx.com.au/offers/offers.php returned a 404 Not Found error. I've lodged a bug here http://bugs.developers.facebook.net/show_bug.cgi?id=15963
*** Bug 15861 has been marked as a duplicate of this bug. ***
(In reply to comment #144) > I thought I would pass this on for the developers using PHP. This is what I do > to deal with knowing whether I should be using HTTP or HTTPS: > > $ref=@$HTTP_REFERER; > if($ref[4]=='s')$usehttps=1; > $facebookconnect=($usehttps) ? 'https://connect.facebook.net/en_US/all.js' : > 'http://connect.facebook.net/en_US/all.js'; > > Martin Interesting? I read a few different PHP / JS ways of auto detecting the protocol and found some were more reliable than others (some depend on the server). The one I opted for is the "Protocol-Relative URL" which is basically dropping https: or http: from the URL of embedded content. So, a link to Google hosted JQuery, for example, would look like this: <script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script> and, the page/browser would automatically request the JS file using http or https depending on if the parent URL was secure or not. I shall give your snippet of code a whirl sometime though... Good input Martin!
This is not fixed. Go here: http://www.facebook.com/BeYU.fb See the tab / bookmark called "discover". Now, go here: https://www.facebook.com/BeYU.fb It disappears. I believe the issue is, if a secure connection is made to a friendly facebook url (eg. www.facebook.com/friendlyurl) then, this bug occurs.
(In reply to comment #149) > This is not fixed. > > Go here: > > http://www.facebook.com/BeYU.fb > > See the tab / bookmark called "discover". > > Now, go here: > > https://www.facebook.com/BeYU.fb > > It disappears. > > I believe the issue is, if a secure connection is made to a friendly facebook > url (eg. www.facebook.com/friendlyurl) then, this bug occurs. My friend... this *is* fixed. If it weren't, many more folks would be complaining here. And I would be one of them. I may be misunderstanding your post, which is why I'm taking the time to reply. I went to both links. When I went to http I could see the tab. When I went to https I could not. Simple. So since all of *my* tabs and everyone else's are working, and yours are not.... *Maybe* you have not supplied the correct secure link in the Facebook Integration section of your app. Are you hosting the tab content in both http and https on your domain?
"*Maybe* you have not supplied the correct secure link in the Facebook Integration section of your app." Sorry I must of missed that memo (the need to specify a secure url). I'll do that, yes I have both http and https version. Thanks for taking the time to let me know. Cheers.
(In reply to comment #151) > "*Maybe* you have not supplied the correct secure link in the Facebook > Integration section of your app." Sorry I must of missed that memo (the need > to specify a secure url). I'll do that, yes I have both http and https > version. Thanks for taking the time to let me know. Cheers. Vince- Tim Ware at HyperArts has probably written the best tutorial about this at http://www.hyperarts.com/blog/adding-iframe-application-to-facebook-fan-page/ We're all in this together. Good luck. :)
Could someone from FACEBOOK express the intent of FACEBOOK? Is it your intent that if a user checks "Browse Facebook on a secure connection (https) whenever possible" that they only see apps served over https? Or is it your intent that http content be served when https content is not available? We as developers need to make decisions based on this and we're all fumbling around guessing at your intent. I'm fine if facebook is going all https, just tell us - and change that account setting to "Always browse Facebook over a secure (https) connection." If you're not ready for that step and you want to fix it so that non-secure tab apps work for users who checked that infamous box that's fine too, but tell us.
jokeefe, Facebook *has* officially ruled on this. Their developers' blog post from Friday says, "Please take some time to add a “Secure Tab URL” as if you have not, we will not be able to show your tab to users browsing Facebook over HTTPS." https://developers.facebook.com/blog/post/482
(In reply to comment #154) > jokeefe, Facebook *has* officially ruled on this. Their developers' blog post > from Friday says, "Please take some time to add a “Secure Tab URL” as if you > have not, we will not be able to show your tab to users browsing Facebook over > HTTPS." https://developers.facebook.com/blog/post/482 Jeffrey- thanks for the kind but firm reply. I shall be less kind. This bug has been marked "RESOLVED FIXED" and if participants to this thread would *please* take the time to read *all* of the previous comments before continuing to complain about this "bug" it would be appreciated by all of us who *have* taken the time to do so. THIS IS NO LONGER A BUG. Facebook has essentially *required* (for all practical purposes) that your content be hosted securely. Deal with the new reality and get about setting up and hosting your apps properly.
(In reply to comment #155) > (In reply to comment #154) > > jokeefe, Facebook *has* officially ruled on this. Their developers' blog post > > from Friday says, "Please take some time to add a “Secure Tab URL” as if you > > have not, we will not be able to show your tab to users browsing Facebook over > > HTTPS." https://developers.facebook.com/blog/post/482 > > Jeffrey- thanks for the kind but firm reply. > > I shall be less kind. > > This bug has been marked "RESOLVED FIXED" and if participants to this thread > would *please* take the time to read *all* of the previous comments before > continuing to complain about this "bug" it would be appreciated by all of us > who *have* taken the time to do so. > > THIS IS NO LONGER A BUG. Facebook has essentially *required* (for all practical > purposes) that your content be hosted securely. Deal with the new reality and > get about setting up and hosting your apps properly. KEN - You the man!!! You read my mind. I appreciate there are a few people who have missed the recent news and have jumped on this thread in a panic but please, if you read through the threads and *do your home work* (yes, we've all lost a little bit of hair), you'll be up to speed in not time. For at least 2 weeks there have been no issues with https if the app and iframe is set up correctly. I wrote a few notes about security issues, here's one: http://www.facebook.com/note.php?note_id=10150133881999417 Hope it helps. Martin
(In reply to comment #156) > (In reply to comment #155) > > (In reply to comment #154) > > > jokeefe, Facebook *has* officially ruled on this. Their developers' blog post > > > from Friday says, "Please take some time to add a “Secure Tab URL” as if you > > > have not, we will not be able to show your tab to users browsing Facebook over > > > HTTPS." https://developers.facebook.com/blog/post/482 > > > > Jeffrey- thanks for the kind but firm reply. > > > > I shall be less kind. > > > > This bug has been marked "RESOLVED FIXED" and if participants to this thread > > would *please* take the time to read *all* of the previous comments before > > continuing to complain about this "bug" it would be appreciated by all of us > > who *have* taken the time to do so. > > > > THIS IS NO LONGER A BUG. Facebook has essentially *required* (for all practical > > purposes) that your content be hosted securely. Deal with the new reality and > > get about setting up and hosting your apps properly. > > KEN - You the man!!! You read my mind. > > I appreciate there are a few people who have missed the recent news and have > jumped on this thread in a panic but please, if you read through the threads > and *do your home work* (yes, we've all lost a little bit of hair), you'll be > up to speed in not time. > > For at least 2 weeks there have been no issues with https if the app and iframe > is set up correctly. > > I wrote a few notes about security issues, here's one: > http://www.facebook.com/note.php?note_id=10150133881999417 > > Hope it helps. > > Martin Hey Martin... thanks for the comments. In re reading my comments I realize that I was a bit unsympathetic to those who are awakening to this reality. Thanks for putting the balance on it. My bark is worse than my bite and though I sounded harsh... I do care. Yes, we have all lost a bit of hair over this issue, and if anyone is still struggling and needs help... post a genuine question in here (and tell us you've read all the previous comments) and I will be happy to try to help. And I'm betting that Martin might weigh in with a helping hand too.
(In reply to comment #157) > if anyone is still struggling and needs help... post a genuine > question in here (and tell us you've read all the previous comments) and I will > be happy to try to help. And I'm betting that Martin might weigh in with a > helping hand too. Sure will Ken. Always glad to help anyone! I think between us and various other contributors to this thread we've seen all the issues and found ways of working with them - even the ones that are merely a consequence of https that Facebook doesn't have a magic cure for.
Hey guys guess what? I've been following 15200 for weeks and I understand the issue technically. Just before I posted I reread the entire thread and since at least as far back as comment 125 there have been doubts about this fix and I was wondering about Facebooks perspective on the issue. Jeffrey was helpful in pointing me to recent information outside this thread which answered the question to my satisfaction and now I know what I need to do. I guess I seemed a little snarky mentioning facebook twice in one sentence and capitalizing it but I was just trying to emphasize that I wanted to hear from facebook as opposed to the developer community following this bug. Now I've read the blog post and I understand the intent of Facebook moving forward. Like I've said, I've been following this bug and I know it generates a lot of email and that can be frustrating but not having read the recent blog post I feel I had a legitimate question.
(In reply to comment #159) > Hey guys guess what? I've been following 15200 for weeks and I understand the > issue technically. Just before I posted I reread the entire thread and since at > least as far back as comment 125 there have been doubts about this fix and I > was wondering about Facebooks perspective on the issue. Jeffrey was helpful in > pointing me to recent information outside this thread which answered the > question to my satisfaction and now I know what I need to do. I guess I seemed > a little snarky mentioning facebook twice in one sentence and capitalizing it > but I was just trying to emphasize that I wanted to hear from facebook as > opposed to the developer community following this bug. Now I've read the blog > post and I understand the intent of Facebook moving forward. Like I've said, > I've been following this bug and I know it generates a lot of email and that > can be frustrating but not having read the recent blog post I feel I had a > legitimate question. Hi Jokeefe.. please accept my apologies... as I mentioned to Martin, I was a bit terse. So again... I apologize. Maybe others will be saved some frustration by our conversations here... if so... it will have worth it. :)
Did this just break again for anyone else?... All of our custom tabs just appear blank now and we didn't change anything. They were working perfectly up until this evening and then *poof* they disappeared -- no error or anything.
(In reply to comment #161) > Did this just break again for anyone else?... All of our custom tabs just > appear blank now and we didn't change anything. They were working perfectly up > until this evening and then *poof* they disappeared -- no error or anything. Yeah, see here http://bugs.developers.facebook.net/show_bug.cgi?id=16102
Ah thanks didn't realize they were broken for Non-SSL users also! Uggg. I hate Tuesdays.
I do not think this bug has been "solved." Not to a "satisfactory" level. Having the canvas to have to REQUIRE an https location is not a good enough fix. Many small businesses and self employed individuals that create fan pages and apps are not going to want to shell out money to get a secured certificate for their domain to deploy these apps. A more "turnkey" solution for the lay person must be developed. To me this is a critical issue that must (and should have been) resolved prior to any https enforcement.
(In reply to comment #164) > I do not think this bug has been "solved." Not to a "satisfactory" level. > Having the canvas to have to REQUIRE an https location is not a good enough > fix. > > Many small businesses and self employed individuals that create fan pages and > apps are not going to want to shell out money to get a secured certificate for > their domain to deploy these apps. > > A more "turnkey" solution for the lay person must be developed. > > To me this is a critical issue that must (and should have been) resolved prior > to any https enforcement. take a look at this https://www.startssl.com/ free class 1 certificates, these should suffice for facebook.
(In reply to comment #165) > (In reply to comment #164) > > take a look at this > > https://www.startssl.com/ > > free class 1 certificates, these should suffice for facebook. Free? You've got to be kidding? Anyone developing apps / iframe content surely has the money to buy their own SSL certificate? Anyone desperate enough to need a free SSL cert is having a laugh, surely. I honestly do not understand why a few people insist of pointing fingers at Facebook saying "we shouldn't be forced to have a secure this and httpps the other"... Well don't have one then. Don't allow your readers to browse securely, don't be professional about it... But please don't keep blaming Facebook because they are not handing everyone the ability to be Facebook page developers without needing to learn anything or figure anything out for themselves. There are plenty of us who will, and have, happily work out how to do things and have been quite happy to buy a real SSL certificate and work WITH Facebook to make things work... The end result is far better than constantly telling Facebook something doesn't work or we can't do XYZ, please can you make it simple for us to look like "experts"... Come on, give us a break. Facebook has done a brilliant job recently. They have listened and fixed what needed fixing. They have restored features that had been removed, because so many people asked for them. They have corrected a few of their own glangers and pretty much done everything we have asked for... They give us a free marketing platform and all we have to do is learn a few things and, to be completely professional about it, buy a $40 SSL certificate for our hosting domain... Hardly an unfair deal, is it? *** Sorry if this seemed a little harsh but, as someone who has spend hours, days, weeks testing and working within the (changing) parameters set by FB over the past weeks / months - and as someone who diligently creates content that is 100% functional across all browsers and for people using https, I get a little rattled by people wanting an easy ride...
I don't disagree that the professional thing to do is to get an SSL certificate for your servers. The only thing I'm disappointed in Facebook is the lack of warning on this, as it was a breaking change that didn't exist before. I would have liked to see this announced on the road-map and blogged about prior to HTTPS being enforced on tabs. The paradigm for iframe tabs borrowed heavily from iframe apps, and so many developers assumed (in light of little communication about it) that Facebook would handle SSL for tabs similarly, that is, to prompt the user to choose to drop out of HTTPS browsing to view the tab, or to stay secure and not view the tab. Facebook has rejected this solution and already posted on their blog their solution (the current one) requires an SSL cert for HTTPS users. I understand WHY they made the choice they did, but with a little lead time the SSL certs could have been in place prior to the change going into effect. Some people don't have direct access to the server or work with clients that can't turn an SSL cert around in a few days (or even weeks), due to a myriad of reasons, and in the meantime their tabs are broken.
The status of this bug report has been "Resolved" for over 7 days. We are closing it to make sure that all bugs in the system have accurate statuses. Closed bugs can't be re-opened since if 7 days have passed since the issue was resolved, even if you're seeing similar symptoms, the underlying cause is probably different so it's best for everyone if you file a new bug with detailed repro steps (you can always include a link to this bug). For the future, remember that if you're ever still experiencing an issue after we've marked a bug as "Resolved" (as in it was fixed or we need repro steps), make sure you "reopen" the bug (change the status from "Resolved" to "Reopened") so that we will see your response (which should include details on how to reproduce the issue). Thanks!
