search

ThexXTURBOXx / flutter_web_auth_2

Flutter plugin for authenticating a user with a web service
https://pub.dev/packages/flutter_web_auth_2
MIT License
53 stars 54 forks source link

WebView Browser stays open after successful call to FlutterWebAuth2.authenticate Android #33

Closed BBQRIBS72 closed 1 year ago

BBQRIBS72 commented 1 year ago

Describe the bug

This is the same report as this bug on flutter_web_auth: https://github.com/LinusU/flutter_web_auth/issues/133 It also exists on this package, so I thought I would report it here

On android, if you successfully authenticate with FlutterWebAuth2.authenticate, when you are redirected back to the app, the browser tab used to authenticate you is still open in the app switcher. This tab is no longer needed so I think it should be closed?

To Reproduce

Steps to reproduce the behaviour:

  1. Successfully authenticate on an android device
  2. Go to app switcher
  3. See that browser tab is still open

Expected behaviour

I think that after a successful .authenticate, the browser tab should be closed as it is no longer needed

Screenshots

Device (please complete the following information!)

Additional context

I know that preferEphemeral: true makes the tab close, but it also closes the tab if the user goes to a different app during the login (e.g. to copy a password/mfa code) I think that either Ephemeral tabs should stay open during the login process, or normal tabs should close upon a successful .authenticate

Checklist

Any help is appreciated thanks.

ThexXTURBOXx commented 1 year ago

That's a tricky thing. Maybe it can be done, but I am unsure as of now. Looking through the documentation of FLAG_ACTIVITY_NO_HISTORY, it states that the newly launched activity (custom tab in our case) will not be kept on the history stack. In my application, that is exactly what I need since there is no MFA or anything. However, I can see that this might not be the desired behavior. Do you know of any activity flags (or combinations) that might solve the problem at hand already? If yes, I will try them out as soon as possible and publish a new release with those in place. If not, I will try to find some better combination myself at some point in the near future

ThexXTURBOXx commented 1 year ago

According to this issue: https://github.com/aboutyou/dart_packages/issues/162 Setting your app's launchMode to either singleTask or singleTop without the preferEphemeral config could also work correctly. However, I did not yet test that. I will try to see as soon as possible, if that is a proper solution.

Vikrech commented 1 year ago

Hi @ThexXTURBOXx, I wonder do you have any updates regarding this issue? One more thing I wanted to mention: could it be possible for the CallbackActivity to be launched with the FLAG_ACTIVITY_CLEAR_TOP? As far as I understand, the described solution is implemented in another package sign_in_with_apple SignInWithApplePlugin.kt Another solution is described here How to close CustomTab

ThexXTURBOXx commented 1 year ago

I already tested most of the flags, but no matter which combination I chose, there will always be some user who will complain. Hence, I did not look further into this issue. If you can confirm that your flag does work well and should fit the majority of use cases, I can adjust the package after some more testing.

Vikrech commented 1 year ago

I appreciate your efforts and agree that probably each case would require a unique approach to handle it, but I am still wondering whether we could at least improve the handling of Android Custom Tabs, taking into account the mentioned examples.

BuzzBumbleBee commented 1 year ago

I have ran into this issue recently, would it be possible to supply a "hideBrowserHistory" flag into the authentication flow and keep the default as it is now ?

I think in most cases the end user seeing an extra app spawned in the recent app menu would be a little confusing

ThexXTURBOXx commented 1 year ago

I am a bit reluctant to add another flag to the current authenticate function. I was thinking about maybe abstracting everything into several objects, one for each platform. Then you can specify each setting for each platform independently. While this would make code within this package much cleaner, everyone else would need to specify more arguments, hence, it is not optimal.

I need to think a bit more about all of this

ThexXTURBOXx commented 1 year ago

The intent flags can now be adjusted using the intentFlags option in 3.0.0-alpha.1