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

TFA broken after update from 1.14.x to 1.15.x. #7794

New Issue
Closed
opened 2025-11-02 07:36:38 -06:00 by GiteaMirror · 14 comments
GiteaMirror commented 2025-11-02 07:36:38 -06:00
Owner
Copy Link

Originally created by @Kusoneko on GitHub (Sep 2, 2021).

  • Gitea version (or commit ref): 1.15.1
  • Git version: 2.33.0
  • Operating system: Arch Linux Built with bindata. Running from systemd service file.
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
  • Log gist: Not Applicable

Description

After updating from 1.14.6 to 1.15.0 (presumably when the issue happened as I didn't try login in then and then from 1.15.0 to 1.15.1, I couldn't login with either my scratch code or my TFA TOTP generated code. I had to manually go delete my entry in my MySQL database in the two_factor table to be able to login again. Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow. I'm assuming there's some form of breaking change that happened with TFA in between 1.14.x and 1.15.x otherwise this wouldn't make any sense, despite my not seeing any TFA related stuff in the changelog for the breaking changes of 1.15.0. I'm essentially wanting to find out what I need to do to fix it. So far I haven't changed anything when building the new versions, only built them and then restarted gitea via # systemctl restart gitea. If there is any manual changes I need to do to fix this in config files or whatever, I would appreciate having them noted somewhere.

Screenshots

Not Applicable

Originally created by @Kusoneko on GitHub (Sep 2, 2021). <!-- NOTE: If your issue is a security concern, please send an email to security@gitea.io instead of opening a public issue --> <!-- 1. Please speak English, this is the language all maintainers can speak and write. 2. Please ask questions or configuration/deploy problems on our Discord server (https://discord.gg/gitea) or forum (https://discourse.gitea.io). 3. Please take a moment to check that your issue doesn't already exist. 4. Make sure it's not mentioned in the FAQ (https://docs.gitea.io/en-us/faq) 5. Please give all relevant information below for bug reports, because incomplete details will be handled as an invalid report. --> - Gitea version (or commit ref): 1.15.1 - Git version: 2.33.0 - Operating system: Arch Linux <!-- Please include information on whether you built gitea yourself, used one of our downloads or are using some other package --> Built with bindata. <!-- Please also tell us how you are running gitea, e.g. if it is being run from docker, a command-line, systemd etc. ---> Running from systemd service file. <!-- If you are using a package or systemd tell us what distribution you are using --> - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [x] No - Log gist: Not Applicable <!-- It really is important to provide pertinent logs --> <!-- Please read https://docs.gitea.io/en-us/logging-configuration/#debugging-problems --> <!-- In addition, if your problem relates to git commands set `RUN_MODE=dev` at the top of app.ini --> ## Description <!-- If using a proxy or a CDN (e.g. CloudFlare) in front of gitea, please disable the proxy/CDN fully and connect to gitea directly to confirm the issue still persists without those services. --> After updating from 1.14.6 to 1.15.0 (presumably when the issue happened as I didn't try login in then and then from 1.15.0 to 1.15.1, I couldn't login with either my scratch code or my TFA TOTP generated code. I had to manually go delete my entry in my MySQL database in the two_factor table to be able to login again. Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow. I'm assuming there's some form of breaking change that happened with TFA in between 1.14.x and 1.15.x otherwise this wouldn't make any sense, despite my not seeing any TFA related stuff in the changelog for the breaking changes of 1.15.0. I'm essentially wanting to find out what I need to do to fix it. So far I haven't changed anything when building the new versions, only built them and then restarted gitea via `# systemctl restart gitea`. If there is any manual changes I need to do to fix this in config files or whatever, I would appreciate having them noted somewhere. ## Screenshots <!-- **If this issue involves the Web Interface, please include a screenshot** --> Not Applicable
GiteaMirror commented 2025-11-02 07:36:39 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Sep 2, 2021):

Did you backup and restore using gitea dump? (I'm suggesting this as a potential cause - not a solution)

@zeripath commented on GitHub (Sep 2, 2021): Did you backup and restore using gitea dump? (I'm suggesting this as a potential cause - not a solution)
GiteaMirror commented 2025-11-02 07:36:39 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 2, 2021):

No, I did not. If I should have how do I fix this now? Note that besides TFA everything else appears to work fine on both the web app and using git commands locally and pushing/pulling from the gitea instance, so I might have gotten off lightly if that's something that should be done before upgrading versions like this.

@Kusoneko commented on GitHub (Sep 2, 2021): No, I did not. If I should have how do I fix this now? Note that besides TFA everything else appears to work fine on both the web app and using git commands locally and pushing/pulling from the gitea instance, so I might have gotten off lightly if that's something that should be done before upgrading versions like this.
GiteaMirror commented 2025-11-02 07:36:39 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Sep 2, 2021):

@zeripath could this be related to secret not being set?

@techknowlogick commented on GitHub (Sep 2, 2021): @zeripath could this be related to secret not being set?
GiteaMirror commented 2025-11-02 07:36:39 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 2, 2021):

