Closed virtualdxs closed 1 year ago
Yes we need to do something, logging in with the WebView seems to cause all kind of problems. Logging in with the browser was also not perfect, mainly because it only worked with Chrome or Firefox. So we will probably need some kind of option or automatic detection.
Interesting, do you know why it doesn't work with other browsers?
As a stopgap, I'd suggesting adding a menu option to the current webview that redirects to the browser.
They did not redirect back to Tusky
Looks like the official app uses Custom Tabs. Seems like a good solution - wide browser support, callback whenever a navigation event happens, and shares cookies etc. with the user's browser.
If you were using custom tabs, why did you need the browser to redirect back to you? From my understanding as long as they stay in the custom tab you should be able to capture the final redirect event, grab the token from it, and close the custom tab. (Apologies if I'm going off an incorrect assumption; I've never worked with this myself)
I think we can actually get navigation even which is nice
Implemented in #3165
Asking users to enter third-party credentials inside a webview is bad practice for a few reasons:
The first two were mentioned in the commit message for 4d8289b2. Providing the option to use a browser redirect would resolve some of these, but ideally the webview auth feature is removed entirely as it is considered bad practice for security and UX reasons.
It has also been mentioned that reverting this would help work around issues such as #2462.
Related: PR #2371 which introduced the change
Tusky Version: 19.0
Android Version: 12
Android Device: Galaxy S10
Mastodon instance (if applicable): N/A
[X] I searched or browsed the repo’s other issues to ensure this is not a duplicate.