Do not limit FIDO/U2F usage based on user agent string #2956

New Issue

GiteaMirror · 2025-11-02T04:55:15-06:00

GiteaMirror commented

2025-11-02 04:55:15 -06:00

Originally created by @jorng on GitHub (Feb 21, 2019).

Gitea version (or commit ref): 1.7.2
Git version: 2.17.1
Operating system: Linux / Ubuntu 18.04
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

Description

After enabling FIDO / U2F for an account on my Gitea server, I am not able to use U2F on Safari, even with the Safari FIDO U2F extension installed and enabled.

If I change my user agent in the developer settings to include Chrome, it works as expected

If the extension is installed/enabled, it uses U2F
If the extension is not installed / disabled, it asks for TOTP

Gitea should not rely on user agent string at all to determine if U2F is available. Checking that window.u2f is non-null should be enough. (for example, it works fine with Github)

Originally created by @jorng on GitHub (Feb 21, 2019). - Gitea version (or commit ref): 1.7.2 - Git version: 2.17.1 - Operating system: Linux / Ubuntu 18.04 - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant ## Description After enabling FIDO / U2F for an account on my Gitea server, I am not able to use U2F on Safari, even with the [Safari FIDO U2F](https://github.com/Safari-FIDO-U2F/Safari-FIDO-U2F) extension installed and enabled. If I change my user agent in the developer settings to include Chrome, it works as expected - If the extension is installed/enabled, it uses U2F - If the extension is not installed / disabled, it asks for TOTP Gitea should not rely on user agent string at all to determine if U2F is available. Checking that `window.u2f` is non-null should be enough. (for example, it works fine with Github)

GiteaMirror added the issue/confirmed type/enhancement labels 2025-11-02 04:55:15 -06:00

GiteaMirror closed this issue

2025-11-02 04:55:16 -06:00

GiteaMirror commented

2025-11-02 04:55:16 -06:00

@stale[bot] commented on GitHub (Apr 22, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Apr 22, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:55:16 -06:00

@jorng commented on GitHub (Apr 22, 2019):

What? Don't close.

@jorng commented on GitHub (Apr 22, 2019): What? Don't close.

GiteaMirror commented

2025-11-02 04:55:17 -06:00

@e3b0c442 commented on GitHub (Jun 4, 2019):

Unfortunately the U2F support check is part of the vendored library, and looking at the latest version of that library, it still explicitly locks out Safari.

I see two ways this could be made to happen:

Scrap the legacy non-standardized U2F implementations entirely and go straight to standard WebAuthn+CTAP1. The consequences of this are that we end up dropping support for Firefox 47-59, Chrome 41-66, and Opera 42-53 (per caniuse.com). I don't think this will be a huge impact since Firefox 60 ESR has this and the Chromium browsers don't have extended support releases. Chrome<67 accounts for 2.18% of total global browser usage per caniuse.com. This is the forward looking approach, and would be a first step in adopting #6892.
Add a short-circuiting check for the window.u2f API before the call to u2fApi.ensureSupport(). This runs the risk of potentially causing issues because window.u2f is not standard. In fact, we cannot fully replace the vendored library call because Chrome itself doesn't provide window.u2f immediately. There is a U2F API library that can be retrieved from Google that implements window.u2f and could potentially replace the existing vendored library, but imho this is wasted effort given the deprecated status of unstandardized (from a web perspective) U2F implementations in favor of WebAuthn.

I'd be willing to take a stab at this if there is some agreement around one or the other option.

@e3b0c442 commented on GitHub (Jun 4, 2019): Unfortunately the U2F support check is part of the vendored library, and looking at the latest version of that library, it still explicitly locks out Safari. I see two ways this could be made to happen: 1) Scrap the legacy non-standardized U2F implementations entirely and go straight to standard WebAuthn+CTAP1. The consequences of this are that we end up dropping support for Firefox 47-59, Chrome 41-66, and Opera 42-53 (per caniuse.com). I don't think this will be a huge impact since Firefox 60 ESR has this and the Chromium browsers don't have extended support releases. Chrome<67 accounts for 2.18% of total global browser usage per caniuse.com. This is the forward looking approach, and would be a first step in adopting #6892. 2) Add a short-circuiting check for the `window.u2f` API before the call to `u2fApi.ensureSupport()`. This runs the risk of potentially causing issues because window.u2f is not standard. In fact, we cannot fully replace the vendored library call because Chrome itself doesn't provide `window.u2f` immediately. There is a U2F API library that can be retrieved from Google that implements `window.u2f` and could potentially replace the existing vendored library, but imho this is wasted effort given the deprecated status of unstandardized (from a web perspective) U2F implementations in favor of WebAuthn. I'd be willing to take a stab at this if there is some agreement around one or the other option.

GiteaMirror commented

2025-11-02 04:55:17 -06:00

@DerAndereAndi commented on GitHub (Nov 20, 2019):

As Safari 13.0 on macOS now has build in support for U2F and iOS 13.3 betas also including support, it would be great to make this work.

@DerAndereAndi commented on GitHub (Nov 20, 2019): As Safari 13.0 on macOS now has build in support for U2F and iOS 13.3 betas also including support, it would be great to make this work.

GiteaMirror commented

2025-11-02 04:55:17 -06:00

@e3b0c442 commented on GitHub (Dec 23, 2019):

My work on the WebAuthn conversion PR can be tracked here: #9451

@e3b0c442 commented on GitHub (Dec 23, 2019): My work on the WebAuthn conversion PR can be tracked here: #9451

GiteaMirror commented

2025-11-02 04:55:18 -06:00

@jorng commented on GitHub (Dec 23, 2019):

I am 💯 in favor of the migration to WebAuthn. I will close this and track that issue.

@jorng commented on GitHub (Dec 23, 2019): I am 💯 in favor of the migration to WebAuthn. I will close this and track that issue.

GiteaMirror referenced this issue

2025-11-02 12:16:16 -06:00