Cleanup old IE/edge properties and implement unsupported browser error page

[skjnldsv]

The message gets narrowed a bit, we only show recommendations for mobile apps if you're on a mobile and for sektop browsers if you're on a desktop machine.

Desktop	Mobile

Ref #20855

[jancborchardt]

Looks good! :)

Do you think we should offer some additional info like which browser wpuld work? But then we also need to specify version numbers and it gets nerdy fast.

So I think it's fine like you did it! :)

[skjnldsv]

Do you think we should offer some additional info like which browser wpuld work? But then we also need to specify version numbers and it gets nerdy fast.

Yes, that was my question and why I asked for your advice :)
Maybe I can automatically build a list of supported browsers based on our configs 🤔

[skjnldsv]

So, I can build a check based on our browserlist, but it's not feature-aware. It's version-aware.

So some old FF versions might still be comptible with what we use, but using this method will redirect everyone that is not STRICTLY using one of the browser that is within our browserlist config into this "unsupported" page.

Anyone have a better idea? Maybe just show a warning and only redirect IE?
Or all dead browsers?

cc @juliushaertl @PVince81 @ChristophWurst @eneiluj @danxuliu

[AlvaroBrey]

I believe this change may have broken the login flow in Android (maybe iOS too). See the following video:

simplescreenrecorder-2022-10-21_15.59.17.mp4

As seen in the video, the webview just goes to the Dashboard instead of completing the login flow.

The Android app uses the Android system webview, as a reference.

[AlvaroBrey]

I believe this change may have broken the login flow in Android (maybe iOS too). See the following video:

As seen in the video, the webview just goes to the Dashboard instead of completing the login flow.

The Android app uses the Android system webview, as a reference.

Confirming, setting no_unsupporting_browser_warning to true lets the app login again. Will investigate if we can work around it in the app somehow.

[szaimen]

Confirming, setting no_unsupporting_browser_warning to true lets the app login again. Will investigate if we can work around it in the app somehow.

Another option wouold be adding the webflow user agent to the supported browsers... what is the user agent of such?

[AlvaroBrey]

After some testing, it looks like the unsupported browser page completely discards the initially loaded URL (in this case /login/flow/...) and redirects to /index.php. This will likely also break login for desktop if the default browser is outdated. Not sure about iOS, cc @marinofaggiana

Another option wouold be adding the webflow user agent to the supported browsers... what is the user agent of such?

This seems difficult. We have two different ways of creating user agents:

• For most cases we use a combination of properties from the Android device. This would look like this for my emulator, for example: Google sdk_gphone64_x86_64 (Android)
• For one specific case I don't quite understand, we use a pre-configured string, which is the same we use for API requests. This would look like: Mozilla/5.0 (Android) Nextcloud-android/3.23.0 Alpha1, BUT this is changed for branded builds IIRC. @tobiasKaminsky can hopefully shed some light here

[szaimen]

So what can we do here then? Improve the browser warning to redirect correctly?

[AlvaroBrey]

So what can we do here then? Improve the browser warning to redirect correctly?

That is needed, yes. Because even if we change the Android app to use the default browser instead of a Webview (and thus login flow v2), if the default browser is outdated the same problem will occur and users will not be able to login.

If the browser warning redirects to the original URL, the login should theoretically be possible afterwards. This is still a UX problem, as every Android user will likely see the warning every time they add an account, but at least they will be able to log in.

Another option is to disable the outdated warning for the /login/flow path and subpaths. Not sure if this is sensible or even possible.

[szaimen]

cc @skjnldsv on this then :)

[skjnldsv]

Confirming, setting no_unsupporting_browser_warning to true lets the app login again. Will investigate if we can work around it in the app somehow.

Another option wouold be adding the webflow user agent to the supported browsers... what is the user agent of such?

Are you setting something specific to the headers that we could use maybe?

the same problem will occur and users will not be able to login

Well, it's a warning, they can bypass it.
But it's defeating the purpose since we're loging in for the auth flow only.
I guess we could check if this is a login for app authentication or just a standard login which the user aims to use the web ui :)

In any case, this si why we merge such things early, to catch them! Nice found @AlvaroBrey 🎉

[skjnldsv]

• For most cases we use a combination of properties from the Android device. This would look like this for my emulator, for example: Google sdk_gphone64_x86_64 (Android)

We could add a bypass if the server as debug mode enabled too

• For one specific case I don't quite understand, we use a pre-configured string, which is the same we use for API requests. This would look like: Mozilla/5.0 (Android) Nextcloud-android/3.23.0 Alpha1, BUT this is changed for branded builds IIRC. @tobiasKaminsky can hopefully shed some light here

Yep, will need to know how the user agents behave for branded or not.
Otherwise I can just check for the Nextcloud word in the agent :)

[AlvaroBrey]

Well, it's a warning, they can bypass it.

Right now the user cannot bypass it, as the login flow URL (with its included tokens) is lost on the redirection.

I guess we could check if this is a login for app authentication or just a standard login which the user aims to use the web ui :)

This is why I suggested to bypass the check on /login/flow (and probably /login/v2/flow too, though the Android app does not use that one), since those are only meant for client authentication, not for web use AFAIK.

Are you setting something specific to the headers that we could use maybe?

Right now we're adding OCS-APIREQUEST=true to the first request only (/index.php/login/flow) but not to subsequent requests. If needed we can probably add more headers/try to add them on every request through the login process.

[skjnldsv]

Right now the user cannot bypass it, as the login flow URL (with its included tokens) is lost on the redirection.

Good call, then we should keep the redirect too :)

This is why I suggested to bypass the check on /login/flow (and probably /login/v2/flow too, though the Android app does not use that one), since those are only meant for client authentication, not for web use AFAIK.

I would like something a bit more standard than an url.
What if we have more URLs to cover ?

Right now we're adding OCS-APIREQUEST=true to the first request only (/index.php/login/flow) but not to subsequent requests. If needed we can probably add more headers/try to add them on every request through the login process.

Let's see what I can do :)

[skjnldsv]

This is why I suggested to bypass the check on /login/flow (and probably /login/v2/flow too, though the Android app does not use that one), since those are only meant for client authentication, not for web use AFAIK.

Maybe we could just load this on default template, and not login/maintenance/error/twofactor authentifications pages. Let's see what I can do here :)

[skjnldsv]

Fix in #34741