@zeripath could this be related to secret not being set?

I'd doubt it personally, if we're talking about my app.ini file, I just did # cat /etc/gitea/app.ini | grep SECRET and I have LFS_JWT_SECRET, SECRET_KEY and JWT_SECRET set. RECAPTCHA_SECRET, HCAPTCHA_SECRET and MINIO_SECRET_ACCESS_KEY unset.

@Kusoneko commented on GitHub (Sep 2, 2021): > @zeripath could this be related to secret not being set? I'd doubt it personally, if we're talking about my app.ini file, I just did `# cat /etc/gitea/app.ini | grep SECRET` and I have LFS_JWT_SECRET, SECRET_KEY and JWT_SECRET set. RECAPTCHA_SECRET, HCAPTCHA_SECRET and MINIO_SECRET_ACCESS_KEY unset.
GiteaMirror commented 2025-11-02 07:36:39 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Sep 2, 2021):

@zeripath could this be related to secret not being set?

that would explain it failing only once I think.

I'm a bit stumped. The usual failure for TOTP is something to do with time offsets but I don't understand why it would have worked previously and not now.

There's nothing that immediately comes to mind as a possible cause - except maybe - just maybe some weird cookie issue.

I can't immediately replicate it here, and so the only thing I can think of is for you to add extra logging and build gitea.

@zeripath commented on GitHub (Sep 2, 2021): > @zeripath could this be related to secret not being set? that would explain it failing only once I think. I'm a bit stumped. The usual failure for TOTP is something to do with time offsets but I don't understand why it would have worked previously and not now. There's nothing that immediately comes to mind as a possible cause - except maybe - just maybe some weird cookie issue. I can't immediately replicate it here, and so the only thing I can think of is for you to add extra logging and build gitea.
GiteaMirror commented 2025-11-02 07:36:40 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 3, 2021):

I can't immediately replicate it here, and so the only thing I can think of is for you to add extra logging and build gitea.

I'm not sure what you mean by building gitea after adding extra logging, I just changed to log level to Debug in app.ini and restarted gitea, and couldn't find anywhere in the docs a build setting to use to enable further logging, but I'm missing something clearly. First, the log only contains the following for TFA stuff that I can see:

Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 Started POST /user/settings/security/two_factor/enroll for [::1]:42432
Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 ...s/context/context.go:740:1() [D] Session ID: probably_private
Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 ...s/context/context.go:741:1() [D] CSRF Token: probably_private
Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 Completed POST /user/settings/security/two_factor/enroll 302 Found in 21.101646ms
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /user/settings/security/two_factor/enroll for 127.0.0.1:49340
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:185:HTML() [D] Template: user/settings/twofa_enroll
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Completed GET /user/settings/security/two_factor/enroll 200 OK in 24.028686ms
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /avatar/8749a188a5e167b6fee6b9613ba71d97?size=96 for [::1]:42434
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Completed GET /avatar/8749a188a5e167b6fee6b9613ba71d97?size=96 302 Found in 2.598738ms
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /user/events for 127.0.0.1:49342
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private
Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private

Similarly, when looking from the dev tools of the browser, the TFA enroll page indeed starts off with a 302 followed by a 200, and when clicking the Verify button, it reloads but shows an Invalid passcode message. Nothing new seems to appear in the logs.

I did notice however that no matter how many time I leave and come back to the TFA enroll page, the TOTP secret shown on the page is always exactly the same secret (and the QR is likely the same since it gives my phone app the same TOTP secret as well), implying the problem is potentially with it not showing the right secret rather than TFA by itself not working. Hopefully that'll help a little with figuring out what's wrong.

