Controlling Facebook oauth login experience - facebook

I'm building a Facebbook application that uses the Facebook oauth login. I see some existing sites that have a single-page experience that combines application authorization with asking for permissions. But when I build my application, I'm seeing a two-page authorization dialog: application authorization and basic permissions come on the first screen, the second screen asks for additional permissions.
I'd like to get to a single-screen dialog, similar to the one shown on this page:
http://developers.facebook.com/docs/authentication/
but that's not what I'm seeing, even though I use the URL from that page, and even though I use the same Oauth redirect URL that I see in another app that shows the dialog as I want it.
Anyone have any ideas on how to have the older app authentication dialog?

Short answer: that's the way it works now. Facebook changed things. Go figure.
Facebook has changed the way the auth dialog works. It seems like they are trying to discourage use of publish_stream and other permissions and make it easier for users to grant the open graph publish_actions permission.
From the recent blog post:
Added functionality to the publish_actions permission
When we turn on the new auth dialog, we will also add some of the most frequently requested permissions to publish_actions to make the permission more robust and improve conversion. publish_actions now includes the ability to post status updates on the authenticated user’s own timeline, tag photos, publish photos and videos. Other actions such as posting to a friend's timeline still require the use of publish_stream.
Adding these common permissions to publish_actions eliminates the need for extended permissions and the second screen of the auth dialog for the majority of timeline apps built with the Open Graph. This makes the auth process clearer to new users and should improve conversion rates. Additionally, approved Open Graph actions are no longer required for the publish_actions permission. Apps should only ask for the stream_publish permission if they absolutely need functionality not present in publish_actions.
See this blog post for full details and references: https://developers.facebook.com/blog/post/2012/03/02/enhanced-auth-dialog-and-updates-to-permissions/
Subscribing to the Facebook devleoper blog and monitoring the platform roadmap at https://developers.facebook.com/roadmap/ are good ways to see these changes coming.

Related

pages_messaging permission required when subscribing for Instagram messages (Facebook app)

