github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

U2F not working with Gitea 1.10.3 #4775

New Issue
Closed
opened 2025-11-02 06:02:32 -06:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-02 06:02:32 -06:00
Owner
Copy Link

Originally created by @0x6d61726b on GitHub (Feb 2, 2020).

  • Gitea version (or commit ref):
    Gitea version 1.10.3 built with GNU Make 4.1, go1.13.6 : bindata, sqlite, sqlite_unlock_notify
  • Git version:
    git version 2.20.1
  • Operating system:
    Linux test 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist: (level debug)
    2020/02/02 16:35:00 ...ce/gracehttp/http.go:142:Serve() [I] Serving [::]:3000 with pid 1234
    2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'lower_name', 'name', 'full_name', 'email', 'keep_email_private', 'email_notifications_preference', 'passwd', 'passwd_hash_algo', 'must_change_password', 'login_type', 'login_source', 'login_name', 'type', 'location', 'website', 'rands', 'salt', 'language', 'description', 'created_unix', 'updated_unix', 'last_login_unix', 'last_repo_visibility', 'max_repo_creation', 'is_active', 'is_admin', 'allow_git_hook', 'allow_import_local', 'allow_create_organization', 'prohibit_login', 'avatar', 'avatar_email', 'use_custom_avatar', 'num_followers', 'num_following', 'num_stars', 'num_repos', 'num_teams', 'num_members', 'visibility', 'repo_admin_change_team_access', 'diff_view_style', 'theme' FROM 'user' WHERE 'id'=? LIMIT 1 []interface {}{1} - took: 102.363µs
    2020/02/02 16:35:05 ...s/context/context.go:330:func1() [D] Session ID: 1bbce208aa01b2cd
    2020/02/02 16:35:05 ...s/context/context.go:331:func1() [D] CSRF Token: 0-lR0jNh25DGmwImY3X7u9qOYoA6MTU4MDY1MTIwMTc1MTY2MjU2OQ
    2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT count(*) FROM 'notification' WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1} - took: 49.808µs
    2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'name', 'user_id', 'raw', 'counter', 'created_unix', 'updated_unix' FROM 'u2f_registration' WHERE (user_id = ?) []interface {}{1} - took: 29.496µs

Description

I tried to add a yubikey security key/token to gitea and got the error message "Could not read your security key.". I used both Firefox 72.0.2 and Chrome 79.0.3945.130 but was unable to add the security key.

  • Gitea is directly accessed via https (not yet through a reverse proxy, but port-forwarding from 443->3000).
  • Both browers work fine on the YubiKey with WebAuthn and webauthn.io demo page.
  • I cannot reproduce this problem at https://try.gitea.io (adding security key works there).

I already searched documentation and issues, but was not yet able to find a solution.
What can I do for further debugging? Unfortunately, the log does not output any error message.

Screenshots

gitea-u2f

