mirror of
https://github.com/OAuthSwift/OAuthSwift.git
synced 2026-04-27 13:15:55 +03:00
[GH-ISSUE #404] Handler not called if user presses systems "back" button when using SafariURLHandler. #256
Labels
No labels
bug
cocoapod
duplicate
enhancement
feature-request
help wanted
help wanted
invalid
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/OAuthSwift#256
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @noobs2ninjas on GitHub (Aug 31, 2017).
Original GitHub issue: https://github.com/OAuthSwift/OAuthSwift/issues/404
Description:
When using SafariURLHandler, the user has the ability to hit the "back" button to return to the application which doesn't trigger the handler. I don't remember when this functionality was added to iOS. Could just affect iOS 10.
Having done some research the view controllers viewDidAppear doesn't get called after the application returns. So the only place that could handle it would be in the app delegate in this function below.
func applicationDidBecomeActive(_ application: UIApplication){ }I checked documentation and the example and didn't see anything about what to put here to handle it.
The main problem here goes a bit beyond just the handler not getting called.
Lets say for a minute that you have a button on your application that creates a OAuth2Swift and then calls oauth.authorize(). If the user hits that system back button to return to your app the first handler isn't completed. Then if the user hits the authorize button again and completes the transaction both handlers will get a completion at once. This can stack indefinitely until the user completes the authorization. Which means if you are saving the result to a database in the "success" block, this may be called and executed multiple times. Even if you set the OAuth2Swift to a variable in order to remove the previous one, ALL success/fail closure will still get called.
I personally will be moving over to using an internal web view. However, I think something should be made to handle completion/fail in the event someone elses application is using the external Safari browser.
OAuth Provider (Twitter, Github, ..):
All
OAuth Version:
OS (Please fill the version) :
Installation method:
Library version:
Xcode version:
@phimage commented on GitHub (Aug 31, 2017):
How did you achieve to have a back button in status bar?

With iphone 7 plus simulator I have a Done button
When I click
safariViewControllerDidFinishfunction is called inSafariURLHandlerand remove all the observers (by calling clearObservers), so no issue@phimage commented on GitHub (Aug 31, 2017):
I see I click on the button at the bottom
Then I click back. I have the safari open with Done button
I click Done and return to the previous controller, the observers are removed...
@noobs2ninjas commented on GitHub (Aug 31, 2017):
This occurs is when you use the external Safari Browser...as in iOS's safari app. In the demo select the option "Open with external web browser".
The issue is that currently there is no way to tell if the user hits this button. So you cant clear observers from anyway that I can tell. Guess one could create a singleton class that the app delegates applicationDidBecomeActive() function could call which would store the handler. However, being that this is an option that the OAuthSwift framework provides, a more permanent solution is probably required.
@phimage commented on GitHub (Aug 31, 2017):
So nothing about SafariUrlHandler
"Open with external web browser" is an external browser(ie .safari), not recommended at all
for ios app in appstore I think it`s forbidden
@noobs2ninjas commented on GitHub (Sep 2, 2017):
@phimage I know. Just thought Id make @everyone aware of the issue since it is something that can be found as an option in the demo.
@noobs2ninjas commented on GitHub (Sep 2, 2017):
I did it this way because I have a million things to do and that was the fastest way to implement. Moving over to internal safariViewController as you suggested.
@phimage commented on GitHub (Sep 2, 2017):
see readme
If you think readme it's not clear, you can propose PR