A bit unrelated, but while we're here, I looked at the start of the logs and I'm seeing the following 2 Errors at the start:

Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 74645
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...es/setting/markup.go:113:createMarkupSanitizerRule() [E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined!
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 cmd/web.go:146:runWeb() [I] Global init
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...es/setting/markup.go:113:createMarkupSanitizerRule() [E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined!

and the following ton of warnings right after the PING DATABASE thing:

Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table public_key column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repository column description db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repository column topics db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table action column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table issue column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table pull_request column conflicted_files db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table comment column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table comment column patch db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table milestone column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table release column note db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table login_source column cfg db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook Column is_system_webhook db default is 0, struct default is
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook Column is_system_webhook db nullable is false, struct nullable is true
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column url db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column secret db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column events db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column meta db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column payload_content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column request_content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column response_content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table notice column description db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table email_address Column lower_email db nullable is true, struct nullable is false
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key column emails db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key_import column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repo_unit column config db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column raw_data db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column avatar_url db type is TEXT, struct type is VARCHAR(255)
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column access_token db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column access_token_secret db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column refresh_token db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column merge_whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column merge_whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column status_check_contexts db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column approvals_whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column approvals_whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column target_url db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column description db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column context db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table lfs_lock column path db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table review column content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table oauth2_application column redirect_uris db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table task column payload_content db type is MEDIUMTEXT, struct type is TEXT
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table language_stat Column language db nullable is true, struct nullable is false
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table project column board_type db type is INT(11), struct type is INT UNSIGNED
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table project column type db type is INT(11), struct type is INT UNSIGNED
Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table session has column created_unix but struct has not related field

Are these errors and warnings fixable?

Thank you!

@Kusoneko commented on GitHub (Sep 3, 2021): > I can't immediately replicate it here, and so the only thing I can think of is for you to add extra logging and build gitea. I'm not sure what you mean by building gitea after adding extra logging, I just changed to log level to Debug in app.ini and restarted gitea, and couldn't find anywhere in the docs a build setting to use to enable further logging, but I'm missing something clearly. First, the log only contains the following for TFA stuff that I can see: ``` Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 Started POST /user/settings/security/two_factor/enroll for [::1]:42432 Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 ...s/context/context.go:740:1() [D] Session ID: probably_private Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 ...s/context/context.go:741:1() [D] CSRF Token: probably_private Sep 02 20:58:05 kusoneko.moe gitea[74645]: 2021/09/02 20:58:05 Completed POST /user/settings/security/two_factor/enroll 302 Found in 21.101646ms Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /user/settings/security/two_factor/enroll for 127.0.0.1:49340 Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:185:HTML() [D] Template: user/settings/twofa_enroll Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Completed GET /user/settings/security/two_factor/enroll 200 OK in 24.028686ms Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /avatar/8749a188a5e167b6fee6b9613ba71d97?size=96 for [::1]:42434 Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Completed GET /avatar/8749a188a5e167b6fee6b9613ba71d97?size=96 302 Found in 2.598738ms Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 Started GET /user/events for 127.0.0.1:49342 Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:740:1() [D] Session ID: probably_private Sep 02 20:58:06 kusoneko.moe gitea[74645]: 2021/09/02 20:58:06 ...s/context/context.go:741:1() [D] CSRF Token: probably_private ``` Similarly, when looking from the dev tools of the browser, the TFA enroll page indeed starts off with a 302 followed by a 200, and when clicking the Verify button, it reloads but shows an Invalid passcode message. Nothing new seems to appear in the logs. I did notice however that no matter how many time I leave and come back to the TFA enroll page, the TOTP secret shown on the page is ***always*** exactly the same secret (and the QR is likely the same since it gives my phone app the same TOTP secret as well), implying the problem is potentially with it not showing the right secret rather than TFA by itself not working. Hopefully that'll help a little with figuring out what's wrong. A bit unrelated, but while we're here, I looked at the start of the logs and I'm seeing the following 2 Errors at the start: ``` Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 cmd/web.go:102:runWeb() [I] Starting Gitea on PID: 74645 Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...es/setting/markup.go:113:createMarkupSanitizerRule() [E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined! Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 cmd/web.go:146:runWeb() [I] Global init Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...es/setting/markup.go:113:createMarkupSanitizerRule() [E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined! ``` and the following ton of warnings right after the PING DATABASE thing: ``` Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table public_key column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repository column description db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repository column topics db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table action column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table issue column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table pull_request column conflicted_files db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table comment column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table comment column patch db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table milestone column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table release column note db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table login_source column cfg db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook Column is_system_webhook db default is 0, struct default is Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook Column is_system_webhook db nullable is false, struct nullable is true Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column url db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column secret db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column events db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table webhook column meta db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column payload_content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column request_content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table hook_task column response_content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table notice column description db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table email_address Column lower_email db nullable is true, struct nullable is false Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key column emails db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table gpg_key_import column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table repo_unit column config db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column raw_data db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column avatar_url db type is TEXT, struct type is VARCHAR(255) Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column access_token db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column access_token_secret db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table external_login_user column refresh_token db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column merge_whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column merge_whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column status_check_contexts db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column approvals_whitelist_user_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table protected_branch column approvals_whitelist_team_i_ds db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column target_url db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column description db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table commit_status column context db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table lfs_lock column path db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table review column content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table oauth2_application column redirect_uris db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table task column payload_content db type is MEDIUMTEXT, struct type is TEXT Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table language_stat Column language db nullable is true, struct nullable is false Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table project column board_type db type is INT(11), struct type is INT UNSIGNED Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table project column type db type is INT(11), struct type is INT UNSIGNED Sep 02 20:49:28 kusoneko.moe gitea[74645]: 2021/09/02 20:49:28 ...om/urfave/cli/app.go:524:HandleAction() [W] Table session has column created_unix but struct has not related field ``` Are these errors and warnings fixable? Thank you!
GiteaMirror commented 2025-11-02 07:36:40 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Sep 3, 2021):

As per our FAQ it is safe to ignore the table warnings although gitea doctor recreate-table should make them go away.

[E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined!

This implies that, like many people, you have copied app.ini.sample/app.example.ini straight across as your app.ini despite the very large warning at the top of that file NOT to do that. (We have had to comment almost the whole file out in 1.15+ because of this.)

You need to seriously simplify your app.ini dropping whole sections from it that you have not explicitly set. My own app.ini is 75 lines long and really that is still too long.

These app.ini issues aren't obviously the cause of the problem (except where maybe you've incorrectly overconfigured your cookies?)

Looking at your logs I see that the IP address you are posting from to appears to be flipping from 127.0.0.1 to [::1] which is concerning that you might be associated with different sessions etc.

You've sanitized the session id away so I can't check that theyre the same and you've not given me the logs from the GET before the enroll POST so I can't check that either. We need to see a little more of the interaction before the POST.

It's helpful to double check if the issue is a browser specific one - i.e. are there multiple weird cookies on your browser that need to be erased.

You haven't told us whether there's a reverse proxy involved or if Gitea is mounted on a suburl. Are you definitely accessing gitea by its ROOT_URL - maybe the cookies aren't being passed down - the session id being the same should assert that.

Regarding additional logging:

You asserted that debug logs were not helpful - although it does appear that they may help shed further light on this issue so follow the instructions given in issue proforma and give us those logs. My suggestion about us adding extra logging was that we would need to compile in some extra logging at certain places.

Give us the logs as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems sanitising only the minimum and asserting where things are the same if you've sanitized them away.

Explain your setup, e.g. reverse proxy or not, how are you running gitea, what is your systemd unit file, what version of mysql/mariadb.

Show us your app.ini - you can send me the unsanitised one on discord if you message me directly.

Check if on private browsing or different browser if things work. The problem may be cookie related.

@zeripath commented on GitHub (Sep 3, 2021): As per our FAQ it is safe to ignore the table warnings although `gitea doctor recreate-table` should make them go away. `[E] Missing required keys from markup.sanitizer.1. Must have ELEMENT and ALLOW_ATTR or ALLOW_DATA_URI_IMAGES defined!` This implies that, like many people, you have copied app.ini.sample/app.example.ini straight across as your app.ini despite the very large warning at the top of that file NOT to do that. (We have had to comment almost the whole file out in 1.15+ because of this.) You need to seriously simplify your app.ini dropping whole sections from it that you have not explicitly set. My own app.ini is 75 lines long and really that is still too long. --- These app.ini issues aren't obviously the cause of the problem (except where maybe you've incorrectly overconfigured your cookies?) --- Looking at your logs I see that the IP address you are posting from to appears to be flipping from 127.0.0.1 to [::1] which is concerning that you might be associated with different sessions etc. You've sanitized the session id away so I can't check that theyre the same and you've not given me the logs from the GET before the enroll POST so I can't check that either. We need to see a little more of the interaction before the POST. It's helpful to double check if the issue is a browser specific one - i.e. are there multiple weird cookies on your browser that need to be erased. You haven't told us whether there's a reverse proxy involved or if Gitea is mounted on a suburl. Are you definitely accessing gitea by its ROOT_URL - maybe the cookies aren't being passed down - the session id being the same should assert that. --- Regarding additional logging: You asserted that debug logs were not helpful - although it does appear that they may help shed further light on this issue so follow the instructions given in issue proforma and give us those logs. My suggestion about us adding extra logging was that we would need to compile in some extra logging at certain places. Give us the logs as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems sanitising only the minimum and asserting where things are the same if you've sanitized them away. Explain your setup, e.g. reverse proxy or not, how are you running gitea, what is your systemd unit file, what version of mysql/mariadb. Show us your app.ini - you can send me the unsanitised one on discord if you message me directly. Check if on private browsing or different browser if things work. The problem may be cookie related.
GiteaMirror commented 2025-11-02 07:36:40 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 3, 2021):

