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

Avatars not visible in commit view when no-reply address is configured to the real domain #14668

New Issue
Closed
opened 2025-11-02 11:19:29 -06:00 by GiteaMirror · 15 comments
GiteaMirror commented 2025-11-02 11:19:29 -06:00
Owner
Copy Link

Originally created by @smartEBL on GitHub (Jun 27, 2025).

Description

This is basically the same problem as being reported by https://github.com/go-gitea/gitea/issues/33595

There are two observations:

  • The icons (custom ones) are not correctly displayed - nearly all of them show the "default" one. This happens in the commit view in the "Code" tab of a repo, as well as in the commit view of any Pull request.
  • The link behind the commit author is broken and will lead to a 404 page.

In our setup we use ldap for authentication. The gitea usernames are lastname, while the email addresses are firstname.lastname@company.bla.
The link created for a user will be http://gitea:3000/firstname lastname - which does not exist. Instead it should be http://gitea:3000/lastname.

In some cases this link creation works - if the user misconfigured his git email address to lastname@company.bla instead of firstname.lastname@company.bla.

Gitea Version

1.24.2

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

Image

Git Version

2.49.0

Operating System

Ubuntu 22.04

How are you running Gitea?

Gitea 1.24.2 via docker compose with SQLite database

Database

SQLite

Originally created by @smartEBL on GitHub (Jun 27, 2025). ### Description This is basically the same problem as being reported by https://github.com/go-gitea/gitea/issues/33595 There are two observations: - The icons (custom ones) are not correctly displayed - nearly all of them show the "default" one. This happens in the commit view in the "Code" tab of a repo, as well as in the commit view of any Pull request. - The link behind the commit author is broken and will lead to a 404 page. In our setup we use ldap for authentication. The gitea usernames are `lastname`, while the email addresses are `firstname.lastname@company.bla`. The link created for a user will be `http://gitea:3000/firstname lastname` - which does not exist. Instead it should be `http://gitea:3000/lastname`. In some cases this link creation works - if the user misconfigured his git email address to `lastname@company.bla` instead of `firstname.lastname@company.bla`. ### Gitea Version 1.24.2 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![Image](https://github.com/user-attachments/assets/f058867d-2037-4ff2-8b47-bcc42a6b81a5) ### Git Version 2.49.0 ### Operating System Ubuntu 22.04 ### How are you running Gitea? Gitea 1.24.2 via docker compose with SQLite database ### Database SQLite
GiteaMirror added the type/bugissue/workaround labels 2025-11-02 11:19:29 -06:00
GiteaMirror commented 2025-11-02 11:19:30 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jun 27, 2025):

Can you check whether the email firstname.lastname@company.bla in database (the email_address table) is active or not?

@wxiaoguang commented on GitHub (Jun 27, 2025): Can you check whether the email `firstname.lastname@company.bla` in database (the `email_address` table) is active or not?
GiteaMirror commented 2025-11-02 11:19:30 -06:00
Author
Owner
Copy Link

@smartEBL commented on GitHub (Jun 27, 2025):

Can you check whether the email firstname.lastname@company.bla in database (the email_address table) is active or not?

Hey. Thanks for the super quick response!
The email address has is_activated and also is_primary set as 1

@smartEBL commented on GitHub (Jun 27, 2025): > Can you check whether the email `firstname.lastname@company.bla` in database (the `email_address` table) is active or not? Hey. Thanks for the super quick response! The email address has `is_activated` and also `is_primary` set as `1`
GiteaMirror commented 2025-11-02 11:19:30 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jun 27, 2025):

That's strange, the bug should have been fixed in 1.24

The logic overall looks like this:

c6467edcb1/models/user/user.go (L1172)

c6467edcb1/models/user/user.go (L1225)

  • Get committer email from git commit
  • Search it from email_address table bye WHERE lower_email = {git email} AND is_active=true, then get related users
  • The code is covered by some tests and is tested on gitea.com and by some other users (well, maybe no LDAP was involved)

So without a reproduce sample, it's difficult for me to figure out what happens ....

Are you able to provide more clues, or a reproducible setup?

@wxiaoguang commented on GitHub (Jun 27, 2025): That's strange, the bug should have been fixed in 1.24 The logic overall looks like this: https://github.com/go-gitea/gitea/blob/c6467edcb1543a1069e4b7b43b87e20017368583/models/user/user.go#L1172 https://github.com/go-gitea/gitea/blob/c6467edcb1543a1069e4b7b43b87e20017368583/models/user/user.go#L1225 * Get committer email from git commit * Search it from `email_address` table bye `WHERE lower_email = {git email} AND is_active=true`, then get related users * The code is covered by some tests and is tested on gitea.com and by some other users (well, maybe no LDAP was involved) So without a reproduce sample, it's difficult for me to figure out what happens .... Are you able to provide more clues, or a reproducible setup?
GiteaMirror commented 2025-11-02 11:19:31 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jun 27, 2025):

In some cases this link creation works - if the user misconfigured his git email address to lastname@company.bla instead of firstname.lastname@company.bla.

That's the most strange part. It shows that the GetUsersByEmails/GetUserByEmail does do their work.

