I'm using
(void)openWithBehavior:(FBSessionLoginBehavior)behavior completionHandler:(FBSessionStateHandler)handler
to open my session, which works fine. After open, I then get my read permissions with:
(void)requestNewReadPermissions:(NSArray*)readPermissions completionHandler:(FBSessionRequestPermissionResultHandler)handler
This works fine, but for users signing in through Mobile Safari (or likely the Facebook iOS app, haven't tested), users get jumped back and forth twice (tap login in my app, jump to Mobile Safari, log in there, jump back to my app, jump back to Mobile Safari, approve permissions, jump back to my app.
Returning users - those who have signed out of my app (and token removed), also get a double-jump - each time Mobile Safari tells the user they've already approved the app.
I'm using openWithBehavior because I prioritize the native iOS login using FBSessionLoginBehaviorUseSystemAccountIfPresent. I don't see a version of this combined with an initial permissions request (such as openActiveSessionWithReadPermissions...).
I was hoping that, for subsequent logins, permissions would already be known via session.permissions but in testing that value is null until requestNewReadPermissions is called.
Is it possible to remove the double-jump from either or both scenarios (first user login, subsequent user login) yet still achieve the same permissions?
You can "init" your session with read permissions by calling the initWithPermissions: method. Then call openWithBehavior:completionHandler: which will do only 1 open call with the permissions you've already set.
Related
I'm writing an app that uses https://github.com/AzureAD/azure-activedirectory-library-for-cordova to authenticate with Azure AD. It opens an embedded browser within the app that shows our Azure AD page and the user enters their credentials. Because we require multi factor authentication the system then sends them a push notification which if tapped* opens the Microsoft Authenticator app.
Using Safari's debug tools I can see that before switching over to Authenticator it is making repeated to requests https://login.microsoftonline.com/common/SAS/EndAuth, each time getting a response including "The authentication has not been completed yet, please try again." However once the Authenticator app is running (and my app is in the background) the requests pause and after approval is done I return to my app the last request that was made turns red (in the Safari inspector).
I believe I need to mark my app as being able to run in the background, but since the page that loses the connection is from AzureAD perhaps there is a setting or fix there that can restart the auth requests when the app returns to the front.
*If the user pulls down on the notification they are offered two buttons "approve" and "deny". My app is obscured by the notification but no other app has really taken focus. In this case when Approve is pressed the final request to ....EndAuth is successful, the app knows it is authenticated and everything proceeds.
I'm working on two iOS applications that share the same keychain tokens which they receive when the user logs-in in either of the apps by entering his username and password in a web view. The tokens saved saved in the keychain, are time limited for a few hours/days - they are being refreshed when the user uses the app and makes request/enters items which are being opened in a browser.
Up until the release of iOS 11, the web view in the app was a SFSafariViewController instance and it was very convenient because it shared the cookies between the apps and once a user logged-in in a browser in one app, he would automatically be logged-in in the other app, thus achieving an SSO experience.
In iOS 11, the behavior of SFSafariViewController changed, and it no longer shares the cookies between different SFSafariViewController instances in my two apps. Instead, Apple wants us to use SFAuthenticationSession to achieve the same behavior.
In my app, I have a table of about 50 rows, almost all of them open a different URL in SFSafariViewController. So now, in iOS 11, I need to create a new instance of SFAuthenticationSession every time (the URL cannot be changed once the instance was created), and in order to actually show the web view, I need to invoke the start() method on this instance. However, this method can only be invoked once on the same instance (otherwise it will return 'false' and do nothing), and every time it is being invoked, it pops the notification that "myapp" wants to use "mydomain.com" to sign in.
So it means that my users see this alert message on every tap on a row in the table.
Is there a way to make my app show the consent alert message only once, e.g. on the first time or something? I want my users to have an SSO experience in my two apps, that's why I used SFSafariViewController in the first place, but I don't want them to see this annoying alert on every tap they make in the app.
There is currently no way of having the alert message only show once using SFAuthenticationSession, we are experiencing the same issue on our apps.
I along with many others have filed a bug regarding this to Apple, asking them to show it only once like you suggested. The end of this GitHub thread discusses the alert.
I have integrated Google-Signin into an iOS Application and it works well as far as signing in or signing up is concerned.
The only problem is that, I dont want the user to be logged into Google on iOS Safari after I have used Google-Signin.
I have verified that, before I log into my app, I am signed out of google in iOS Safari. Then I go to my app and I use Google-Signin to log into my app, once that is done I then go back to iOS Safari and refresh the google page and all of a sudden it shows me signed in with the same account that I used to log in to the app.
How do i just use Google-Signin to simply log into the app and stay logged out of iOS safari?
I've researched the topic and it seems the only way to perform logout is to use SFSafariViewController to open provider's logout page
For Google this is https://accounts.google.com/logout
This way requires some additional UX changes, because this action will open Safari window for a second and user should not be confused.
Try to use GIDSignIn it will open safariviewcontroller inside the app.
You can change which content from your Google Account syncs with the Apple apps on your device. You can also remove your Google Account from your Apple apps at any time, which stops syncing.
To change what syncs or remove your Google Account:
On your iPhone or iPad, open the Settings app.
Select Mail, Contacts, Calendars or Safari
Choose the account you'd like to edit or remove.
Make the changes you want.
To change what content syncs: Next to the content you want to sync, turn on the switch. Turn it off for content you don't want to sync.
To remove your account: Select Delete Account.
I'm trying to setup my app to publish a simple post to a user's Facebook feed (image url, link, description). They don't need to use Facebook for anything else so the first time they click "Share" it needs to authorize the app, and the publish permissions.
If they have their credentials stored in the device as of iOS 6 they simply get two alert boxes and it's done with. But if they don't, or have an older version, it switches out to Safari for login. My problem is that it is then switching the user back to my app, then immediately back again to Safari to accept the publish permission. It's very jarring and unprofessional.
What I would like is for the page in Safari to change after the login to the permissions page so they can accept it, and THEN switch back to my app. I know this can be done because the popular Mixology app does exactly this behavior. Unfortunately Facebook keeps changing their SDK and all the information I find online is outdated.
I wrote up a solution here: FacebookSDK presents login UI twice to avoid the double switch.
Basically, you can use openActiveSessionWithPublishPermissions: to do what you want. However, you have to handle the special case where the user has signed in to Facebook from the device settings, which requires requests for read and publish permissions into two separate calls.
Apps that allow users to log in over a 3rd party authentication provider (e.g. Facebook, Google, Twoitter,...) should open a browser window to let the user authenticate against the provider. That means, at some point, an app is backgrounded and the user interacts with a browser window. Just before the browser opens, it's a recommended pratctice to inform the user about what will happen (see e.g. Getting Started with OAuth 2.0 - O'Reilly), let's say an alert window with something like "you will leave now the XYZ app and a browser window will open where you can enter your credentials safely".
My question: How can that be done if I use the facebook SDK for ios? Looking at the SDK, there seem to be no notifications and no designated states that would allow me to detect that the sdk is about to background my app and about to opening either Safari or the Facebook app.
Use a simple alert that explains what will happen when pressing the button (or however you choose to do it). And when the user has pressed the OK on the alert sign them in.
However I'm quite certain that in Facebook terms of service you have to have some sort of Facebook trademark before interacting with facebook and it seems like standard practice to mention facebook in some way on a button and then log-in the user without mentioning it, since it plays on the user expectation.
Especially when using iOS 6.0 and Facebook SDK 3.1 for iOS, then Facebooks SDK takes care of most of that in it's own.