These app.ini issues aren't obviously the cause of the problem (except where maybe you've incorrectly overconfigured your cookies?)

Thanks, that fixed the errors and most of the warnings, I assume the last 2 that gitea doctor didn't fix, where it says the table's field should be int unsigned and that it's currently int(10) unsigned is far from the end of the world.

Well, I did configure them a bit, but I just swapped it from storing the sessions from file mode to memory mode, and deleted all my cookies for the instance to see if something changed, indeed, the TOTP secret has changed afterwards, but it's sticking to the new secret now, and still refusing codes. This is a really odd issue.

Looking at your logs I see that the IP address you are posting from to appears to be flipping from 127.0.0.1 to [::1] which is concerning that you might be associated with different sessions etc.

You've sanitized the session id away so I can't check that they're the same and you've not given me the logs from the GET before the enroll POST so I can't check that either. We need to see a little more of the interaction before the POST.

It's helpful to double check if the issue is a browser specific one - i.e. are there multiple weird cookies on your browser that need to be erased.

They were identical for that specific snippet.

You haven't told us whether there's a reverse proxy involved or if Gitea is mounted on a subgitea-log.txt. Are you definitely accessing gitea by its ROOT_URL - maybe the cookies aren't being passed down - the session id being the same should assert that.

Regarding additional logging:

