SAP / gigya-android-sdk

SAP CDC (Gigya) android sdk for mobile
Apache License 2.0
19 stars 13 forks source link

Android Facebook Login - WebView no longer supported #28

Closed iNdieboyjeff closed 2 years ago

iNdieboyjeff commented 2 years ago

Facebook is no longer allowing login using WebView. If we use WebLoginActivity com.gigya.android.sdk.ui.WebLoginActivity then login with Facebook does not work. What can we do instead? Does this need to be resolved SDK side, or do we need to alter our implementation?

tal-mi commented 2 years ago

Facebook login requires implementing the Facebook SDK. If you do the SDK will not use the WebLoginActity. Please see: https://sap.github.io/gigya-android-sdk/sdk-core/#facebook

iNdieboyjeff commented 2 years ago

We already have all of that set up. It's still trying to use the WebLoginActivity

tal-mi commented 2 years ago

FacebookProvider class is responsible for selecting the correct social provider. Can you verify if it fails on the FacebookProvider.isAvailable call?

iNdieboyjeff commented 2 years ago

Do you want me to add this call to see what it does, or should there be something already in the logs?

2021-10-13 15:42:05.742 com.upst.hayu D/GigyaSDK: << Gigya *** login: with provider = Facebook >> 2021-10-13 15:42:05.886 com.upst.hayu D/GigyaSDK: << WebLoginActivity *** failedValidation: uri = https://socialize.eu1.gigya.com/socialize.login?client_id={removed}&redirect_uri=gigya%3A%2F%2Fgsapi%2Fcom.upst.hayu%2Flogin_result&response_type=token&x_forceAuthentication=false&x_provider=Facebook&x_sdk=5.1.4&x_secret_type=oauth1 >> 2021-10-13 15:42:05.886 com.upst.hayu D/GigyaSDK: << WebLoginActivity *** failedValidation: parsed parameters = {x_secret_type=oauth1, x_sdk=5.1.4, response_type=token, redirect_uri=gigya://gsapi/com.upst.hayu/login_result, nonce={removed}, client_id={removed}, x_forceAuthentication=false, x_provider=Facebook} >> 2021-10-13 15:42:06.074 com.upst.hayu D/GigyaSDK: << WebLoginActivity *** onPageFinished: https://socialize.eu1.gigya.com/socialize.login?client_id={removed}&nonce={removed}&redirect_uri=gigya%3A%2F%2Fgsapi%2Fcom.upst.hayu%2Flogin_result&response_type=token&x_forceAuthentication=false&x_provider=Facebook&x_sdk=5.1.4&x_secret_type=oauth1 >>

tal-mi commented 2 years ago

This call is internal to the SDK. You are able to debug it. If you are prompt to use the WebLoginActivity when trying to login with Facebook there is an issue with your implementation. See the Kotlin example app for details.

iNdieboyjeff commented 2 years ago

FacebookProvider.isAvailable returns true

At the moment I'm failing to see anything that looks wrong from the documentation

tal-mi commented 2 years ago

If it return true then you are using the FacebookProvider to login and not the WebLoginProvider. Can you debug your implementation to verify where it is failing? What version of the SDK are you using?

iNdieboyjeff commented 2 years ago

Gigya SDK 5.1.4 Facebook 12.0.0

This looks to be the code snippet where we start the flow:

gigya.login( provider, mutableMapOf<String, Any>("forceAuthentication" to forceAuthentication), object : GigyaLoginCallback<GigyaAccount>() {

forceAuthentication defaults to false provider is "Facebook"

iNdieboyjeff commented 2 years ago

Hum, changing the provider from "Facebook" to "facebook" uses the Chrome custom tabs :(

tal-mi commented 2 years ago

Use GigyaDefinitions.Providers.FACEBOOK if you want to use the correct enum. I will make sure that in the upcoming version uppercase/lowercase will be handled.

iNdieboyjeff commented 2 years ago

OK, gracias.

tal-mi commented 2 years ago

Cheers.

iNdieboyjeff commented 2 years ago

Out of interest is there a way to bypass the app login, and force the use of Chrome Custom Tabs? We're seeing an issue where login works without the FB app installed, and fails if the FB app is installed. We're checking config to make sure there isn't an error, but it would be good to have this option as a fallback if necessary

iNdieboyjeff commented 2 years ago

I worked the bit above out, but I confirmed the config in FB was wrong, and correcting it seems to have worked.

I guess this issue can be closed, unless you want to keep it open for the case-sensitive provider name part.

tal-mi commented 2 years ago

I will keep it open until the SDK will fix the case-sensitive provider name issue on the next release. Thanks you.