Upgraded To Latest; Avatars Broken #5722

New Issue

GiteaMirror · 2025-11-02T06:34:01-06:00

GiteaMirror commented

2025-11-02 06:34:01 -06:00

Originally created by @atom0s on GitHub (Jul 11, 2020).

Gitea version (or commit ref): 1.12.1 (Current download from the main site.)
Git version: 2.27.0
Operating system: Windows Server 2012 R2
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: Not relevant.

Description

Upon upgrading to latest Gitea from 1.9.x, avatars are now broken by default. User avatars are now defaulted to:

https://<website_url>/user/avatar/<username>/<user_avatar_id>

However, these do not resolve to anything and thus show a dead image. Manually attempting to go to this link does redirect to:

http://<website_url>/img/avatar_default.png

But, there are two issues here.

The redirect is going to HTTP and not HTTPS.
The redirect is not happening when looking up the avatar to be displayed anywhere on the site.

Every user has to update their avatar now to fix the issue. This appears to be a redirect and protocol de-elevation issue.

Originally created by @atom0s on GitHub (Jul 11, 2020). - **Gitea version (or commit ref):** 1.12.1 (Current download from the main site.) - **Git version:** 2.27.0 - **Operating system:** Windows Server 2012 R2 - **Database (use `[x]`):** - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - **Log gist:** Not relevant. ## Description Upon upgrading to latest Gitea from 1.9.x, avatars are now broken by default. User avatars are now defaulted to: ``` https://<website_url>/user/avatar/<username>/<user_avatar_id> ``` However, these do not resolve to anything and thus show a dead image. Manually attempting to go to this link does redirect to: ``` http://<website_url>/img/avatar_default.png ``` But, there are two issues here. 1. The redirect is going to HTTP and not HTTPS. 2. The redirect is not happening when looking up the avatar to be displayed anywhere on the site. Every user has to update their avatar now to fix the issue. This appears to be a redirect and protocol de-elevation issue.

GiteaMirror added the type/bug label 2025-11-02 06:34:01 -06:00

GiteaMirror closed this issue

2025-11-02 06:34:01 -06:00

GiteaMirror commented

2025-11-02 06:34:02 -06:00

@atom0s commented on GitHub (Jul 11, 2020):

Also noticed that this does not seem to be consistent across the site. On the main repo list page, avatars are linked to:

<img class="ui avatar image" src="/user/avatar/<USERNAME>/-1" alt="">

Which fail to load, again due to the site attempting to redirect to HTTP for the default avatar.

Next, if I go to a user profile page that has a broken avatar, that page fails to display the avatar and is linked as:

<img src="/user/avatar/<USERNAME>/290" title="<USERNAME>">

Also fails and is attempting to redirect to HTTP.

Along with this, any profile page that has a broken avatar will attempt to redirect the entire site to HTTP. If you refresh/force-refresh (CTRL+F5) on a broken avatar profile page, the site is redirected to HTTP instead. This does not happen when the profile has a valid avatar though.

This seems to happen when there is any broken resource on the page. Very odd that Gitea is trying to de-elevate to HTTP like this.

@atom0s commented on GitHub (Jul 11, 2020): Also noticed that this does not seem to be consistent across the site. On the main repo list page, avatars are linked to: ``` <img class="ui avatar image" src="/user/avatar/<USERNAME>/-1" alt=""> ``` Which fail to load, again due to the site attempting to redirect to HTTP for the default avatar. Next, if I go to a user profile page that has a broken avatar, that page fails to display the avatar and is linked as: ``` <img src="/user/avatar/<USERNAME>/290" title="<USERNAME>"> ``` Also fails and is attempting to redirect to HTTP. Along with this, any profile page that has a broken avatar will attempt to redirect the entire site to HTTP. If you refresh/force-refresh (CTRL+F5) on a broken avatar profile page, the site is redirected to HTTP instead. This does not happen when the profile has a valid avatar though. This seems to happen when there is any broken resource on the page. Very odd that Gitea is trying to de-elevate to HTTP like this.

GiteaMirror commented

2025-11-02 06:34:02 -06:00

@lunny commented on GitHub (Jul 12, 2020):

Which page did you found that broken image?

@lunny commented on GitHub (Jul 12, 2020): Which page did you found that broken image?

GiteaMirror commented

2025-11-02 06:34:02 -06:00

@atom0s commented on GitHub (Jul 12, 2020):

Every single page that an avatar is referenced/used.

For example:

The main dashboard.
User profile pages.
Repository root pages that show commit information.
Commit pages specifically.

@atom0s commented on GitHub (Jul 12, 2020): Every single page that an avatar is referenced/used. For example: - The main dashboard. - User profile pages. - Repository root pages that show commit information. - Commit pages specifically.

GiteaMirror commented

2025-11-02 06:34:02 -06:00

@atom0s commented on GitHub (Jul 14, 2020):

I was able to fix this and found the cause. Was due to Cloudflare and some of their SSL settings.

Here is a rundown of what to adjust/fix in case others run into this issue while using Gitea via IIS behind Cloudflare.

Log into Cloudflare and select the domain that your Git server is hosted behind.
Select the 'SSL/TLS' options tab for the site.
- Change the encryption mode to 'Full'.
Select the 'SSL/TLS' > 'Edge Certificates' option for the site.
- Change the 'Always Use HTTPS' to 'On'.
- Change the 'Automatic HTTPS Rewrites' to 'On'.
- Optional: Turn 'Minimum TLS Version' up to your desired security level. (1.0 Default is fine.)
- Optional: Turn 'Opportunistic Encryption' to 'On'. (Recommended to be on anyway.)
- Optional: Turn 'TLS 1.3' to 'On'. (Recommended to be on anyway.)

If you need to work with custom certificates and such, you should do that now as well at this point. Settings and setups for that will vary, so you will need to do that part yourself.

After your setup is done, then you should purge your site's entire cache on Cloudflare. You can do that via:
'Caching' > 'Configuration' > 'Purge Cache' - Purge Everything

@atom0s commented on GitHub (Jul 14, 2020): I was able to fix this and found the cause. Was due to Cloudflare and some of their SSL settings. Here is a rundown of what to adjust/fix in case others run into this issue while using Gitea via IIS behind Cloudflare. - Log into Cloudflare and select the domain that your Git server is hosted behind. - Select the 'SSL/TLS' options tab for the site. - Change the encryption mode to 'Full'. - Select the 'SSL/TLS' > 'Edge Certificates' option for the site. - Change the 'Always Use HTTPS' to 'On'. - Change the 'Automatic HTTPS Rewrites' to 'On'. - Optional: Turn 'Minimum TLS Version' up to your desired security level. (1.0 Default is fine.) - Optional: Turn 'Opportunistic Encryption' to 'On'. (Recommended to be on anyway.) - Optional: Turn 'TLS 1.3' to 'On'. (Recommended to be on anyway.) If you need to work with custom certificates and such, you should do that now as well at this point. Settings and setups for that will vary, so you will need to do that part yourself. After your setup is done, then you should purge your site's entire cache on Cloudflare. You can do that via: 'Caching' > 'Configuration' > 'Purge Cache' - Purge Everything

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#5722