You asserted that debug logs were not helpful - although it does appear that they may help shed further light on this issue so follow the instructions given in issue proforma and give us those logs. My suggestion about us adding extra logging was that we would need to compile in some extra logging at certain places.

Give us the logs as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems sanitising only the minimum and asserting where things are the same if you've sanitized them away.

Explain your setup, e.g. reverse proxy or not, how are you running gitea, what is your systemd unit file, what version of mysql/mariadb.

Show us your app.ini - you can send me the unsanitised one on discord if you message me directly.

Check if on private browsing or different browser if things work. The problem may be cookie related.

Right, my gitea instance is configured to listen to localhost:3001 (unless I'm misunderstanding the app.ini comments), except for ssh requests which is actually using the git user and openssh's sshd. SSH works fine, so that's not the issue. The server is actually serving multiple (mostly personal) web apps and services, so to prevent port collision issues and all that, all of them are being run behind nginx as a reverse proxy (except for one or 2 webpages that nginx serves itself), unless they're not web apps and therefore don't require port 443/80 to be used without fiddling around with ports in a browser.

The results of $ mysql --version: mysql Ver 15.1 Distrib 10.6.4-MariaDB, for Linux (x86_64) using readline 5.1

SystemD service file: gitea.service

The logs after stopping gitea, removing all my cookies from my browser, then restarting gitea, while I go speedrun to the TFA enroll page are here: log.txt
The Session IDs were renamed id# and the CSRF Tokens token# with sed, so they should have the same number for all occurrences of each.

The app.ini configuration for the looks like this: app.ini
Note that I'm not sure in this app.ini file (which I did a quick cleanup of) what's left that is by default and thus can be removed and what isn't. I'm off to bed for now though, so I'll perhaps think about looking it up later.

Thanks.

EDIT: Moved the code snippets for each file to actual attachments to prevent a 30-meters long wall of text.

@Kusoneko commented on GitHub (Sep 3, 2021): > These app.ini issues aren't obviously the cause of the problem (except where maybe you've incorrectly overconfigured your cookies?) Thanks, that fixed the errors and most of the warnings, I assume the last 2 that gitea doctor didn't fix, where it says the table's field should be int unsigned and that it's currently int(10) unsigned is far from the end of the world. Well, I did configure them a bit, but I just swapped it from storing the sessions from file mode to memory mode, and deleted all my cookies for the instance to see if something changed, indeed, the TOTP secret has changed afterwards, but it's sticking to the new secret now, and still refusing codes. This is a really odd issue. > Looking at your logs I see that the IP address you are posting from to appears to be flipping from 127.0.0.1 to [::1] which is concerning that you might be associated with different sessions etc. > > You've sanitized the session id away so I can't check that they're the same and you've not given me the logs from the GET before the enroll POST so I can't check that either. We need to see a little more of the interaction before the POST. > > It's helpful to double check if the issue is a browser specific one - i.e. are there multiple weird cookies on your browser that need to be erased. They were identical for that specific snippet. > You haven't told us whether there's a reverse proxy involved or if Gitea is mounted on a sub[gitea-log.txt](https://github.com/go-gitea/gitea/files/7103796/gitea-log.txt). Are you definitely accessing gitea by its ROOT_URL - maybe the cookies aren't being passed down - the session id being the same should assert that. > > Regarding additional logging: > > You asserted that debug logs were not helpful - although it does appear that they may help shed further light on this issue so follow the instructions given in issue proforma and give us those logs. My suggestion about us adding extra logging was that we would need to compile in some extra logging at certain places. > > Give us the logs as per https://docs.gitea.io/en-us/logging-configuration/#debugging-problems sanitising only the minimum and asserting where things are the same if you've sanitized them away. > > Explain your setup, e.g. reverse proxy or not, how are you running gitea, what is your systemd unit file, what version of mysql/mariadb. > > Show us your app.ini - you can send me the unsanitised one on discord if you message me directly. > > Check if on private browsing or different browser if things work. The problem may be cookie related. Right, my gitea instance is configured to listen to localhost:3001 (unless I'm misunderstanding the app.ini comments), except for ssh requests which is actually using the git user and openssh's sshd. SSH works fine, so that's not the issue. The server is actually serving multiple (mostly personal) web apps and services, so to prevent port collision issues and all that, all of them are being run behind nginx as a reverse proxy (except for one or 2 webpages that nginx serves itself), unless they're not web apps and therefore don't require port 443/80 to be used without fiddling around with ports in a browser. The results of `$ mysql --version`: `mysql Ver 15.1 Distrib 10.6.4-MariaDB, for Linux (x86_64) using readline 5.1` SystemD service file: [gitea.service](https://github.com/go-gitea/gitea/files/7103820/gitea-service.txt) The logs after stopping gitea, removing all my cookies from my browser, then restarting gitea, while I go speedrun to the TFA enroll page are here: [log.txt](https://github.com/go-gitea/gitea/files/7103796/gitea-log.txt) The Session IDs were renamed id# and the CSRF Tokens token# with sed, so they should have the same number for all occurrences of each. The app.ini configuration for the looks like this: [app.ini](https://github.com/go-gitea/gitea/files/7103812/gitea-app.txt) Note that I'm not sure in this app.ini file (which I did a quick cleanup of) what's left that is by default and thus can be removed and what isn't. I'm off to bed for now though, so I'll perhaps think about looking it up later. Thanks. EDIT: Moved the code snippets for each file to actual attachments to prevent a 30-meters long wall of text.
GiteaMirror commented 2025-11-02 07:36:40 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Sep 3, 2021):

Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow.

