Inconsistent behaviour compared to iOS Auth0 when pressing back button about auth0.android HOT 27 CLOSED

The indicator is not because the popup is slow to come up, it's because it takes some time to be notified with the token after the web view was closed. Our Product Owner does not want the user to see the login screen for 1 or 2 seconds until we manage to get the token as the user might click again and restart the process. That's why we have some activity indicator right after the popup has been created.

But if we have no way to know that the user is coming back apart from onResume callback of the activity we are in a difficult situation.

Thanks for your support :)

from auth0.android.

I don't see the utility on knowing when the user has canceled the auth. Normally, you'd call the WebAuthProvider logic from a Login screen. If you cancel the auth or close the browser, you just get back to the Login screen of your app to try to login again or leave the app at all.

from auth0.android.

Well there's always going to be a slight delay between the activity of the webauth disappearing and the callback bubbling up to frameworks like ReactNative for example. In our specific case we are showing some activity indicator while the login is popping up until we receive the callback. We could revert to the login screen if we had some way to know that the user cancelled but we have none. The user is then coming back to a screen with some activity indicator which sucks. Any suggestion welcome.

from auth0.android.

Why are you showing that indicator in the first place? Calling the WebAuth should be fast, depending on the browser installed and the device specs of course. That shouldn't vary among frameworks. But on my (native) tests I haven't noticed any important delays. Users already know that the WebAuth is appearing soon because they have performed a manual action like a click on some "login now" button, so they would wait for something to happen soon.. On this case, a Toast is less intrusive and it can be dismissed automatically..

If you want to stick with that "indicator" I'd try with a postDelayed Runnable triggered from the activity's OnResume method, which will take the user back to the Login screen, but can be canceled from the callback if something arrives any sooner. I know it's not the best and I wouldn't use it because it looks like a hack, and you'll have to tune the delay too... But maybe it saves you some time while we discuss internally if this is required or not.

from auth0.android.

I'm thinking out loud, but wouldn't the "cancel callback" produce the same delay? We're not making any extra requests when we receive the tokens.. so this issue you're mentioning may occur as well on the "cancel flow". So in that case, you'll be still showing the "auth on progress" popup until you receive either the tokens or the cancel call.

from auth0.android.

Right but that's way more acceptable to show an activity indicator for 1 sec until you get the callback than still showing the login screen with an actionable button don't you think ?

Anyway I understand if you consider that this is off topic. I was just raising the issue because the iOS Auth0 auth is sending a callback for that scenario.

from auth0.android.

I'll keep this open as a reminder and evaluate it with my team. Cheers

from auth0.android.

Hello, we are also in need of a cancel callback. Has there been any plans to make the Android behaviour match the iOS behaviour?

from auth0.android.

@corporate-fun not in the short time. But sure it could be added in a future release if more people request it 👍.

from auth0.android.

Another developer expressed interest in this functionality through private support (internal ticket #34768).

from auth0.android.

Upvote. :)

Same issue as @jmoutte: I'm having to set a timeout (via postDelayed) in onResume to remove the loading indicator because none of the callback methods were called. It wouldn't be necessary if either: a) any callback was called (like iOS); or b) the success callback was instant.

from auth0.android.

@jmoutte @lbalmaceda this doesn't look like it would be too complicated to implement if you use the existing onFailure callbacks.

Remove the if check here
Add callback.onFailure here and here

And you should pretty much have a working callback for when the auth was cancelled.
Not the prettiest solution but it looks like it's the easiest to implement without much work and without breaking anything (that I'm aware of).

from auth0.android.

Any updates here? Really need a cancelled callback to update the UI accordingly if the users cancels the login.

from auth0.android.

@korre It's not in our backlog for the next month 👍 I haven't went through it thoroughly but any solution like the one proposed above seems like a change in a behavior that some customers might find breaking.

from auth0.android.

Ok @lbalmaceda. It's really a shame that it doesn't exist already. Since it is available when using native lock screens in apps. The use case is for example when we are toggling "switches" etc. in the UI causing login screen to show but if the users is cancelling or failing login we want to toggle them back of course.

from auth0.android.

I don't see how a switch could launch authentication, but in any case I'd not change the switch state until a valid pair of tokens is received from the callback, and I guess that if the switch is turned off I'd remove the tokens if I have anything saved.

We're not making any extra requests when we receive the tokens..

I know I said this ☝️ , but the code flow requires us to exchange a value that the server gives us for the tokens. So yes, after the browser app is closed on a successful authentication, another request is made to the server to obtain the tokens. That one could be causing the issues mentioned in this thread if you're depending on that response to update your UI.

But then even if I add a call to callback.onFailure that request alone would still be running on the background, with the browser already closed and your app still waiting for the tokens, so there's no way to go around it and you'll still be on a similar situation. An option in that case would be showing some progress bar/dialog until a valid/invalid response is received in the callback, but that doesn't look like good a UX either IMHO. Do you consider it helpful for your particular case?

from auth0.android.

i would love to see this behaviour as well.

from auth0.android.

Just saw this open ticket as I created #184.

Upvote.

from auth0.android.

+1 when the auth O call is async followed by another internal API calls, hiding the loader becomes problematic.

from auth0.android.

+1 I would like to have it as well

from auth0.android.

+1
In my case I'm calling from Flutter. I need to handle both the iOS and Android.

If user cancels the login screen, I get different results:

• iOS returns a failure, which I catch and reset my view appropriately
• Android returns nothing, and I'm stuck without a way to reset my view

In my opinion, this issue deserves a label with a higher priority.

from auth0.android.

+1
I totally agree with @jjerome00
I think this scenario, when user close the WebAuth view and fall back to the activity, should be covered with a callback.
Yes there is some delay calling WebAuth, we need to show some indicator and remove it in the case user close the WebAuth, but it's not only about it I think it's a leak in the lifecycle calling the WebAuth.

Do you know if is there any work in progress with this?

from auth0.android.

@kronosboy There hasn't been any progress so far.

I think it's a leak in the lifecycle calling the WebAuth.

Remember when using code that after the browser is closed there's an extra request to the auth0 servers to exchange the received code for tokens. This is IMO the only reason why adding the feature requested in this issue is necessary. Given that this is the default authentication flow, I'll make sure we have this in our backlog and re-prioritize it.

from auth0.android.

+1, my app is launching the login mechanism automatically. If the webauth is closed, I would like to be notified so that I can handle it accordingly (by reopening the webauth).

from auth0.android.

Any news about this improvement? Almost 2 years passed..
This leads to use dirty workarounds when cancelling webview authentication proccess

from auth0.android.

Still on the backlog

from auth0.android.

To all, feel free to try PR #240 and make any suggestions in there.

from auth0.android.