Facebook's cross-domain upgrades
If you've read any postings about Facebook's cross-domain handling code, Facebook has gone to great lengths to implement support for it between most modern browsers. The main use case is Facebook's Login Social Plugin, which opens a popup window that prompts to fill out a form that will prompt you for your email/password:
This popup needs to communicate with the parent window to send back information about what to do next upon successful login. Since the parent window is most likely a page hosted on your site and the popup is a window hosted from facebook.com, there has to be a way for a successful login to pass a message between windows hosted on different sites. Usually browser same-origin security policies will prevent such data exchanges, but there are legitimate use cases to allow messages to pass between windows, which is why the HTML5 postMessage function was introduced.
Now these 3 different states are no longer shown and embedded as FORM values inside the popup window, depending on the user interaction. For instance, there is now a cancel_url FORM input value that will close the popup window and return control back to the original frame.
3. Within the fb-root tag, there is now an iFrame with the ID fb_xdm_frame_http or fb_xdm_frame_https (depending on the protocol) that will implement the cross-domain receivers, whether they implement via postMessage, Flash, or IFrame's. You can also figure out which transport mechanism by looking at the channel= query parameter.
The most important information passed is the callback (cb) querystring parameter, which contains a global unique identifier (guid) that corresponds to a key in the FB._callbacks dictionary that is used to load the code that is loaded. This callback function should correspond to a key in the parent window. If you close that parent window, you may notice a blank dialog permissions.request screen if you were to login.
< iframe id="fb_xdm_frame_https" name="fb_xdm_frame_https" src="https://s-static.ak.facebook.com/connect/xd_arbiter.php?version=6#channel=f38dfabf84&origin=https%3A%2F%2F[MY_APP_HOSTNAME]&channel_path=%2F%3Ffb_xd_fragment%23xd_sig%3Df3b4c64464%26&transport=postmessage"></iframe >
In summary, the big win here is that IE8 now uses the native HTML postMessage and therefore no longer depends on the Adobe Shockwave/Flash Add-On in your browser. You can also uncover which transport mechanism within the iFrame's stored inside the fb-root div tag that you use.
If you want to better understand how all the cross-domain messages get passed, I've found it useful to deminify the all.js code, substitute the script include, and then putting a breakpoint on the xdRecv handler. This allows you to see how Facebook decodes the query string parameters in xd_arbiter.php, extracts the callback function guid, and executes the code to set the appropriate cookies on your browser with the signed token response.
blog comments powered by Disqus