A small question, have you checked your system time (running Gitea instance) is accurate and correct? You can check your system time here: https://time.is . Or check time by google:

$ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*"
< date: Fri, 03 Sep 2021 06:57:17 GMT

$ date -u
Fri Sep  3 06:57:17 UTC 2021
@wxiaoguang commented on GitHub (Sep 3, 2021): > Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow. A small question, have you checked your system time (running Gitea instance) is accurate and correct? You can check your system time here: https://time.is . Or check time by google: ``` $ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*" < date: Fri, 03 Sep 2021 06:57:17 GMT $ date -u Fri Sep 3 06:57:17 UTC 2021 ```
GiteaMirror commented 2025-11-02 07:36:41 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 3, 2021):

Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow.

A small question, have you checked your system time (running Gitea instance) is accurate and correct? You can check your system time here: https://time.is . Or check time by google:

$ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*"
< date: Fri, 03 Sep 2021 06:57:17 GMT

$ date -u
Fri Sep  3 06:57:17 UTC 2021

$ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*";date -u
< date: Fri, 03 Sep 2021 07:15:23 GMT
Fri Sep  3 07:16:24 AM UTC 2021

That's odd, it's apparently off by a full minute, I'm not sure how to fix that though.

@Kusoneko commented on GitHub (Sep 3, 2021): > > Then I went to set it up again, and using both a desktop TOTP generator and copying the secret into it, as well as using the QR code for a mobile TFA app and made both generate the 6-digit codes, and both generate the exact same codes and switch codes at the exact same time, however, the Enroll into TFA page on my gitea instance is claiming that the new passcodes generated by both using the secret it provides is invalid somehow. > > A small question, have you checked your system time (running Gitea instance) is accurate and correct? You can check your system time here: https://time.is . Or check time by google: > > ``` > $ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*" > < date: Fri, 03 Sep 2021 06:57:17 GMT > > $ date -u > Fri Sep 3 06:57:17 UTC 2021 > ``` ``` $ curl -v "https://google.com" 2>&1 | grep -i "date:" | grep -v "^\*";date -u < date: Fri, 03 Sep 2021 07:15:23 GMT Fri Sep 3 07:16:24 AM UTC 2021 ``` That's odd, it's apparently off by a full minute, I'm not sure how to fix that though.
GiteaMirror commented 2025-11-02 07:36:41 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Sep 3, 2021):