Originally created by @0x6d61726b on GitHub (Feb 2, 2020). - Gitea version (or commit ref): Gitea version 1.10.3 built with GNU Make 4.1, go1.13.6 : bindata, sqlite, sqlite_unlock_notify - Git version: git version 2.20.1 - Operating system: Linux test 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [X] No - [ ] Not relevant - Log gist: (level debug) `2020/02/02 16:35:00 ...ce/gracehttp/http.go:142:Serve() [I] Serving [::]:3000 with pid 1234` `2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'lower_name', 'name', 'full_name', 'email', 'keep_email_private', 'email_notifications_preference', 'passwd', 'passwd_hash_algo', 'must_change_password', 'login_type', 'login_source', 'login_name', 'type', 'location', 'website', 'rands', 'salt', 'language', 'description', 'created_unix', 'updated_unix', 'last_login_unix', 'last_repo_visibility', 'max_repo_creation', 'is_active', 'is_admin', 'allow_git_hook', 'allow_import_local', 'allow_create_organization', 'prohibit_login', 'avatar', 'avatar_email', 'use_custom_avatar', 'num_followers', 'num_following', 'num_stars', 'num_repos', 'num_teams', 'num_members', 'visibility', 'repo_admin_change_team_access', 'diff_view_style', 'theme' FROM 'user' WHERE 'id'=? LIMIT 1 []interface {}{1} - took: 102.363µs` `2020/02/02 16:35:05 ...s/context/context.go:330:func1() [D] Session ID: 1bbce208aa01b2cd` `2020/02/02 16:35:05 ...s/context/context.go:331:func1() [D] CSRF Token: 0-lR0jNh25DGmwImY3X7u9qOYoA6MTU4MDY1MTIwMTc1MTY2MjU2OQ` `2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT count(*) FROM 'notification' WHERE (user_id = ?) AND (status = ?) []interface {}{1, 0x1} - took: 49.808µs` `2020/02/02 16:35:05 .../xorm/session_raw.go:76:queryRows() [I] [SQL] SELECT 'id', 'name', 'user_id', 'raw', 'counter', 'created_unix', 'updated_unix' FROM 'u2f_registration' WHERE (user_id = ?) []interface {}{1} - took: 29.496µs` ## Description I tried to add a yubikey security key/token to gitea and got the error message "Could not read your security key.". I used both Firefox 72.0.2 and Chrome 79.0.3945.130 but was unable to add the security key. - Gitea is directly accessed via https (not yet through a reverse proxy, but port-forwarding from 443->3000). - Both browers work fine on the [YubiKey with WebAuthn](https://demo.yubico.com/webauthn-technical/registration) and [webauthn.io](https://webauthn.io/) demo page. - I cannot reproduce this problem at https://try.gitea.io (adding security key works there). I already searched documentation and issues, but was not yet able to find a solution. What can I do for further debugging? Unfortunately, the log does not output any error message. ## Screenshots ![gitea-u2f](https://user-images.githubusercontent.com/25281946/73610988-88986880-45dd-11ea-9f33-98ac5b1b06d5.png)
GiteaMirror added the type/question label 2025-11-02 06:02:32 -06:00
GiteaMirror commented 2025-11-02 06:02:33 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 3, 2020):

Are you visiting a localhost? That will not work with U2F.

@lunny commented on GitHub (Feb 3, 2020): Are you visiting a localhost? That will not work with U2F.
GiteaMirror commented 2025-11-02 06:02:33 -06:00
Author
Owner
Copy Link

@0x6d61726b commented on GitHub (Feb 3, 2020):

Hi @lunny,

thanks for your hint. I use a dyndns service to resolv to the public IP address of my ISP (to which also the SSL certificate was issued to by letsencrypt) which today resolves to 93.220.xxx.xxx. However gitea runs on the virtual machine with the IP address 192.168.1.6. Traffic is forwarded from the ISP router to the virtual machine with NAT.

Here is the tcpdump file that was captured during the "add security key" procedure:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:09:55.741008 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [P.], seq 4280327037:4280327716, ack 1741328768, win 1025, length 679
08:09:55.741041 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [.], ack 679, win 716, length 0
08:09:55.745807 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [P.], seq 1:336, ack 679, win 716, length 335
08:09:55.790815 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [.], ack 336, win 1024, length 0
08:09:59.951388 IP 93.220.xxx.xxx.49933 > 192.168.1.6.3000: Flags [.], seq 3126526437:3126526438, ack 1943948608, win 1025, length 1
08:09:59.951428 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49933: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.963152 IP 93.220.xxx.xxx.49937 > 192.168.1.6.3000: Flags [.], seq 3555876064:3555876065, ack 1335527715, win 1024, length 1
08:09:59.963225 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49937: Flags [.], ack 1, win 266, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.963170 IP 93.220.xxx.xxx.49936 > 192.168.1.6.3000: Flags [.], seq 2695486276:2695486277, ack 2730822703, win 1025, length 1
08:09:59.963243 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49936: Flags [.], ack 1, win 247, options [nop,nop,sack 1 {0:1}], length 0
08:09:59.982799 IP 93.220.xxx.xxx.49935 > 192.168.1.6.3000: Flags [.], seq 3937215492:3937215493, ack 2161389577, win 1025, length 1
08:09:59.982863 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49935: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0
08:10:00.077591 IP 93.220.xxx.xxx.49934 > 192.168.1.6.3000: Flags [.], seq 2568963727:2568963728, ack 1579807665, win 1023, length 1
08:10:00.077637 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49934: Flags [.], ack 1, win 265, options [nop,nop,sack 1 {0:1}], length 0
14 packets captured
14 packets received by filter
0 packets dropped by kernel

Do you think this is the problem?

