John's Blog: 3rd Party Frames
June 26, 2012
A couple of weeks ago, I wrote about the technique of wrapping a Rumpus service inside a frameset, either to "cloak" the server's access URL or to better integrate it with an existing Web site. It turns out the timing on that was pretty poor...
Back in February 2012, news broke that Google had been using some questionable work-arounds to track Safari user activity. (Check out the Wall Street Journal article for details.) In response, Apple changed some of the privacy rules in Safari, including blocking use of "3rd party cookies" even when the user manually submits a form to the 3rd party site, as is the case with a Rumpus user login.
A 3rd party frame involves the technique of having a Web page served from one Web server embed the contents of another Web server. There are a couple of reasons why you might use a 3rd party frame page:
- Server Integration
Your primary Web site probably has a common look to all the pages on the site. An easy way to apply the same appearance to your Rumpus service is to create a page on your primary Web site that includes your logo, help text, and other common elements. That page could then include the Rumpus service in a frame so that it appears more integrated with your main Web presence rather than as a stand-alone server.
- DNS Hosting
Some DNS services also use the technique. In this case, your domain name (let's say, "files.acme.com") doesn't actually point to your server, and instead always points to the DNS provider's Web server. When a request reaches "files.acme.com", the DNS provider's Web server responds with a framing page that has no other content at all but embeds your server within it. Some DNS providers offer this as an extra feature, usually referred to as some form of "masking".
In this case, the end-user interface is exactly the same as if a user connected to your server directly, and you might not even be aware that it's happening. It's easy enough to tell, though... Access your server using the usual domain name in your browser and use "View Source" to see the page. If the login page source is just a few lines and includes a "frame", "iframe" or "frameset" tag, then your DNS host is embedding your server in a page their Web server is sending to clients. If you see the full login page HTML, then the contents are coming straight from your Rumpus server.
Regardless of the reason it's used, if you want to support Safari clients, they'll need to connect to your server directly, and you should not use a 3rd party frame. As of this writing, I have not found a reasonable work-around for the problem, and must simply recommend that servers that require user login (like Rumpus) just not be wrapped in a frameset that comes from another server.
If you use a frame to include Rumpus in your primary Web site, offer a simple link to the Rumpus server instead (possibly using a pop-up window to leave your primary site available in the background). If the 3rd party frame is used as part of your DNS setup, disable that feature so that the domain name always points users directly to your server.
If and when a solution that allows frames to be used with Rumpus, you can be sure I'll post about it here.
If you use Safari 5.1.5 or later but don't have this problem, you might be saying, "but John, it works for me." That's because Safari remembers sites from which it has previously accepted cookies, and you've previously accessed your server without going through a frame. Once you do that, Safari will happily continue to process cookies, 3rd party frames or not. In Safari, use the "Reset Safari ..." function to clear your cache and past cookies, and you'll see that the problem now affects you as well.