I'm creating an app that will allow me to manage my Instagram account, following the guide from here
Now I'm at the App Review stage and I have a conundrum:
theoretically I should not need the pages_messaging permission (the documentation is not mentioning this as required)
that being said, when I make my call to register a callback for Instagram messages `POST /v11.0/{page-id}/subscribed_apps?fields=messages&access_token={access_token} the call will fail with WWW-Authenticate: OAuth "Facebook Platform" "insufficient_scope" "(#200) To subscribe to the messages field, one of these permissions is needed: pages_messaging" (this call is the same they are making in the documentation)
so I've added the pages_messaging permission in my review
now I'm unable to pass review as they keep telling me that I don't need the pages_messaging permission for my use case (managing Instagram messages) - "We determined that your app's use case for the requested permission or feature is invalid or is not needed to support its core functionality."
Hmm.... what am I missing? Any guidance that you can provide?
After further attempts:
we could not find a technical way for not needing the pages_messaging permission
Facebook would not approve this permission for our Instagram app - we got no more details than "invalid or is not needed"
we resorted to actually increasing the scope of our app to also cover Facebook page messages, we re-recorded our demos to showcase interaction with a FB page.
with the new approach we managed to pass the pages_messaging approval process
It feels like we're doing something wrong - we shouldn't have had to support Facebook messages and go through the lengthy process of changing our app just to showcase FB page interaction. Not if we only wanted Instagram support.
Alas, as of October 2021, this is how we moved things along.
Hopefully something will change in the future to make things more clear & transparent in future.

Facebook Graph API 2.0 Permissions Request Denied

I'm working on a notification web-app that has a Post-to-Facebook feature. Until the (Graph) API v2.0, it worked great. A user would authenticate with their Facebook account, put their token into our app, and we'd use that to make posts to their wall/page for them when a new notification was sent.
We have applied for the permissions we need to use on Facebook's new API (publish_pages, publish_actions, manage_pages). We received a notice that our application was rejected, so we re-worded the same application for permissions to try to clarify what we use the permissions for, resubmitted it, but have been rejected again.
An app that does almost exactly the same thing we hope to do was granted these permissions (we know, because we both work with- and compete with- that app). Until we found out that that app can still publish posts to Facebook, we believed that all requests to repost/automatically post on users' behalfs were being denied because of a Facebook policy change.
We can't figure out who to contact or where to appeal the denial of these permissions. This probably isn't the right forum (since this isn't specifically a technical question about the API), but I can't see where to take this issue next.
Did you have a look at the Login Review FAQs:
https://developers.facebook.com/docs/facebook-login/review/faqs
or otherwise refer to
https://www.facebook.com/groups/fbdevelopers

Using an app access token, why do i need publish_stream permission instead of just publish_actions

I'm using an app access token to write to a facebook user's wall (using the facebook graph toolkit in asp.net). i've found that the process works fine if i have publish_stream permission but fails if i only have publish_actions. i would prefer to work only with publish_actions to avoid the second screen permission request.
this issue seems to go against the fb docs which state "Moving forward, we recommend that apps only ask for publish_actions, as this permission encompasses the other two and we want to simplify the model." (https://developers.facebook.com/docs/concepts/login/permissions-login-dialog/)
I'm wondering if anyone else has experienced and overcome this issue.
You need to check out this.
It says-
publish_actions will now include basic publish_stream permissions (including posting on a user's timeline, posting photos/videos, commenting on and liking content), which will appear on the first Auth Dialog screen. With this change, apps that were previously granted publish_stream do not need to request publish_actions.
as you said, BUT-
If you need specific capabilities like posting to a friend's timeline or to groups, you will still need to request publish_stream, which appears on a second screen where users can also opt out.

Automatically activate users' timeline on login

I am using the JavaScript SDK to login in the user on my website via Facebook, requiring the publish_actions permission. If I am getting it right, Open Graph stories published by using publish_actions are only visible for users who have their timeline enabled.
Is it possible to automatically activate the users' timeline after he logged in to my application and gave me the publish_actions permissions. I've seen authentication dialogs around the web where applications request the publish_actions permission and after granting the permission and logging in, the user automatically has the new timeline enabled.
I already searched a lot, but unfortunately I could not find anything in the developer documentation about how to do that.
How do I accomplish this?
If you request the publish_actions permission from the user and you have the action approved by Facebook, the message you talk about will appear in the login popup. Facebook automatically adds this message in as the features are only available with the new timeline profile. There isn't a setting you need to configure to add this message in.
What you describe is the intent of modifying user settings, and you can't do that.

Facebook app without asking permission on load

How do I make an app that doesn't ask for permission when you load it?
Or is that impossible? The only thing the application does is post to the user's wall, but can't I authenticate for that after they load the application?
You can, not sure why others are so positive that it is not possible.
On your server side you can check through facebook api if current user granted you required permission. If not, pass some flag to your fbml where you can display permission prompt link:
Would you like to <fb:prompt-permission perms="publish_stream">allow us</fb:prompt-permission> to post on your wall?
You are not obligated to require users to authorize your app either (but you need authorization before checking for granted permissions or retreiving any user information), you can still allow users to use your app. In fact allowing users to use an app without authorization is even encouraged by facebook recommendations. For optional authorization you can put such fbml on your page:
<fb:if-is-app-user>
<fb:else><a href="http://www.facebook.com/login.php?api_key=...&v=1.0>Would you like to authorize this app?</fb:else>
</fb:if-is-app-user>
If you want to post to their wall via a prompt instead of requiring prior authorization, you should use the connect library. Then you can use some javascript to open the dialog.
In fact, another SO question gives you exactly what you need.
Or is that impossible. The only thing
the application is going to do is post
to the users wall, but can't I
authenticate them for that after they
load the application?
To publish content to users' walls, you need to have the steam_publish permission from them first.