You see, it's your system time's problem.

TOTP won't work correctly if the error between your server's time and client's time is greater than a few seconds.

The time window for a TOTP code is usually 30 seconds. The larger the error is, the more likely the OTP code will fail. When the error is greater than 30 seconds, the OTP code will always fail.

As long as you set your server's time to the correct time, the problem will disappear.

So it's not Gitea's bug 😊

@wxiaoguang commented on GitHub (Sep 3, 2021): You see, it's your system time's problem. TOTP won't work correctly if the error between your server's time and client's time is greater than a few seconds. The time window for a TOTP code is usually 30 seconds. The larger the error is, the more likely the OTP code will fail. When the error is greater than 30 seconds, the OTP code will always fail. As long as you set your server's time to the correct time, the problem will disappear. So it's not Gitea's bug 😊
GiteaMirror commented 2025-11-02 07:36:41 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Sep 3, 2021):

PS: Maybe the TOTP problem should be written into FAQ. I know many people use servers with wrong system time.

@wxiaoguang commented on GitHub (Sep 3, 2021): PS: Maybe the TOTP problem should be written into FAQ. I know many people use servers with wrong system time.
GiteaMirror commented 2025-11-02 07:36:41 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Sep 3, 2021):

@wxiaoguang I meant to suggest timing but I was distracted by them saying it had previously worked but yes this would be consistent with that being the issue.

So I'm gonna close.

@zeripath commented on GitHub (Sep 3, 2021): @wxiaoguang I meant to suggest timing but I was distracted by them saying it had previously worked but yes this would be consistent with that being the issue. So I'm gonna close.
GiteaMirror commented 2025-11-02 07:36:41 -06:00
Author
Owner
Copy Link

@Kusoneko commented on GitHub (Sep 3, 2021):

Just to confirm, I went and enabled and started systemd-timesyncd that was for some reason not enabled nor started, and tried again and this time it worked. Thank you everyone!

@Kusoneko commented on GitHub (Sep 3, 2021): Just to confirm, I went and enabled and started systemd-timesyncd that was for some reason not enabled nor started, and tried again and this time it worked. Thank you everyone!
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
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#7794
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?