So need to figure out why firstname.lastname@company.bla is different. Where it mismatches? (if you are surely using 1.24)

@wxiaoguang commented on GitHub (Jun 27, 2025): > In some cases this link creation works - if the user misconfigured his git email address to `lastname@company.bla` instead of `firstname.lastname@company.bla`. That's the most strange part. It shows that the GetUsersByEmails/GetUserByEmail does do their work. So need to figure out why `firstname.lastname@company.bla` is different. Where it mismatches? (if you are surely using 1.24)
GiteaMirror commented 2025-11-02 11:19:31 -06:00
Author
Owner
Copy Link

@smartEBL commented on GitHub (Jun 27, 2025):

(if you are surely using 1.24)

Yes, it's 1.24.2 for sure.

Maybe the fact that the generated link which should point to the user page contains Firstname Lastname (db field full_name) instead of lastname (db field lower_name) might be a hint.

So instead of
http://gitea:3000/Firstname Lastname (what we see right now)
we would expect
http://gitea:3000/lastname

fyi: We did the migration from 1.23.8 to 1.24.2 in the morning - maybe something went wrong there also?

@smartEBL commented on GitHub (Jun 27, 2025): > (if you are surely using 1.24) Yes, it's 1.24.2 for sure. Maybe the fact that the generated link which should point to the user page contains `Firstname Lastname` (db field `full_name`) instead of `lastname` (db field `lower_name`) might be a hint. So instead of `http://gitea:3000/Firstname Lastname` (what we see right now) we would expect `http://gitea:3000/lastname` fyi: We did the migration from 1.23.8 to 1.24.2 in the morning - maybe something went wrong there also?
GiteaMirror commented 2025-11-02 11:19:31 -06:00
Author
Owner
Copy Link

@hiifong commented on GitHub (Jun 27, 2025):

Please use git config --global --list to check if the email address matches the one on gitea.

@hiifong commented on GitHub (Jun 27, 2025): Please use `git config --global --list` to check if the email address matches the one on gitea.
GiteaMirror commented 2025-11-02 11:19:31 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jun 27, 2025):

Maybe the fact that the generated link which should point to the user page contains Firstname Lastname (db field full_name) instead of lastname (db field lower_name) might be a hint.

I don't think it is the case.

The details are:

  • Git commit contains git user and git email (provided by each user)
  • Gitea has user's gitea_username and gitea_email

Gitea needs to use git email to find a related Gitea user by its gitea_email, and render the link http://gitea-host/{gitea_username}. If it can't find the Gitea user by git email, then it renders the link as http://gitea-host/{git user}

@wxiaoguang commented on GitHub (Jun 27, 2025): > Maybe the fact that the generated link which should point to the user page contains `Firstname Lastname` (db field `full_name`) instead of `lastname` (db field `lower_name`) might be a hint. I don't think it is the case. The details are: * Git commit contains `git user` and `git email` (provided by each user) * Gitea has user's `gitea_username` and `gitea_email` Gitea needs to use `git email` to find a related Gitea user by its `gitea_email`, and render the link `http://gitea-host/{gitea_username}`. If it can't find the Gitea user by `git email`, then it renders the link as `http://gitea-host/{git user}`
GiteaMirror commented 2025-11-02 11:19:32 -06:00
Author
Owner
Copy Link

@smartYSC commented on GitHub (Jun 27, 2025):

