How come Spring Social's samples request for permissions look different than my flow?

[rickcr]

When I attempt to signin with facebook with spring social showcase, and I hadn't accepted permissions yet, I get a nice page that looks like the following: (circles in red are my doing of course):

https://img.skitch.com/20111116-fdxj...dxwhyhrcdg.jpg

Note how in the above 'access basic information' and 'post to facebook as me' is all on one screen and then at the bottom you have "allow" or "leave app."

In my flow, there are two screens that come up. The first one is the one asking about basic information and it looks vastly different and has a "log in" button?

https://img.skitch.com/20111116-mgm2...1k9mxnai72.jpg

Then if you accept that you get ANOTHER screen for the "post to facebook" acceptance, yet its buttons are different:

https://img.skitch.com/20111116-tq1w...5c36rw4et6.jpg

What's incredibly insidious for me is if I click "don't allow" in that last screen, I'm still brought to the join page and the providerSignInAttempt is in scope so after the user completes the join form my app thinks they are valid and ads a user connection. (What should happen is it should simply go back to the signin form just like it does in the showcase.)

The first thing I have to figure out is why is my acceptance flow so radically different?

I am requiring more permissions

Is there something special I need to setup on facebook app's end?

[habuma]

What you're seeing in your app's case is the new Facebook permissions dialog (which was originally announced at F8 back in September). Currently, it's still in beta and is opt-in thing for apps and I just haven't switched Spring Social Showcase to use the new permissions dialog.

In the old version, *all* permissions were presented to you as one long list. In the new one, there are users/friends permissions and extended permissions. The users/friends permissions appear on the first screen, followed by extended permissions on the 2nd screen. There are other differences, but that's the most noticeable. Also, from what I understand, the users/friends permissions are non-revocable, but the extended permissions may be revoked by the user without revoking the entire application access. You can see more about it at https://developers.facebook.com/docs...authentication.

[habuma]

FWIW, I just turned on the "Enhanced Auth Dialog" setting for Spring Social Showcase, so it should look similar to yours now.

[rickcr]

Ahhh ok interesting. Thanks for that head's up.

This has me wondering if possibly a useful utility class as part of the spring social web core would be useful. I'm currently using one myself in my current app and maybe making it more generic and added to core might not be a bad idea. The idea is that the utility class shields you from having to catch things such as "OperationNotPermittedException" when you try to make posts (I'm also catching RevokedAuthorizationException on the calls there as well although I might let that be handled at a higher level.)

As an example you could call:

socialUtils.updateStatusOnProviders(String message, FacebookLink facebookLink)

(facebookLink could be null) The updateStatusOnProviders method will post the messages to the providers you have access to and of course catches OperationNotPermittedException since the user might have declined your app's permission to allow posting.

With the old auth system this doesn't seem to be as a concern since if you declined allowing publish (and offline access) then you would't have access to the application.

As a side note, do you know if there is a way to get a handle to whether they declined 'publish' permissions? In our existing application we were making an admin screen that allows users to select which kind of posts they will allow, but that whole screen shouldn't even be available if the user declined all publishing to facebook (since it won't matter anyway since no posts will go through.) I need a way to make a quick check to see if they've denied publishing.

[rickcr]

socialUtils.updateStatusOnProviders(String message, FacebookLink facebookLink)

(facebookLink could be null) The updateStatusOnProviders method will post the messages to the providers you have access to and of course catches OperationNotPermittedException since the user might have declined your app's permission to allow posting.

I forgot to mention there is another important thing that the updateStatusOnProviders method does. When it catches RevokedAuthorizationException it makes a call to remove the UserConnection (and also does some other internal cleanup of some facebook information we store.) This helps to also make the user appear now to be disconnected from facebook.

I'm wondering about doing something similar in the SocialConnect tag? Right now it just does a check
getConnectionRepository().findConnections(provider ).size() > 0

But this doesn't account for the fact that the user might have "remove your application" within Facebook while you are still working in your main site app in another tab or browser. In my opinion, if the user 'removes your app from facebook' you should make the appear disconnected from facebook within your app. (Of course this is only an issue when the user removes your app while your other site's session is still active so it's not super common but it certainly could occur.)