One of the big developments in the March 2011 Facebook Page overhaul was support for iFrames in Fan Page custom tabs. Until then, iFrames were only allowed on canvas pages and, even there, required the user to click an image or text to “activate” (load) the iFramed content.
Custom iFrame Tabs Shouldn’t Mix Secure and Nonsecure Content
Because iFramed pages are hosted on non-Facebook servers — allowing developers to use standard Web coding (HTML, CSS, JavaScript, etc.) — they are subject to the same rules governing any other Web page. This includes making sure that pages aren’t coded to display both secure (linked using “https”) and nonsecure (linked using “http”) content when “calling” files (images, external CSS and JavaScript, etc.) to display on, or enhance the functionality of, the page.
In this article, I explain why Facebook custom iFrame tabs must now accommodate the many users now browsing Facebook under HTTPS, what files need to be secure — and how to make them secure — and various associated pitfalls developers must avoid.
I will also show how Amazon Web Services can provide a secure, economical and non-technical hosting solution for those with less experience in Web development and who are using an iFrame Custom Tab application like TabPress where you can add code but don’t have to create a Facebook app.
Facebook Introduces Secure Browsing (https)
In January 2011, Facebook announced a new account setting called “secure browsing (https)”:
Here is how Amazon Web Services describes their offering:
Starting today we’ll provide you with the ability to experience Facebook entirely over HTTPS. You should consider enabling this option if you frequently use Facebook from public Internet access points found at coffee shops, airports, libraries or schools. The option will exist as part of our advanced security features, which you can find in the “Account Security” section of the Account Settings page.
Jan 2011: Facebook Announces 9.6M Users Browsing Facebook over HTTPS
Developers should take this issue very seriously. On April 15, 2011, Facebook announced on the Developer Blog: “Today, 9.6 million people are browsing Facebook over HTTPS and the trend is continuing to increase. ”
Facebook secure browsing under HTTPS combined with iFramed content on Page tabs creates potentially BIG problems with browsers, problems that can be avoided.
Page Tab Applications MUST Specify a Secure Tab URL
Developers must make sure they specify a “Secure Tab URL” under “Facebook Integration” in the application editing interface:
If a Secure Tab URL isn’t specified, the tab will not display any content to a user browsing Facebook with “secure browsing (https)” enabled!
Of course, the domain specified in the Secure Tab URL has to have an SSL Certificate.
Admins will see this popup dialog if they try to access a tab on their Page that doesn’t have a Secure Tab URL specified:
Users who click on a tab while browsing under “secure browsing (https)” when that tab has no Secure Tab URL specified will be presented with the option to switch to HTTP browsing (this from the Redbull “Games” tab):
Facebook Enables Automatic Temporary Switching to HTTP
On April 19, 2011, on the Facebook Blog, it was announced:
Today, we’re improving HTTPS so if you start using a non-HTTPS application on Facebook, we automatically switch your session back to HTTPS when you’re finished.
This, of course, was driven by some very large brands whose apps wouldn’t work under HTTPS (the Redbull Fan Page has over 17M fans), but the benefit is to all of us, to some degree. But it doesn’t really affect the gist of this article: avoid mixing HTTP and HTTPS content that generates browser security warnings. I don’t think this “improvement” addresses that issue.
HTTPS Secure Browsing and Mixed Secure and Nonsecure Content Warnings
If a Page tab does have a secure URL, but the URLs for CSS, JavaScript, images or embedded files use the HTTP protocol instead of HTTPS, AND the Facebook user has opted for “secure browsing (https)” in the Account Settings, Internet Explorer, Google Chrome, Firefox and Opera create a fairly significant problem, displaying a warning when the tab attempts to load, either as a popup window (this example is IE 8):
or at the bottom right of the browser (this example is Firefox):
Make Sure You Avoid Calling ANY Files via HTTP!
First, remember this DOES NOT INCLUDE files you hyperlink to, such as other Web pages or websites, or PDF downloads, etc.
Files that MUST Be HTTPS to Avoid the Mixed Secure and Nonsecure Content Warning:
- Images — <img /> tag;
- External CSS (.css) and JavaScript (.js) files;
- Embedded files, such as Flash and Video. YouTube is served over SSL, so you can simply change its embed-video URLs from “http” to “https” and they work fine. (Unfortunately, Vimeo doesn’t yet serve its videos over SSL.)
<iframe title="YouTube video player" width="480" height="390" src="https://www.youtube.com/embed/A7F2X3rSSCU" frameborder="0" allowfullscreen></iframe> - URLs in your DOCTYPE or <html> tag:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="https://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> - Calls to the JavaScript SDK when incorporating Facebook Social Plugins:
<div id="fb-root"></div><script src="https://connect.facebook.net/en_US/all.js#appId=127182060688835&xfbml=1"></script>*See the note below on errors with Activity Feed and Recommendations tags.
Root-relative or File-relative URLs are OK
Root-relative or file-relative links avoid the issue of mixing secure and nonsecure content because they don’t specify either HTTP or HTTPS. So linking this way, if possible, avoids the mixed-content pitfalls:
Root-relative link, which begins with “/” representing the document root:
<link rel="stylesheet" type="text/css" href="/directory-name/stylesheet.css" />
File-relative link, where “./” or just the file name means same directory, “../” means one directory up:
<link rel="stylesheet" type="text/css" href="../my-css-files/stylesheet.css" />
Facebook Social Plugins Bug: XFBML Tags Pull in Profile Images Via HTTP!
The HyperArts Fan Page “XFBML Tags” tab — our test area for the XFBML Social Plugins — was persistently generating the secure/nonsecure content warning, even though I’d changed every URL to HTTPS, except of course links to external websites).
It turns out that even when a user is viewing Facebook under “secure browsing (https)”, Facebook pulls in the user profile images over HTTP rather than HTTPS for two XFBML tags: Activity Feed and Recommendations.
Of course, these two social plugins may be intended for use ONLY on external websites, and not for Facebook tabs. Whatever the case, I created a bug report on Bugzilla: Bug 16821.
Amazon Web Services (AWS): A Hosting Solution for Those Without a Secure Server
For those folks who are using an iFrame app that allows you to enter your own code (eg TabPress) and who don’t have access to a server with an SSL Certificate, I would recommend checking out Amazon Web Services, and specifically their Simple Storage Service (S3) product.
NOTE: You cannot use the S3 service to host the actual index page of an app (eg index.php). Facebook uses HTTP POST request to fetch the index page of an iFrame app, and S3 doesn’t support POST requests. You can, however, use the S3 service to host all other content you link to in your index page.
Amazon S3 provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from anywhere on the web. It gives any developer access to the same highly scalable, reliable, secure, fast, inexpensive infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers.
The service is free for the first year and then it’s pay as you go. Your free tier includes 5 GB of Amazon S3 storage, 20,000 Get Requests, 2,000 Put Requests, 15GB of data transfer in, and 15GB of data transfer out each month for one year. Once you start paying, the pricing is quite reasonable.
Images, video, CSS (.css) and JavaScript (.js) files can be stored, using either HTTP or HTTPS (just get the URL of the file you’ve uploaded and change it to the HTTP/HTTPS protocol you wish to use. You can even store all you website files using AWS S3. It’s pretty cool.
You create “buckets” and can create “folders” within them to organize your files. After uploading a file, you can get its URL by right-clicking it and selecting Properties. By default, the URL is HTTPS, but you can change it to HTTP if you’re not using it for a Facebook iFrame tab.
NOTE: Be aware that you can’t use SSL (https) on buckets that have a “.” in them, eg mybucket.bucket1.s3 etc. Use either a single name (eg mybucket) or use a dash “-” instead (eg mybucket-bucket1.s3 etc). (Read more about bucket limits and restrictions.) (Thanks to David Heriot!)
Access Denied Error: Edit Your Bucket Policy
If you try to access the object you uploaded via the URL in Properties, and you get this error: “This XML file does not appear to have any style information associated with it. The document tree is shown below.”
There’s a fix. You highlight the bucket and click “Edit bucket policy” in the bottom screen, under Properties > Permissions:
Paste in this policy:
{
"Version": "2008-10-17",
"Id": "c2f6151d-4f3c-4381-8569-15f0ef85e107",
"Statement": [
{
"Sid": "AllowPublicRead",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::YOUR-BUCKET-NAME/*"
}
]
}
Make sure you replace “YOUR-BUCKET-NAME” with the name of the bucket whose policy you’re editing.
Other Resources
- Amazon Web Services S3 forum discussion on HTTPS issues with Facebook iFrame tabs
- Amazon Web Services – Definitions, Etc.
- Amazon Web Services: Access Denied Error
- Information Week: Facebook iFrames: Good For Business, Bad For Security?
- How to Host an Entire Website on Amazon S3
- Ars Technica: HTTPS is great: here’s why everyone needs to use it (so we can too)
Pingback: HTTPS+Facebook Apps: Who Gets Left Behind? | Bit Social Media
Pingback: Facebook Pages SSL Deadline Approaches