We figured it out (I'm the colleague of @smartEBL):

In our config NO_REPLY_ADDRESS is set to company.bla.

GetUsersByEmails() check if the git email ends with @NO_REPLY_ADDRESS:

c6467edcb1/models/user/user.go (L1180-L1183)

This is true for all our users.

It then decides to check the user name instead of the email address:

c6467edcb1/models/user/user.go (L1215-L1217)

This finds no results.

Afterwards some other piece of code I have not found yet decides to use the git user in the commit list, which is similar to the behaviour of v1.23. However, it creates a link to the git user which I think it should not do (and did not do in v1.23).

We now changed NO_REPLY_ADDRESS to noreply.company.bla. And the commit list is fixed.

So our issue is resolved.

@smartYSC commented on GitHub (Jun 27, 2025): We figured it out (I'm the colleague of @smartEBL): In our config `NO_REPLY_ADDRESS` is set to `company.bla`. `GetUsersByEmails()` check if the `git email` ends with `@NO_REPLY_ADDRESS`: https://github.com/go-gitea/gitea/blob/c6467edcb1543a1069e4b7b43b87e20017368583/models/user/user.go#L1180-L1183 This is true for all our users. It then decides to check the user name instead of the email address: https://github.com/go-gitea/gitea/blob/c6467edcb1543a1069e4b7b43b87e20017368583/models/user/user.go#L1215-L1217 This finds no results. Afterwards some other piece of code I have not found yet decides to use the `git user` in the commit list, which is similar to the behaviour of v1.23. However, it creates a `link` to the `git user` which I think it should not do (and did not do in v1.23). We now changed `NO_REPLY_ADDRESS` to `noreply.company.bla`. And the commit list is fixed. So our issue is resolved.
GiteaMirror commented 2025-11-02 11:19:32 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jun 27, 2025):

Awesome, it explains everything, thank you very much.

However, it creates a link to the git user which I think it should not do (and did not do in v1.23).

I think the root problem is the changed behavior (regression) caused by Improve commits list performance to reduce unnecessary database queries (#33528) also cc @lunny

@wxiaoguang commented on GitHub (Jun 27, 2025): Awesome, it explains everything, thank you very much. > However, it creates a `link` to the `git user` which I think it should not do (and did not do in v1.23). I think the root problem is the changed behavior (regression) caused by Improve commits list performance to reduce unnecessary database queries (#33528) also cc @lunny
GiteaMirror commented 2025-11-02 11:19:32 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jul 8, 2025):

The logic for checking no-reply addresses was introduced in #7133 to address issue #2457. Pull request #33528 builds on this by performing the check in batch, rather than individually.

To help prevent misconfiguration, we should consider adding a comment to the [service].NO_REPLY_ADDRESS setting, clarifying that it must be a fake domain—one that no real user would ever use as their actual email address.

@lunny commented on GitHub (Jul 8, 2025): The logic for checking no-reply addresses was introduced in #7133 to address issue #2457. Pull request #33528 builds on this by performing the check in batch, rather than individually. To help prevent misconfiguration, we should consider adding a comment to the `[service].NO_REPLY_ADDRESS` setting, clarifying that it must be a fake domain—one that no real user would ever use as their actual email address.
GiteaMirror commented 2025-11-02 11:19:33 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 9, 2025):

The logic for checking no-reply addresses was introduced in https://github.com/go-gitea/gitea/pull/7133 to address issue https://github.com/go-gitea/gitea/issues/2457. Pull request https://github.com/go-gitea/gitea/pull/33528 builds on this by performing the check in batch, rather than individually.

But #33528 did introduce a regression, it changed the check logic. I think you should be able to reproduce and see the difference between 1.23 and 1.24

@wxiaoguang commented on GitHub (Jul 9, 2025): > The logic for checking no-reply addresses was introduced in https://github.com/go-gitea/gitea/pull/7133 to address issue https://github.com/go-gitea/gitea/issues/2457. Pull request https://github.com/go-gitea/gitea/pull/33528 builds on this by performing the check in batch, rather than individually. But #33528 did introduce a regression, it changed the check logic. I think you should be able to reproduce and see the difference between 1.23 and 1.24
GiteaMirror commented 2025-11-02 11:19:33 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Jul 9, 2025):

I sent #35007 to try to fix the regression.

@lunny commented on GitHub (Jul 9, 2025): I sent #35007 to try to fix the regression.
GiteaMirror commented 2025-11-02 11:19:33 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Jul 9, 2025):

I sent #35007 to try to fix the regression.

35007 doesn't contain the fix.

To fix, you need to "always" try to the commit's email to load a user, no matter it ends with "no reply address" or not.

@wxiaoguang commented on GitHub (Jul 9, 2025): > I sent [#35007](https://github.com/go-gitea/gitea/pull/35007) to try to fix the regression. 35007 doesn't contain the fix. To fix, you need to "always" try to the commit's email to load a user, no matter it ends with "no reply address" or not.
GiteaMirror commented 2025-11-02 11:19:33 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 10, 2025):

In our config NO_REPLY_ADDRESS is set to company.bla.

Funnily enough, I made the exact same error in my instance configuration. My config is very old (inherited from gogs) and I assume that maybe at some point NO_REPLY_ADDRESS must have been documented to hold a "regular" domain name, not a fake one.

@silverwind commented on GitHub (Jul 10, 2025): > In our config NO_REPLY_ADDRESS is set to company.bla. Funnily enough, I made the exact same error in my instance configuration. My config is very old (inherited from gogs) and I assume that maybe at some point NO_REPLY_ADDRESS must have been documented to hold a "regular" domain name, not a fake one.
GiteaMirror commented 2025-11-02 11:19:33 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 10, 2025):

In our config NO_REPLY_ADDRESS is set to company.bla.

Funnily enough, I made the exact same error in my instance configuration. My config is very old (inherited from gogs) and I assume that maybe at some point NO_REPLY_ADDRESS must have been documented to hold a "regular" domain name, not a fake one.

Actually no, my config was always incorrect, here is where NO_REPLY_ADRESS was first added, and it was always with the "noreply." prefix.

@silverwind commented on GitHub (Jul 10, 2025): > > In our config NO_REPLY_ADDRESS is set to company.bla. > > Funnily enough, I made the exact same error in my instance configuration. My config is very old (inherited from gogs) and I assume that maybe at some point NO_REPLY_ADDRESS must have been documented to hold a "regular" domain name, not a fake one. Actually no, my config was always incorrect, [here](https://github.com/go-gitea/gitea/commit/51d578ff3321e173b0dae4c80d3031fb0492656d#diff-2711c6ed235dd002d3db831f513006c4215c99e4f5109c750b0b69a0f97559b3R197-R199) is where NO_REPLY_ADRESS was first added, and it was always with the "noreply." prefix.
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 issue/workaround type/bug
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#14668
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?