@0x6d61726b commented on GitHub (Feb 3, 2020): Hi @lunny, thanks for your hint. I use a dyndns service to resolv to the public IP address of my ISP (to which also the SSL certificate was issued to by letsencrypt) which today resolves to 93.220.xxx.xxx. However gitea runs on the virtual machine with the IP address 192.168.1.6. Traffic is forwarded from the ISP router to the virtual machine with NAT. Here is the tcpdump file that was captured during the "add security key" procedure: `tcpdump: verbose output suppressed, use -v or -vv for full protocol decode` `listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes` `08:09:55.741008 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [P.], seq 4280327037:4280327716, ack 1741328768, win 1025, length 679` `08:09:55.741041 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [.], ack 679, win 716, length 0` `08:09:55.745807 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49866: Flags [P.], seq 1:336, ack 679, win 716, length 335` `08:09:55.790815 IP 93.220.xxx.xxx.49866 > 192.168.1.6.3000: Flags [.], ack 336, win 1024, length 0` `08:09:59.951388 IP 93.220.xxx.xxx.49933 > 192.168.1.6.3000: Flags [.], seq 3126526437:3126526438, ack 1943948608, win 1025, length 1` `08:09:59.951428 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49933: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0` `08:09:59.963152 IP 93.220.xxx.xxx.49937 > 192.168.1.6.3000: Flags [.], seq 3555876064:3555876065, ack 1335527715, win 1024, length 1` `08:09:59.963225 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49937: Flags [.], ack 1, win 266, options [nop,nop,sack 1 {0:1}], length 0` `08:09:59.963170 IP 93.220.xxx.xxx.49936 > 192.168.1.6.3000: Flags [.], seq 2695486276:2695486277, ack 2730822703, win 1025, length 1` `08:09:59.963243 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49936: Flags [.], ack 1, win 247, options [nop,nop,sack 1 {0:1}], length 0` `08:09:59.982799 IP 93.220.xxx.xxx.49935 > 192.168.1.6.3000: Flags [.], seq 3937215492:3937215493, ack 2161389577, win 1025, length 1` `08:09:59.982863 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49935: Flags [.], ack 1, win 246, options [nop,nop,sack 1 {0:1}], length 0` `08:10:00.077591 IP 93.220.xxx.xxx.49934 > 192.168.1.6.3000: Flags [.], seq 2568963727:2568963728, ack 1579807665, win 1023, length 1` `08:10:00.077637 IP 192.168.1.6.3000 > 93.220.xxx.xxx.49934: Flags [.], ack 1, win 265, options [nop,nop,sack 1 {0:1}], length 0` `14 packets captured` `14 packets received by filter` `0 packets dropped by kernel` Do you think this is the problem?
GiteaMirror commented 2025-11-02 06:02:34 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 3, 2020):

And could you have any js error on your chrome console?

@lunny commented on GitHub (Feb 3, 2020): And could you have any js error on your chrome console?
GiteaMirror commented 2025-11-02 06:02:34 -06:00
Author
Owner
Copy Link

@0x6d61726b commented on GitHub (Feb 3, 2020):

I did not find any errors neither in Chrome nor in Firefox. I did update to the pre-Release (v1.11.0-rc2) just to see if that eliminates the issue, but that wasn't the case. This is also the reason why the error message looks different now. In addition I again tried using registration/login on webauthn.io which worked fine.

gitea-chrome-console
gitea-chrome-network
gitea-webauthn

Can I do anything else to track-down this issue?
The log file still does not contain any further hints.

@0x6d61726b commented on GitHub (Feb 3, 2020): I did not find any errors neither in Chrome nor in Firefox. I did update to the pre-Release (v1.11.0-rc2) just to see if that eliminates the issue, but that wasn't the case. This is also the reason why the error message looks different now. In addition I again tried using registration/login on [webauthn.io](https://webauthn.io/) which worked fine. ![gitea-chrome-console](https://user-images.githubusercontent.com/25281946/73674104-15abf200-46b0-11ea-87d1-43a08bffcd9c.png) ![gitea-chrome-network](https://user-images.githubusercontent.com/25281946/73674112-18a6e280-46b0-11ea-9623-e8f3699cec01.png) ![gitea-webauthn](https://user-images.githubusercontent.com/25281946/73674120-1b093c80-46b0-11ea-9818-959a04880431.png) Can I do anything else to track-down this issue? The log file still does not contain any further hints.
GiteaMirror commented 2025-11-02 06:02:34 -06:00
Author
Owner
Copy Link

@0x6d61726b commented on GitHub (Feb 4, 2020):

I did further debugging with Firefox console today (which I am more familiar with) and found out that I had an incorrect ROOT_URL entry in app.ini telling the wrong protocol and no port.

Incorrect setting:

