I am using oauth to authenticate my iPhone-app's users. They click the login button and Safari opens to display the password entry page. Afterwards they are redirected using a custom url scheme, e.g. myapp://somethingsomething, which opens the application again (sending Safari into the background).
Can I close the browser tap during that redirect? Or directly afterwards via Javascript?
I ask because if my user imports a bording pass to his Passbook, Safari opens and logs my user in again, since the tab was still there.
Ok fixed by doing a setTimeout() call in JS before issuing the redirect. In the setTimeout() another redirect is executed: To a harmless page.
Related
I am working on a use case where we want to have customers using an iOS app click on a 'Login Now' button which opens the login web page in a Safari Browser. Then the customers login into my website in a Safari browser, and are redirected back from the browser to the app.
We then want the customers to use the iOS app where upon clicking 'Transact' button it launches my website's transaction web page in SFSafariViewController. The transaction requires the customer to be logged in otherwise the customer is redirected to a login page.
Given the SFSafariViewController sessions are isolated to the app context, how do we get it to recognize the previously completed browser login session?
If my browser login puts a auth cookie / session cookie client side, is there anyway I can access it and make it available to SFSafariViewController such that it too recognizes the login session?
Note: I cannot use SFSafariViewController for logins due to a constraint that is not technical. So that is not an option.
I'm trying to implement an OAuth2 authorization code flow as part of my iOS app. I open the third party's OAuth2 login page in an SFSafariViewController, and the url that I pass to the Safari controller includes an https redirect uri that is a universal link. When the user hasn't done an OAuth2 login recently, the Safari controller displays the login page, the user presses the "log in" button, and then the redirect uri is followed as a universal link, bringing control back to the app, as expected. (The user doesn't enter credentials on the third party's page because Safari has already cached them.)
The problem is that, if I immediately try to repeat that process, the Safari controller does not appear to open the third party's login page, and, judging by the hostname displayed at the top of the screen, it tries to go straight to the redirect uri, which doesn't get treated as a universal link this time. The Safari controller just shows a 403 error because the uri doesn't correspond to any real webpage.
Does anyone know the cause of and/or the solution to this problem? I suspect that it may have to do with this behavior documented by Apple (https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html):
If you instantiate a SFSafariViewController, WKWebView, or UIWebView object to handle a universal link, iOS opens your website in Safari instead of opening your app. However, if the user taps a universal link from within an embedded SFSafariViewController, WKWebView, or UIWebView object, iOS opens your app.
That doesn't entirely explain why it works in the first case but not in the second, and it doesn't explain how I might prevent the second case from happening.
In my application I am using Google SignIn as Login to my application. I am not using cocoa pods I am directly using frameworks by pasting in my project. I am configuring GIDSignIn class like below.
//Allowing to sign in through browser
self.googleSignIn.allowsSignInWithBrowser = YES;
self.googleSignIn.allowsSignInWithWebView = NO;
//Initiate sign in
[self.googleSignIn signIn];
When i clicks on Google SignIn button it will redirect me to Safari (Not SFSafariViewController) and asks for google account credentials, everything is working fine. Once i allow to get the application to use my basic profile data, a pop up will appear in Safari for redirecting to my application and if I selects open it will go back to my application (Proper redirect URL is given) with the basic profile information. But problem is when I don't select an option of the alert view in safari for redirecting. It will close the alert view by itself and i will be in safari and no information will be redirected to my application. How to make the alertview wait for user response?
It will ask for user permission and once allow is pressed i will get the following screen.
And now if i don't select anything, the alert view dismisses and stays in Safari. Only if i press "Open" it will take me to MyApplication and gets me user basic profile application. Please help me how to stop alertview getting dismissed by itself.
I'm building a native application. The app has an embedded webview (UIWebView) pointing to a social website. To be able to use the website inside the app, user has to log in by the webview (username/password) and then he can continue use the site with saved cookies. Normally, the cookies expire after two days. After that, the user has to re-login by the webview.
Now suppose I know username and password of the user and I would like to make the user login automatically with this account when the cookie expires. How can I do that?
I tried to simulate the Login action when I click on Login button on web page, but not successful.By using "Inspect Element" of Chrome, I can see Chrome makes a "Post" request to an URL with some parameters. However, the request doesn't get successful (I use REST client for testing).
Finally I found out the solution. I didn't build requests anymore. I used javascript to set text fields and make "click" action on the webview. Done.
When running a mobile site in iOS full screen mode, using the "apple-mobile-web-app-capable" meta tag, I am using a combination of AJAX and synchronous page requests, including redirects, with success while the user is logged in.
However, when the user logs out and the session is destroyed, the iOS device leaves full screen mode and opens the login page in a Mobile Safari window.
Here is a common sequence of events:
User clicks button on Home Screen to launch mobile site in iOS full
screen mode
Server redirects user to login page for authentication (still in full screen)
User logs in, and is redirected back to mobile home (still in full screen)
User performs various actions, via GET and POST, some using AJAX and some not (still in full screen)
User hits logout button, which destroys session and redirects back to login page
Mobile Safari window opens to render login page this second time
I have tried 301, 302 and 303 redirects on logout success and nothing seems to change this behavior. It seems related to the user's session ending when running in full screen mode. I don't think this matters, but the security mechanism is implemented via Spring Security running on Tomcat.
Is there any way to prevent this behavior? I would prefer not to use a location.href client side redirect on logout.
You can cancel a links default behaviour by using jQuery's event delegation to assign a single, top-level event handler to all links on the page. When a click event is detected, we cancel the default behavior (which is to open in mobile Safari) and then manually change the window's location. This approach allows the page to be changed without breaking the iPhone standalone application experience.
http://www.bennadel.com/blog/2302-Preventing-Links-In-Standalone-iPhone-Applications-From-Opening-In-Mobile-Safari.htm
I was under the impression from running into this previously that any non-ajax/ javascript navigation would cause the app to jump into safari to serve the page