3.0 FBToolkit.Samples.IFrame Doesn't work

Nov 10, 2009 at 2:28 AM

Anyone have any luck using the new toolkit?

Running the sample provided takes the application completely out of Facebook.  I do not see the Facebook Headers.  Am I missing something here?  I would love to upgrade, but it seems as though the documentation and sample code are not complete.

Nov 10, 2009 at 4:40 PM

Do you have it setup as a facebook app with facebook?  are you navigating to it via http://apps.facebook.com/yourapp ?

Nov 10, 2009 at 9:42 PM

I do actually.  I was using v2.1 and was updating my code.

This behaves completely different than v2.1.  taking your advice I hit the apps.facebook.com/myapp url and was able to get to the embedded iframe as expected.  however, clicking on any other link takes me right back out. 

and to top it off, the sample application for iframe uses the feed.publish api which is being decomissioned dec 20th.  so you cannot setup a template to run the sample.  documentation and samples for this release isn't where it should be.

Nov 11, 2009 at 2:29 AM

Yeah, I'm getting dumped out of the facebook chrome as well with any re-directs with 3.0

Nov 11, 2009 at 2:47 AM

I'm trying to port my 2.1 app to 3.0.  I set the RequireLogin property to true as it shows in the sample, and now every link I try to go to dumps me back to my default page.  I commented out setting of RequireLogin and I seem to work.  Although now I'm having trouble getting FQL to work...

Nov 11, 2009 at 2:40 PM

I have not tried this yet as I am hoping someone else has had better luck and a different solution. 

The only thing I can see is if you create two master (one with login required and the other without).  The default page for the site uses the one with login and all subsequent ones uses the one without.  This seems a little cloogy though and is a total 180 in functionality from 2.1.

Developer
Nov 11, 2009 at 9:21 PM

I've looked into the issue, and it looks like this is a combination of a couple of bugs in the toolkit, and an inherent complexity in using iframes. When you click a relative link in an iframe (like <a href="NextPage.aspx">), it sends a request to your callback URL for that page, but without any of the query parameters that Facebook usually sends for authentication purposes. The toolkit should either check for a cached session from the user's cookies, which may or may not exist, or redirect to the login page.

However, the cached session won't get picked up in this case since we're using some incorrect logic to check if the session is still valid. Then when the redirect to the login happens, a certain query parameter isn't getting passed, so that the login page redirects directly back to your callback, instead of to your canvas page. Technically, though, if you're getting sent to the login page, then that's already a problem, since it will send you to your main canvas page URL instead of the other page you wanted to go to (eg. NextPage.aspx).

The issue is discussed in a bit more detail on the Facebook Developer wiki here: http://wiki.developers.facebook.com/index.php/Choosing_between_an_FBML_or_IFrame_Application#Authentication. It looks like the best solution is actually to use an absolute link instead, and specify target="_top". This will reload the entire page, instead of just your iframe, which means Facebook will send the correct parameters again, as well. It's not a perfect solution, but it's the best I've seen so far.

Issue 14435 seems to be related to this issue, as well, so I'll try to post some updates there. I'll check in the fix in a bit, so people can at least get it and use cookies as a partial solution if they want.

Developer
Nov 11, 2009 at 9:27 PM

The fix is checked in as changeset 39685. Keep in mind that this is only a partial fix. It still doesn't fix the situation where the session login has expired, or where the browser doesn't accept cookies (supposedly Safari has a problem with this, according to the above Facebook wiki link). I'm going to ask for feedback on Issue 14435, so if you have any other suggestions on how to better fix this in the code, please tell us there.

Nov 11, 2009 at 9:40 PM

thanks for the quick response.  without really knowing what the code differences are between 2.1 and 3.0, i would have to think that if you did what you did in 2.1, we would be good.  the behavior between the two is completely 180. 

from a usability, the required login call in the master page should check and post correctly.  the fix you suggested for using absolute urls and specifying target="_top" would require most of existing users to make some major code changes to existing code.  that's not really a great way to launch an upgrade in my opinion.

i'll download the temporary fix and provide more feedback.  thanks for the immediate attention to this matter.  i would also suggest changing the sample for using master pages in iframes to not use the feed.publish since it is being decomissioned.

Developer
Nov 11, 2009 at 9:55 PM

Just realized that this doesn't work for the case where the user removed the app, but now wants to add it again. Working on a fix.

Developer
Nov 11, 2009 at 10:20 PM

Fixed the check, again (changeset 39697). Now it should check both situations: that the cache has not yet expired, and that the user did not remove the app.

tanman, the one problem with the 2.1 code is that it didn't check for expired sessions. So, if you're not using infinite sessions and the user leaves the app open for an hour and then tries to do something (probably a rare case, I realize), they'll get some sort of exception. This should at least redirect them back to the login page, instead.

Could someone please test this with an FBML app, as well? I currently don't have an FQDN to use for testing.

Nov 11, 2009 at 10:31 PM

thanks for the responses.  i did encounter that in 2.1 i believe.  i am assuming that you are referring to an exception that gets thrown saying the session has expired.  i noticed that behavior if two people login using the same browser session and the 2nd person was adding the app for the first time.

in this case i trapped the exception and just displayed a generic session message telling the user to open a new browser to establish a new session.  i'll implement this new release this week and provide feedback.

Nov 13, 2009 at 12:31 PM

just wanted to report to everyone following that i have successfully built changeset 39697 and the behavior so far is consistent with the prior 2.1 release.  only thing i encountered was the TFS settings in the Facebook project.

http://weblogs.asp.net/jeffwids/archive/2009/08/25/unexpected-error-encountered-opening-visual-studio-project.aspx - this will explain how to remove it.

many thanks to jschuster for making the changes and support.  i am doing further testing and releasing to production after some enhancements.  i encourage everyone to do the same so we can provide feedback and continue to help stabilize this release.

Nov 14, 2009 at 4:10 PM

I think I am still seeing an issue in this area where the user grants offline_access, which changes the session key to an infinite session key, and then subsequently revokes offline_access (using the edit application settings page).  This makes the session key being used by the toolkit invalid (a new temporary session key is issued, but the toolkit doesn't get it) and causes an exception when the toolkit tries to make further API calls.