[Bug] 1.16.1 Push with username broken #8528

New Issue

GiteaMirror · 2025-11-02T08:09:50-06:00

GiteaMirror commented

2025-11-02 08:09:50 -06:00

Originally created by @rakshith-ravi on GitHub (Feb 8, 2022).

Gitea Version

1.16.1

Git Version

No response

Operating System

Ubuntu 18.04

How are you running Gitea?

Direct binary from GitHub release, using systemd

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

Can't seem to get anything on the logs :(
Please help me to get the logs

Description

When I try to push using my username, I get a remote: Unauthorized error. But when I try to push using my email address, it seems to work perfectly fine

Screenshots

No response

Originally created by @rakshith-ravi on GitHub (Feb 8, 2022). ### Gitea Version 1.16.1 ### Git Version _No response_ ### Operating System Ubuntu 18.04 ### How are you running Gitea? Direct binary from GitHub release, using systemd ### Database MySQL ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist Can't seem to get anything on the logs :( Please help me to get the logs ### Description When I try to push using my username, I get a `remote: Unauthorized` error. But when I try to push using my email address, it seems to work perfectly fine ### Screenshots _No response_

GiteaMirror added the issue/needs-feedback label 2025-11-02 08:09:50 -06:00

GiteaMirror closed this issue

2025-11-02 08:09:50 -06:00

GiteaMirror commented

2025-11-02 08:09:51 -06:00

@zeripath commented on GitHub (Feb 9, 2022):

journalctl -u gitea

@zeripath commented on GitHub (Feb 9, 2022): `journalctl -u gitea`

GiteaMirror commented

2025-11-02 08:09:52 -06:00

@rakshith-ravi commented on GitHub (Feb 10, 2022):

I did that, and I got this:

Feb 10 09:26:37 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:37 Started GET /vicara/vicara-api/info/refs?service=git-upload-pack for 127.0.0.1:36656
Feb 10 09:26:37 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:37 Completed GET /vicara/vicara-api/info/refs?service=git-upload-pack 401 Unauthorized in 92.694083ms
Feb 10 09:26:43 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:43 Started GET /vicara/vicara-api/info/refs?service=git-upload-pack for 127.0.0.1:36660
Feb 10 09:26:43 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:43 Completed GET /vicara/vicara-api/info/refs?service=git-upload-pack 401 Unauthorized in 12.504429ms

There doesn't seem to be much else in this as of now. Is there any other place I can look at for logs? Is there a way to enable some kind of "extensive logging" mode for us to see the logs?

./log/gitea.log doesn't seem to print any kind of login event at all, so I'm not sure where to look :(

@rakshith-ravi commented on GitHub (Feb 10, 2022): I did that, and I got this: ``` Feb 10 09:26:37 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:37 Started GET /vicara/vicara-api/info/refs?service=git-upload-pack for 127.0.0.1:36656 Feb 10 09:26:37 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:37 Completed GET /vicara/vicara-api/info/refs?service=git-upload-pack 401 Unauthorized in 92.694083ms Feb 10 09:26:43 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:43 Started GET /vicara/vicara-api/info/refs?service=git-upload-pack for 127.0.0.1:36660 Feb 10 09:26:43 ubuntu-blr1-01 bin[13212]: 2022/02/10 09:26:43 Completed GET /vicara/vicara-api/info/refs?service=git-upload-pack 401 Unauthorized in 12.504429ms ``` There doesn't seem to be much else in this as of now. Is there any other place I can look at for logs? Is there a way to enable some kind of "extensive logging" mode for us to see the logs? `./log/gitea.log` doesn't seem to print any kind of login event at all, so I'm not sure where to look :(

GiteaMirror commented

2025-11-02 08:09:52 -06:00

@zeripath commented on GitHub (Feb 10, 2022):

Logs

When you are reporting bugs or issues it is helpful to give us DEBUG logs.

In fact the issue proforma expressly asks you to do that and links to a helpful section of the documentation that to do that: https://docs.gitea.io/en-us/logging-configuration/#debugging-problems

I will copy that below:

Debugging problems

When submitting logs in Gitea issues it is often helpful to submit
merged logs obtained by either by redirecting the console log to a file or
copying and pasting it. To that end it is recommended to set your logging to:

[database]
LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them

...

[log]
MODE = console
LEVEL = debug ; please set the level to debug when we are debugging a problem
ROUTER = console
COLORIZE = false ; this can be true if you can strip out the ansi coloring

Sometimes it will be helpful get some specific TRACE level logging restricted
to messages that match a specific EXPRESSION. Adjusting the MODE in the
[log] section to MODE = console,traceconsole to add a new logger output
traceconsole and then adding its corresponding section would be helpful:

[log.traceconsole] ; traceconsole here is just a name
MODE = console ; this is the output that the traceconsole writes to
LEVEL = trace
EXPRESSION = ; putting a string here will restrict this logger to logging only those messages that match this expression

(It's worth noting that log messages that match the expression at or above debug
level will get logged twice so don't worry about that.)

STACKTRACE_LEVEL should generally be left unconfigured (and hence kept at
none). There are only very specific occasions when it useful.

@zeripath commented on GitHub (Feb 10, 2022): # Logs When you are reporting bugs or issues it is helpful to give us DEBUG logs. In fact the issue proforma expressly asks you to do that and links to a helpful section of the documentation that to do that: https://docs.gitea.io/en-us/logging-configuration/#debugging-problems I will copy that below: ## Debugging problems When submitting logs in Gitea issues it is often helpful to submit merged logs obtained by either by redirecting the console log to a file or copying and pasting it. To that end it is recommended to set your logging to: ```ini [database] LOG_SQL = false ; SQL logs are rarely helpful unless we specifically ask for them ... [log] MODE = console LEVEL = debug ; please set the level to debug when we are debugging a problem ROUTER = console COLORIZE = false ; this can be true if you can strip out the ansi coloring ``` Sometimes it will be helpful get some specific `TRACE` level logging restricted to messages that match a specific `EXPRESSION`. Adjusting the `MODE` in the `[log]` section to `MODE = console,traceconsole` to add a new logger output `traceconsole` and then adding its corresponding section would be helpful: ```ini [log.traceconsole] ; traceconsole here is just a name MODE = console ; this is the output that the traceconsole writes to LEVEL = trace EXPRESSION = ; putting a string here will restrict this logger to logging only those messages that match this expression ``` (It's worth noting that log messages that match the expression at or above debug level will get logged twice so don't worry about that.) `STACKTRACE_LEVEL` should generally be left unconfigured (and hence kept at `none`). There are only very specific occasions when it useful.

GiteaMirror commented

2025-11-02 08:09:52 -06:00

@wxiaoguang commented on GitHub (Apr 16, 2022):

Outdated, please open a new issue if there is still any problem

@wxiaoguang commented on GitHub (Apr 16, 2022): Outdated, please open a new issue if there is still any problem

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8528