Error trying to load auth webview activity with application context

[elkhoudiry]

Basically this is my setup, i'm using ViewModel which has a login feature that that calls login() function from Auth0Repository interface using WebAuthProvider also using a dagger hilt provider for providing app level dependencies for Auth0, AuthenticationAPIClient, etc

Everything is working alright and clean , i can call login() function with no paramaters and dagger hilt injects the dependencies for me, but passing context to login WebAuthProvider is a challenge When i'm leaving the context to dagger hilt so it can inject an ApplicationContext i get this error

Calling startActivity() from outside of an Activity  context requires the  
FLAG_ACTIVITY_NEW_TASK flag. Is this really what you want?

https://github.com/auth0/Auth0.Android/blob/9bbee00e09933c7c9b741ffe0fdb3a29385cce2a/auth0/src/main/java/com/auth0/android/provider/AuthenticationActivity.kt#L101

can this flag FLAG_ACTIVITY_NEW_TASK be added to auth0 sdk ?

PS: Injecting @ActivityContext won't work cuz ViewModel outlives activity, which will make the application doesn't combile

[lbalmaceda]

This has already been reported here: https://github.com/auth0/Auth0.Android/issues/479

The WebAuthProvider takes an Activity context rather than an Application context. But changing the signature today poses a breaking change. If you want to use the class in that use case, you will have to pass an activity.

[elkhoudiry]

thank you for your response, is it possible to be allowed to pass custom defined intent or just custom FLAGS as arguments to overcome this application context problem, and customize the WebActivity a little ?

[lbalmaceda]

@elkhoudiry If your intention is to pass FLAG_ACTIVITY_NEW_TASK, that has proven to be problematic for the web auth scenario; as the custom tabs would be opened in a separate task defeating the purpose of their improved UX. See my comment in the issue linked in my previous comment.

Moreover, we are considering for future implementation of the WebAuthProvider to receive a ComponentActivity as context instead and use the Activity Results API to register that for an internal result. That change wouldn't be possible if we open the API to receive a custom intent.

[elkhoudiry]

Yes, implementing Activity Results api will make the sdk tied tightly to the activity, well i will try to work around it, thank you

[elkhoudiry]

One last thing before closing the issue Firefox browser is giving me unusual behavior

when chrome is default browser and the WebAuthProvider get valid credentials it takes me back to the app,

but when firefox is default browser, it redirect to a white screen that have "Not found" in it, and i have to click on the firefox tab "3 vertical dots" menu and choose from it "Open in app" and then choose my application, so it takes me back inside my application and then the application continues normally

[thsaraiva]

TL;DR: change the scheme of the Callback URL from https:// to a custom scheme your_company_name://.

Hey @elkhoudiry , @lbalmaceda , I've reported this "not found" behaviour here:

https://community.auth0.com/t/google-sign-in-integration-in-android-app-simply-stopped-working/70975

but found a solution in stack overflow this morning:

https://stackoverflow.com/questions/2665796/android-handle-oauth-callback-using-intent-filter

It would be interesting to understand exactly what is happening and why it used to work with https and it doesn't anymore.

[elkhoudiry]

Thank you for sharing that, i will try it asap,

But I'd like to understand why chrome custom tabs is working correctly and firefox tabs behaving this way

[lbalmaceda]

@elkhoudiry We've also experienced that 404 page in the past with other browsers than Chrome (not just firefox) and still don't understand the conditions for that to happen. We did see that using a custom scheme instead of "https" for the callback URL helped in fixing that behavior, but the caveat is that it removes the ability to use "Android App Links" (domain verification, etc).

Another issue like this was reported here: https://github.com/auth0/Auth0.Android/issues/488

[elkhoudiry]

I see, i will try to workaround that too,

Well while exploring around, i found that there is auth0.lock that can be used to authenticate users but from a native activity that can be visually and language customized

Can i use that Lock to authenticate users and replace WebAuthProvider without losing any functionality ?

[lbalmaceda]

Embedded authentication, like the one provided via Lock when you type your username/password, is discouraged nowadays. Users would prefer to type their credentials in a trusted application, as their browser apps for example, instead of in your apps' form (Lock). Anyway, social authentication via that library is delegated to the WebAuthProvider class of this one; so you will still be using that.

You can read about the differences in this article that while it focused on web apps, it can also be applied to mobile. And about web auth vs embedded, you might also find interesting this blog post https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html.

[elkhoudiry]

Got it, thank you for your clarification and with this i will close the issue