I'm making an app that is running on iOS 6.1.3 and Facebook SDK 3.5. When the app launches, the user is asked to authenticate with Facebook. I ask for read permissions here and have an access token after a successful connection.
However, one of my features involves showing a UIWebView popup inside of my app that is on the Facebook mobile website. Ideally, I'd like to be able to have the user load this UIWebView and be logged into Facebook automatically on the mobile web version without having to reenter their credentials. Is this possible? If so, how could I go about doing this?
I guess a simpler way of describing what I'm trying to do is:
1) User logs into MyApp and grants me permissions with an access token.
2) User opens Safari. Right now, going to m.facebook.com will prompt user to login once more.
Q) How can I get it to where the user is automatically logged in on m.facebook.com using the access token that I have?
Thanks!
Related
We have an ios app that uses native Facebook login just fine.
Then we also have a website (app is basically an optimized client for it) where people can login via Facebook too. When they open our website in mobile safari, they are directed to Facebook pages to authenticate there and it works, but.. it is still far from native and users have to retype credentials they often have in ios already.
So could it be possible to to somehow launch system fb authentication for just a web page (maybe using some clever URL schema?) and get granted token back to web?
Difficult way
As described here http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps you could find URL scheme to trigger the native iOS app for app authorization:
fbauth://authorize?redirect_uri=[redirect_uri]&client_id=[client_id]&response_type=token
But if you call that link it's not possible to have a redirection. You could try to hack that redirection but maybe you could not find a way out.
A secure way to solve that problem is to use a SSO token to authenticate user on your App when he logs in, and next on Safari take a redirection, with a custom url to your APP, that do as bridge to FB App via Token stored in your APP. After FB authentication you can directly redirect user back to your landing page in Safari. As said by #Lego it's an alternative way to direct authenticate that could be made by going deep to custom URL used by FB.
No, it is not yet possible to directly authenticate the user via the native Facebook App, but it's possible to authenticate the user using a custom URL scheme which opens your native iOS app which then handles the authentication flow:
The user authenticates natively with your iOS App. You then store the user login (not password) in your app (i.e. using NSUserDefaults).
Then the user opens your web page in Mobile Safari. You redirect the user via a custom url scheme to your app (i.e. using myapp://authenticate). Apple documentation on implementing custom URL schemes: click
Now, if you have an active FB session in your iOS app, you can either directly redirect the user back to your landing page in Mobile Safari, passing the access token via url get parameter or you first re-authenticate the user, displaying a login view with the user name pre-filled, which you have stored in your iOS app before (step 1) and then redirect the user to your landing page, again all depending on session state and your security needs.
For opening face book app you can use Custom URL scheme. But i am not sure if u can authenticate user from it. In case if you could also then it will be confined up to the fb account which is already configured on that device app .so better try to use face book api or something
I don't get your question exactly but i think as per your question you want to create fb app Login in safari or in your custom web view.
is this perfect ?
as per my knowledge web view is different thing and native app is different thing.
if you are Login in web view then no need to check anything token or other thing because it will give you Logout thing there.
but if you are Login in your application then "developer.facebook.com" will definitely help you.
and yes, you will do most of the thing in your app as native facebook app do.
Hope it help....
So I've searched for this topic a lot and may be over complicating things but would love some clarity on it. So here's the issue.
I have a web app that uses Facebook Graph (FB Login, friends invite, sharing through FB, etc). We've just built an iOS app for the website and now want to implement all the above FB actions on the iOS app as well. I looked up the Facebook documentation and have tried using that to getting just the Facebook login to work for a user that's already registered on our website (and has their Facebook account connected as well) but it doesn't seem to work.
Use case - A user registers on the web app and connects their FB account with us. They then download the iOS app and want to use FB login to login to the iOS app or share objects on their timeline. A vice versa case should also apply.
Question - What should be the workflow between the ios App, web Server and Facebook for the use case above? Basically, how is the token and the secret passed so all three know we're talking about the same user and same FB account?
Any links or advice would be highly appreciated! Thanks!
In the case when a facebook authed webapp user first starts the native app, you won't know who they are. So they need to be prompted with a "login with facebook" button. When they hit that button, the facebook-ios-sdk will figure out who the logged in user is and then check if that user has already granted your application access. If the web app and the native app both point to the same facebook app, then the facebook-ios-sdk will simply store the authed access token, and you'll have access to everything your web app does on the native app.
The key here is that your web app and native app must point to the same facebook app (ie. same app id in developers.facebook.com). If it didn't, then the native app user would be re-prompted to grant permissions when they click the "login with facebook" button. Additionally, it's important that the user is logged into the same facebook account on the web app (which is based on cookies in the browser) and on the phone itself. The facebook-ios-sdk uses a couple of different ways to look for the active facebook account on the phone. It tries the iOS 5+ system facebook account, inter-app calls to facebook's own native app, the browser cookie for the web view instance running in your app, or bounce you out to safari and use the browser cookie in safari. Which ever one comes back first saying they have an active facebook account needs to have found the same facebook account as the one on the web app. In most cases, they will match up because most users only have a single facebook account and are logged in everywhere with the same account, but they certainly can be different. In the off chance that the web app facebook user is not the same as the native app active facebook user as detected by facebook-ios-sdk, then the "login with facebook" button will simply prompt the native app active facebook user to log in and grant permissions.
Once the access token has been granted to the native app, you can send it back to the server, find the associated facebook user id, and now the web app user and the native app user can be linked to be the same person operating both apps. Additionally, any graph api calls you want to make on the server can be made on behalf of the user using the up-to-date access token you just got from the native app. Any sharing/posting/api calls made directly in the native app through the facebook-ios-sdk will be done as this user and will be handled by the sdk (ie. you won't need to worry about it... it should just work seamlessly and integrate all posts to their timeline just like the web app's graph apis can).
In the case where you have a facebook authed native app user going to the web app, you also won't know (on the first request) who this user is. You can present them with a facebook js sdk login and, again, once the same facebook user logs in, you can associate this current web app user as the one who was on the native app earlier.
Specifically addressing your question, you really have no way of knowing who a migrating user is on either the web app or the native app when they first come to the app. That's where the "login with facebook" comes in. Assuming the user is logged into the same account on the browser as well as on their phone (as determined by the facebook-ios-sdk), then the process of logging into your app is seamless. They won't be prompted to grant permissions a second time (unless your permissions set is different between the web app and the native app) and you'll be given the user's access token immediately. The role of the server is to reconcile the two users by using the granted access token. With the access token, the server can make a simple call to the graph api and get the user's facebook user id. Using that facebook user id, you'll be able to match up the "true" identities of the users on your apps (ie. you now know that the web app user and the native app user are one and the same). Once you know who the user is, you'll be able to provide a personalized experience to that user, based on his identity, regardless of whether he's using your web app or your native app.
Hope this helps. Happy to answer more questions that you may have.
Right now I'm using a Facebook SDK to share posts from my application. The problem is that this sdk pops up a webview inside my app and asks the user to log in. There has to be a better way.
Can I send the share information to the facebook app on the users device (If they have it installed)? Or at least leverage the facebook app to check credentials? If people have to sign in to share, they probably won't do it..
The latest Facebook SDK 3.5 includes a native share dialog. If you follow the authentication workflow according do the documentation and the phone is on iOS 6.0 you should not get a UIWebView during authentication, instead you will get a UIAlertView.
Facebook login process would use WebView only in a few cases. Some of them are:
1) You are asking it to do so explicitly, by using - (void)openWithBehavior:(FBSessionLoginBehavior)behavior completionHandler:(FBSessionStateHandler)handler; which, I think, is not your case.
2) If there is no Facebook app installed on the device, FB SDK falls back to using WebView login window.
3) Probably, this is your case. If you are requesting publish permissions on the first attempt to open FB session, FB SDK will also fall back to old login flow envolving WebView. In the new login flow, FB session is supposed to be open with read permissions first (in that case, FB will use fast app switching or native iOS FB login):
+ (BOOL)openActiveSessionWithReadPermissions:(NSArray*)readPermissions allowLoginUI:(BOOL)allowLoginUI completionHandler:(FBSessionStateHandler)handler;
Then, you should ask additional publish permissions from the user:
- (void)requestNewPublishPermissions:(NSArray*)writePermissions defaultAudience:(FBSessionDefaultAudience)defaultAudience completionHandler:(FBSessionRequestPermissionResultHandler)handler;
That way, user will not need to log in (if he is logged in FB app already), but there will be inconvenience of double switching from your app to FB (though it works rather fast lately).
I was looking for a cleaner way to get publish permissions with FB Single Sign On on the first call, but unfortunately didn't find anything working yet.
Using Facebook SSO (Single Sign on), after the system prompts the user for permissions to work with their Facebook account, it directs the user back to the app that SSO was being run in. How specifically does FB SSO accomplish this? (How does it know which app to reopen after the permissions are granted?)
We are building a SDK that interacts with Facebook, and it is not clear how the facebook app figures out which app to return to.
When you add the Facebook SDK, one of the steps is to register a URL scheme for your app with your API key.
When you authorize the app in Facebook it tries to open the URL (usually formatted like fbXXXXXXXXXXX) and since your app is set to handle this URL scheme so the app is opened.
And here's a list of other apps you can communicate using handleOpenURL:
http://handleopenurl.com/
This is the link for Facebook's iOS tutorial.
https://developers.facebook.com/docs/mobile/ios/build/
Can any one please explain what does this mean :
"If the device is running in a version of iOS that supports multitasking, but it doesn't have the Facebook app of version 3.2.3 or greater installed, the SDK will open the authorization dialog in Safari. After the user grants or revokes the authorization, Safari redirects back to the calling app. Similar to the Facebook app based authorization, this allows multiple apps to share the same Facebook user access_token through the Safari cookie."
Most of the posts say,like this one:
https://stackoverflow.com/questions/531712/reading-cookies-using-xcode-on-the-iphone
because of the sandbox environment of iOS one cannot access safari cookies, then how is this possible ?
and if its possible, How can multiple apps use the same access token. According to me different apps might have different permissions.
Your app does not read the cookie in that case. I think it just opens up a URL in Safari. Then some Facebook code which is run in Safari checks whether a valid Facebook session exists and then calls a callback function in your app. Of course all the access tokens and with them the different permissions for all the different apps on the device are saved separately in the facebook session so that the apps do not share the permissions. Only the user is saved in the session (most likely there is only one user who uses the mobile device), so that he doesn't have to login over and over again. He instead just clicks on 'login' or 'no, I'm not So and So'.