JFBC - Open Auth?

Guero,
You're correct about the session key coming back. That's actually normal, depending on the browser. I can't tell from the shot, but I'd guess you were using Firefox.

Either way, it's not that the key comes back over the URL, it's that there are no other 'loads' of external content on the page that is loaded. As you'll see in Charles, the response code is 303, which is a redirect from the page Facebook returns the user to. So the flow looks like:
1) Login to Facebook
2) Facebook redirects to yoursite.com/index.php?option=com_jfbconnect&task=loginregister&session=xxxx
3) JFBConnect then 303 redirects the user to a new page on your site without the session variable in the URL

At stage 2, if 3rd party content is being loaded, then yes, JFBConnect is leaking data. If at stage 3, 3rd party data is being loaded, that's fine.

I can't tell from your log page, because it doesn't go past the login page, but if you can look at any external loads (to Google Analytics for instance), you should be able to see what the "header referrer" is. This should be the URL on your site that you're telling the 3rd party is requesting the data. If that referrer URL from your site has the session key, then yes, something bad is happening. If not, then that is the correct behavior.

Hope that makes sense. We'll start doing some additional tests with Charles now. Thank you for your feedback, and let us know what happens a few lines further down in the log. Also, if you wouldn't mind, please PM us the URL of your site (I know I've been before but can't remember). We'll test with Charles and Fiddler and see if we see any issues. So far, we haven't found any issue yet, but if there is one, we definitely want to find it.

Just tested with Charles, on Mac, on SourceCoast.com. Basically, what you want to do after the line you have highlghted in your screenshot (with the 303 redirect), is look for any Hosts that are not Facebook.com or yourdomain.com. Click on them, and then in the bottom panel, select "Request" and "Headers". You'll see the referrer in the box at the bottom.

This referrer for any of the external sites should not have the session key in the string. If it does, please let us know. Also, if it does, definitely PM us your site so that we can Charles and Fiddler it up to see why and how it's behaving differently than we'd expect.

Thanks again for your report, and we look forward to more status!

Sorry for the spam.

Another thing in Charles to test is simply using the Search (binoculars) and look for "session_key". The only domains that should come up are Facebook.com and yoursite.com. It can come up for plenty of requests, because the session_key is stored in the cookie. It should not come up for any other domains other than the 2 above.

Again, hope this helps, and thanks for the PM. We just tested your site (and created the account testjfbc, feel free to delete). We did not see anything that would worry us about your site and the way JFBConnect is handling the session_key on it.

Guero,
Excellent observations, and we're still investigating a lot, so we don't have all the answers right now. We still see no way that JFBConnect is leaking data, and would (again) highly recommend that anyone who's received the email to respond to it to let Facebook know that you don't think it's an issue on your site and that you think you received the email erroneously.

As for your specific questions:
i) Why the session_key isn't shown in our video: The session_key really shouldn't be passed by the URL. It should be set by Facebook in a cookie. However, even if it is passed by the URL, JFBConnect correctly strips it from URL as required. Initially, we thought this was because of a few browser differences and Facebook would include the key in the URL in some cases. We not sure that's the case now, and are trying to understand why. There are a few things to note that may make a difference, but we haven't seen a change yet in our testing:
1) In your Facebook application, please check the Advanced tab, and see if the "Remove Deprecated Auth Methods" setting is enabled or not. This should be able to be disabled without issue, and we'd recommend doing it.
2) On your page, we're seeing a Javascript error. In the body tag is a call to onLoad=setFocus(). Since this doesn't exist, that's a problem. While I don't think that's the problem, it could actually be interfering with how the cookie is set by Facebook and forcing them to send the key back in the URL. Please try to remove the Javacscript call/error.

ii) Loading 3rd party content is completely fine throughout your site. The only page that the content cannot be loaded on is the page that Facebook returns the user to after they've registered/logged in. This is the only time the session key can be sent in the URL, and therefore, the only time it could be intercepted by a 3rd party. On any other page, this isn't an issue.
Since Facebook returns the user to a special JFBConnect page (index.php?option=com_jfbconnect&task=loginFacebookUser) and because that page strips the session_key if it exists by redirecting the user to a new page, this is again not a possible data leak issue.

Technical or not, it's always best to understand your site Hope this helps explain, and definitely ask away with any questions you have!

Thanks for the update you received from Facebook. It seems this issue is starting to end, in our opinion. The Facebook Developer forums have a lot of posts from users who don't feel they're affected, and the email you posted above seems to be the form email sent out to anyone that says "We don't think we're affected."

Again, we do not think JFBConnect ever experienced this issue. Also, from this thread (and a few others in our forums related) as well as the amount (under 10) people that filled out our survey for configuration settings in JFBConnect, we simply think that Facebook was a little overzealous in their notification of some users that they're sites are vulnerable.

As for OAuth2.0 being able to be implemented right now, the answer is yes and no. In JFBConnect, we use a publicly available PHP library that Facebook distributes to use the current authentication scheme we are using (that still works with Facebook). They do allow applications to connect over OAuth2 currently and this will be required as of September 1st. They do not have a PHP library for OAuth2 authentication available yet, but it will be on July 1st.

We plan to move to this new library very quickly upon availability to have a long runway to the drop-dead date of September 1st. While it is possible we could write our own OAuth2.0 library to have something available in the early/mid June timeframe, it's a dead-end for us as then we'd still likely move to Facebook's public library which would have more features, be more tested, and simply better. So, yes, it's a bit of a catch22 when they notify our users to upgrade, and we do apologize you got caught in the snare.

Finally, from our daily scanning of the Facebook developer forums, we still have not seen an instance of a user's application being disabled (there would be loud complaints). It still is possible, I'm sure, if the application is leaking data as that's what started all of this, but I think there's been a decent amount of backlash which will hopefully make Facebook be overly cautious if they choose to disable a specific app.

Best of luck to you (and anyone else following this thread), and definitely keep us posted if you hear anything else.