233144e33e1c90fd799e76ea55236fda661e5ed2
Backport #37588 by @pandareen ## Summary Fixes [go-gitea/gitea#37564](https://github.com/go-gitea/gitea/issues/37564): when an OIDC provider returns a `picture` claim, Gitea is supposed to download that image as the user's avatar (if `[oauth2_client] UPDATE_AVATAR = true`). Two latent bugs prevented this from working consistently: 1. **Default Go User-Agent rejected by some image hosts.** `oauth2UpdateAvatarIfNeed` used `http.Get`, which sends `User-Agent: Go-http-client/1.1`. Hosts like `upload.wikimedia.org` reject that UA with `403`, and every error path silently returned, so the user was left with an identicon and **no log line** to diagnose the issue. 2. **Link-account *register* path skipped avatar sync.** First-time OIDC sign-ins where auto-registration is disabled (or required a username/password retype) go through `LinkAccountPostRegister`, which created the user but never called `oauth2SignInSync`. So the avatar / full name / SSH keys from the IdP were dropped on the floor for those users, even though the existing-account-link path (`oauth2LinkAccount`) and the auto-register path (`handleOAuth2SignIn`) both already did the sync. ## Changes - `routers/web/auth/oauth.go` — `oauth2UpdateAvatarIfNeed` now uses `http.NewRequest` + `http.DefaultClient.Do`, sets `User-Agent: Gitea <version>`, and logs every failure path at `Warn` (invalid URL, fetch error, non-200, body read error, oversize body, upload error). No silent failures. - `routers/web/auth/linkaccount.go` — `LinkAccountPostRegister` now calls `oauth2SignInSync` after a successful user creation, mirroring the auto-register and link-existing-account flows. - `tests/integration/oauth_avatar_test.go` — new `TestOAuth2AvatarFromPicture` integration test with five sub-cases: - `AutoRegister_FetchesAvatarFromPictureWithGiteaUA` — happy path, asserts `use_custom_avatar=true`, an avatar hash is set, exactly one HTTP request was made, and the request carried a `Gitea ` UA. The mock server enforces the UA prefix to mirror real-world hosts that reject Go's default UA. - `AutoRegister_NonOK_DoesNotUpdateAvatar` — server returns 403; user's avatar must remain unset. - `AutoRegister_EmptyPicture_NoFetch` — empty `picture` claim must not trigger any HTTP request. - `AutoRegister_UpdateAvatarFalse_NoFetch` — `UPDATE_AVATAR=false` must not trigger any HTTP request. - `LinkAccountRegister_FetchesAvatarFromPicture` — guards the `linkaccount.go` fix; without the new `oauth2SignInSync` call this assertion fails. ## Test plan - [x] `go test -tags 'sqlite sqlite_unlock_notify' -run '^TestOAuth2AvatarFromPicture$' ./tests/integration/ -v` — 5/5 sub-tests pass. - [x] Manual: log in as a Keycloak user with `picture` claim pointing at `https://avatars.githubusercontent.com/u/9919?v=4` — Gitea avatar is replaced with the GitHub picture. - [x] Manual: same flow with `https://upload.wikimedia.org/...` — request now succeeds (or returns a clearly logged `Warn` line if rate-limited with `429`); previously it silently 403'd. - [x] Manual: `UPDATE_AVATAR=false` — user keeps the identicon, no outbound request in container logs. - [ ] Reviewer: please double-check that no other call sites of `oauth2UpdateAvatarIfNeed` rely on the old `http.Get` behaviour. ## Related - Upstream issue: go-gitea/gitea#37564 -------------------------------------------- AI Editor was used in this PR --------- Signed-off-by: silverwind <me@silverwind.io> Co-authored-by: pandareen <7270563+pandareen@users.noreply.github.com> Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: Claude (Opus 4.7) <noreply@anthropic.com> Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> Co-authored-by: Nicolas <bircni@icloud.com>
fix(auth): set User-Agent on avatar fetch and sync avatar on link-account register (#37564) (#37588) (#37726)
fix(auth): set User-Agent on avatar fetch and sync avatar on link-account register (#37564) (#37588) (#37726)
fix(auth): set User-Agent on avatar fetch and sync avatar on link-account register (#37564) (#37588) (#37726)
Add ability for local makefile with personal customizations that wouldnt affect remote repo (#35836)
…
MokoGitea
Moko fork of Gitea — adding project board REST API endpoints and custom enhancements
Custom Gitea fork with Project Board API
Pages
- Branding
- Deployment
- [Project API](Project API)
- roadmap
Category: Infrastructure | Platform: moko-platform wiki
Documentation
Full documentation is available on the Wiki.
Contributing
See the wiki for development guidelines and contribution instructions.
License
This project is licensed under the GNU General Public License v3.0 or later -- see the LICENSE file.
Description
Moko fork of Gitea — adding project board REST API endpoints and custom enhancements
bitbucketcicddevopsdocker-registry-v2gitgit-guigit-lfsgit-servergiteagithubgithub-actionsgitlabgogolanghacktoberfestmaven-servernpm-registryself-hostedtypescriptvue
Readme
MIT
1 GiB
Releases
33
Languages
Go
78.5%
Handlebars
12.2%
TypeScript
4.4%
CSS
1.9%
JavaScript
1.6%
Other
1.3%