DOMAIN           = <subdomainnamae>.dynv6.net
HTTP_PORT        = 3000
PROTOCOL         = https
ROOT_URL         = http://<subdomainnamae>.dynv6.net

After I changed the ROOT_URL the authentication worked as expected:

ROOT_URL         = https://<subdomainnamae>.dynv6.net:3000

gitea-firefox-console

Maybe additional information can be added to the manual?

Thanks again for your support.

@0x6d61726b commented on GitHub (Feb 4, 2020): I did further debugging with Firefox console today (which I am more familiar with) and found out that I had an incorrect `ROOT_URL` entry in app.ini telling the wrong protocol and no port. Incorrect setting: ``` DOMAIN = <subdomainnamae>.dynv6.net HTTP_PORT = 3000 PROTOCOL = https ROOT_URL = http://<subdomainnamae>.dynv6.net ``` After I changed the ROOT_URL the authentication worked as expected: ``` ROOT_URL = https://<subdomainnamae>.dynv6.net:3000 ``` ![gitea-firefox-console](https://user-images.githubusercontent.com/25281946/73775299-e962a500-4785-11ea-9eea-ddde1961af2c.png) Maybe additional information can be added to the manual? Thanks again for your support.
GiteaMirror commented 2025-11-02 06:02:34 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 5, 2020):

I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value.

The docs state:

ROOT_URL: %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/: Overwrite the automatically generated public URL. This is useful if the internal and the external URL don’t match (e.g. in Docker).

You're not the only person I've seen do this but I still don't understand where it is coming from.

@zeripath commented on GitHub (Feb 5, 2020): I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value. The docs state: ``` ROOT_URL: %(PROTOCOL)s://%(DOMAIN)s:%(HTTP_PORT)s/: Overwrite the automatically generated public URL. This is useful if the internal and the external URL don’t match (e.g. in Docker). ``` You're not the only person I've seen do this but I still don't understand where it is coming from.
GiteaMirror commented 2025-11-02 06:02:35 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Feb 5, 2020):

Anyway as this was a configuration issue I'm going to close this.

@zeripath commented on GitHub (Feb 5, 2020): Anyway as this was a configuration issue I'm going to close this.
GiteaMirror commented 2025-11-02 06:02:35 -06:00
Author
Owner
Copy Link

@0x6d61726b commented on GitHub (Feb 5, 2020):

I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value.
...
You're not the only person I've seen do this but I still don't understand where it is coming from.

What I was doing was running the installation wizard on http://\<ip-adress\>:3000/install which created the app.ini file that contains contains the following values in the server section (with SSH disabled):

[server]
SSH_DOMAIN       = localhost
DOMAIN           = localhost
HTTP_PORT        = 3000
ROOT_URL         = http://<fqdn>:3000/
DISABLE_SSH      = true
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET   = <removed>
OFFLINE_MODE     = false

The ROOT_URL field value is set by the installation wizard and seems to get the value from the Gitea Base URL * (required) field.

gitea-install

So maybe thats an explanation why I am not the only person with that kind of non-recommended configuration?

@0x6d61726b commented on GitHub (Feb 5, 2020): > I don't understand why you've even set the ROOT_URL there. There's no need to set it - you've just set it to the default value. > ... > You're not the only person I've seen do this but I still don't understand where it is coming from. What I was doing was running the installation wizard on `http://\<ip-adress\>:3000/install` which created the app.ini file that contains contains the following values in the server section (with SSH disabled): ``` [server] SSH_DOMAIN = localhost DOMAIN = localhost HTTP_PORT = 3000 ROOT_URL = http://<fqdn>:3000/ DISABLE_SSH = true LFS_START_SERVER = true LFS_CONTENT_PATH = /var/lib/gitea/data/lfs LFS_JWT_SECRET = <removed> OFFLINE_MODE = false ``` The `ROOT_URL` field value is set by the installation wizard and seems to get the value from the `Gitea Base URL *` (required) field. ![gitea-install](https://user-images.githubusercontent.com/25281946/73863205-0360be00-4840-11ea-8b1a-b28aa165d748.png) So maybe thats an explanation why I am not the only person with that kind of non-recommended configuration?
GiteaMirror commented 2025-11-02 06:02:35 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 7, 2020):

@0x6d61726b That's a good workaround. Maybe we should add a hint on FAQ.

@lunny commented on GitHub (Feb 7, 2020): @0x6d61726b That's a good workaround. Maybe we should add a hint on FAQ.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#4775
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?