Is "Open this page in APP_NAME" an expected part of the auth flow?

[tomprogers]

I think I've finished integrating react-native-oauth into my app, but I'm seeing an unexpected prompt, "Open this page in APP_NAME?", in the authorization flow. I want to confirm whether this is supposed to occur.

I ask because, on a previous project, I used react-native-fbsdk for authorization, and there was no such prompt. I prefer to use oauth over a provider-specific solution, but this prompt seems sub-optimal.

I assume it's there because rno is passing the app's custom URL scheme to the auth provider, and the prompt is a standard part of the "open an app using a custom scheme" flow. But I also assumed that bypassing this prompt was one of the main attractions of using rno in the first place -- I built this same flow manually using react-native's Linking, RCTLinkingManager, and a tiny piece of similar wiring in AppDelegate. Now that I see it in operation, I'm not sure I understand what is the benefit of using this project in the first place, especially given how much additional setup was required to get it to work.

Am I missing something?

[NigelEarle]

@tomprogers Having a similar issue with a like plugin. Yeah, that prompt is annoying. Just wondering if you were still receiving the prompt when manually requesting with react-native's Linking and RCTLinkManager?

[tomprogers]

@NigelEarle Yes, the user experience is the same when the login flow is constructed manually. That's precisely why I filed this ticket: this package doesn't seem to substantially improve the login flow, from either the user's or developer's point of view.

Another unwanted consequence of performing login this way: when the user returns to their web browser after logging in, there is still a tab open for the login attempt. Pretty hacky. (This applies in both scenarios.)

Finally, and this is a major drawback, implementing authentication with this library requires hijacking the openURL method in AppDelegate.m. That means that using this library is mutually exclusive with support for any other deep-linking functionality. Implementing login manually avoids this problem, since all openURL calls are passed to the RCTLinkingManager, with the result that all deep-links are made available to the JS application. Admittedly, I'm not an iOS dev; there is likely a way to intelligently pass some calls to RCTLinkingManager and others to OAuthManager, but I'm just as likely to guess the lottery numbers as I am to spontaneously type that code.

The only way I can imagine improving this without native work would be to pass a redirect_uri that goes to a non-blank webpage. That page might include some kind of "you've logged in" text, as well as a button that reads "return to App", and which navigates to the app's custom URL scheme (perhaps with embedded auth data), e.g. fb12345://authorize?userId=<uuid>&sessionId=<sessionId>. This is still sub-optimal, for several reasons:

• if the user returns to the app by any means other than clicking the button, they will still not be authenticated
• the non-blank page will remain the active tab in the user's browser
• it's extra dev work (with essentially zero payoff)

[thecodecafe]

I'm having a problem please, can someone help me, whenever I log into my social media account, for some unknown reason, I can't login with a different account, every time i click on authorise, skips the consent screen and just logs the person in, is there a way to make such that the user can actually choose to login with a different social media or google account?

[maxcodes]

@thecodecafe you need to call manager.deauthorize(provider) first