When viewing applications that exist in the AppStore, I observe that there are two ways to log in via Facebook:

  1. When you click on "Login via FB" you get to the site via a web form (UIWebView) and enter your email / password there and come back.
  2. When you click on "Login via FB", the application requests access to the FB account of the phone itself, and you do not need to go to any site.

It would be interesting to know how the second method is done. I will add that I know about the first method and have done it for a long time, and now, with the obvious convenience of the second method, I just want to save time searching for a solution on how to implement it.

So, how to implement authorization through FB by local means, without going to the FB website?

Thank.

    4 answers 4

    Most likely, point 2 is done through the Account Framework - it allows you to work with accounts of some services through the settings of the device, not the application, for Facebook this option is relevant only with 6.0 because I did not use it (but used the same from Twitter, there are some problems) the first way is through third-party (for ayoshi) sdk facebook , however, his latest versions seem to also use option 2, depending on the axis version, I will not lie, I don’t remember, I haven’t come across this topic for the last six months

      Join the guys.

      Everything is done through the Facebook iOS SDK, and this SDK itself looks at what to do and how to behave:

      If the user has entered the data into the system account, then he will be used, otherwise the SDK will try to open the Facebook App, if the application is not installed, it will open Safari.

      In order to be able to return to the application after logging in via the Safari or Facebook App, then in Info.plist you need to add support for the URL scheme, such as fb $ app_id.

      In principle, everything is rather trivial and repeatedly painted, but I would like to share a little different experience, namely how to connect the iOS app with the server backend and what can be stepped on.

      This is not the only right decision, but in my opinion it is quite acceptable and quite “secular”.

      In the mobile application you need to get the user data:

      [FBSession openActiveSessionWithReadPermissions:@[@"email"] allowLoginUI:YES completionHandler:^(FBSession *session, FBSessionState status, NSError *error) { if (session.isOpen && _successCallback) { _successCallback(session.accessTokenData.accessToken); } else if (_failureCallback) { _failureCallback([[TDError alloc] initWithError:error]); } }];

      pull out the auth_token and send it to the server, after which the server application should knock somewhere like facebook.com/api/me with this token, and if valid data has arrived, then we have everything to register a new user, or find the old one and log in him.

      PS at the moment when the user logs out of the mobile application, you also need to drop the session in the FB SDK, because it caches the session, and if the user has changed something on the web on the FB (for example, the application has dropped access), the open session will still return on the device and token, but the fact that the token is invalid will be found out only on the server)

      Cleaning an FB session:

       [FBSession.activeSession closeAndClearTokenInformation]; [FBSession.activeSession close]; [FBSession setActiveSession:nil];

      ZY Please forgive me if I wrote something wrong and misled :)

        This is done via the Facebook SDK. Authorization via FB-account on the phone is made if the official Facebook application is installed. That is, when you click on the authorization button in your application, the Facebook application opens and asks for permission to give your application access to the information on Facebook and then authorizes. When you re-authorize, the Facebook application will no longer open, but will only take data from Keychain, which facebook sdk saved.

        • Thanks for the answer. Rather, you only clarify my question, telling in more detail how the authorization is performed by the second method. The fact that this is done via the Facebook SDK is also very obvious (for the first one, too, it is used, by the way). I am interested in, for example, a specific reference to the documentation and (preferably) a meaningful example with several lines of code. Can you please make your answer more detailed? - Stanislav Pankevich
        • If you need through the Facebook SDK - then I think you know how to do it. Here is my example: gist.github.com/leoru/6866165 And also, you can pull through Accounts.framework gist.github.com/leoru/6866278 - Kirill Kunst
        • Yeah, thanks for the examples. It looks sober. I will try. - Stanislav Pankevich
        • I tried Accounts. Framework - I used almost the same code that you have in the gist. Completion block: it works and I receive both facebookAccount.credential.oauthToken and facebookAccount.username, which is equal to my e-mail, that is, everything seems to work. But it remains to me a little incomprehensible where this data comes from? After all, they are taken from the phone? If so, why don't I see any warning at all (pop-up window) that the application is requesting access to the account somewhere? - Stanislav Pankevich
        • In Settings there is a Facebook section. There are entered data for a Facebook account in order to integrate it with the system. Data is stored in Keychain. - Kirill Kunst

        Use Cocoapods.

        pod 'SimpleAuth / Facebook'

        https://cocoapods.org/pods/SimpleAuth

        If you need to use the account from the phone, use the "facebook" configuration, if through the UIWebView use the "facebook-web"

        Do not forget to specify the redirect in the code and in the settings of the application on developer.facebook.com

         SimpleAuth.configuration[@"facebook"] = @{@"app_id":@"123456789", SimpleAuthRedirectURIKey : @"http://com.server.redirecturl" }; [SimpleAuth authorize:@"facebook" completion:^(id responseObject, NSError *error) { NSLog(@"\nResponse: %@\nError:%@", responseObject, error); }];