Email param for login view on Android SDK

[Raffaele Lagana]

Hi all, I am using Webex Android SDK 3.4.0.
I am calling OAuthWebViewAuthenticator to launch Web Auth Login but I want to Login view to have the user input the user's email address first.
In order for it to work, I have to put a bogus email (e.g. bogus123@bogus123.org) to OAuthWebViewAuthenticator for the email parameter. If I put empty string in the email param, it will return "Invalid Email" error and there's no Login View showing up.
Is there an email argument that I could use to make the Login View with the user's email address inquiry page to show up? Or do I have to always use this workaround hack by passing a bogus email?
Thank you

[Raffaele Lagana]

Hi, I'm not too sure I get your requirement, but the Android SDK KitchenSink App will ask for a user email and then use that in OAuthWebViewAuthenticator, along with client_id, client_secret, etc. , to login through web auth. Added a screenshot of debug here: https://www.evernote.com/shard/s375/sh/25ced3b2-e1df-3f2d-7cd0-a2e101a65edc/b2bd38cfc30caa25c4439550235eefd6 , showing the authenticator params , filled with the email just entered by the user. No need for a 'bogus email'.

Is this what you're looking for or are you looking for something else?

KitchenSink App on v3.4 is found here; https://github.com/webex/webex-android-sdk-example

[handitan]

Hi Raffaele,

Thank you for the response.

In the kitchensink, the user's email was asked through AlertDialog.

I don't want to use AlertDialog to ask user's email but instead to ask it via Webex Auth Login.
This is what I would like to show. I got this to show up like this when I input the bogus email.

Thanks Raffaele!

 

[Raffaele Lagana]

Ok understood, thanks. I think you can then use the  getAuthorizationUrl() method and then use that auth URL to open up the login page in your app. I have never tried this before so I don't know whether it will work, but you can give it a go maybe. If that doesn't work then the only other way is to do what you're doing already, with the bogus email hack (it's not really recommended to use in this way, but I guess if it suits your use case and works for you...). Note that all that's doing is making the request to the authorization URL, then seeing that the email is incorrect and therefore going back to the webex login page for the user to retry to login. 

[handitan]

Hi Raffaele,

Thank you for the suggestion.

I tried using the getAuthorizationUrl() like here below:

WebexConnector.getAuthenticator().getAuthorizationUrl(CompletionHandler {
    result ->
    if (result.error != null) {
        Log.d("Error", "Error Login ${result.error!!.errorMessage}")
    } else {
        val authURL = result.data
        mainScope.launch {
            binding.loginWebview.loadUrl(authURL!!)
            binding.loginWebview.visibility = View.GONE
        }
    }
}

While it's working that it will ask the user's email, it will launch a web browser client outside my app (in this case, it was Chrome) that will load authURL.

I am not sure why it did that eventhough I assign the URL to my app's WebView.

Am I doing something wrong?

By the way, the email hack that I said as a workaround to prompt to inquire user's email address. It didn't quite work as expected.
It did what it supposed to do which was prompting to inquire user's email address but somehow when I input a valid webex email address account and then password, it went back again to the user's email address inquiry page again (when I put the email account and then password again, it now works - meaning it won't go back to the inquiry page and I was able to make calls).
This happened all the time so email hack workaround is not a good option.

[Raffaele Lagana]

I'm not sure why it would open the browser instead of working inside the webView, I haven't tested this before I'm afraid. However, it does sound like the webViewClient wasn't set before calling loadUrl(), or at least the app isn't seeing it being set already and so defaults to the device's default browser instead. But I can't tell without some way of testing it and to be honest it doesn't sound like it's the SDK causing the issue, seems more an android thing that's causing it.