Repository navigation
fix: lowercase the email before hashing the Gravatar URL - #1605
Merged
LinkinStars merged 1 commit intoSep 10, 2026
Merged
Conversation
The Gravatar specification hashes the trimmed, lowercased address. GetAvatarURL only trimmed it, so an account whose stored address contains an uppercase letter hashed to an address Gravatar does not know: the user's avatar was never found and the identicon fallback was rendered instead. selectedAvatar recomputes this URL from the stored address on every response, so this affected both default_avatar: gravatar and an explicit per-user avatar.type: gravatar, and a user could not work around it by re-selecting Gravatar in their profile. Nothing in the backend normalises a stored address, and the external login path copies the provider's address verbatim, so accounts created through an OIDC/OAuth2 connector inherit whatever casing the identity provider sends. The web UI already lowercases before hashing, so the Settings -> Profile preview showed the user's real avatar while every other surface showed an identicon. This removes that disagreement. The hash is computed on read, so existing accounts resolve correctly as soon as this ships. Stored addresses are left untouched. Co-Authored-By: Claude Opus 5 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1604
Proposed Changes
pkg/gravatar.GetAvatarURLbefore hashingit. The Gravatar specification hashes the trimmed, lowercased address; the
function only trimmed, so an account whose stored address contains an
uppercase letter hashed to an address Gravatar does not know and rendered
the identicon fallback instead of the user's avatar.
pkg/gravatar/gravatar_test.gocovering the casing and whitespacevariants of one address, all of which must produce the hash of its
lowercase form.
selectedAvatarrecomputes this URL from the stored address on every response,so this affects both
default_avatar: gravatarand an explicit per-useravatar.type: gravatar— a user cannot work around it by re-selecting Gravatarin their profile. The backend never normalises a stored address, and the
external-login path copies the provider's address verbatim, so accounts created
through an OIDC/OAuth2 connector inherit whatever casing the identity provider
sends.
The web UI already lowercases before hashing
(
ui/src/pages/Users/Settings/Profile/index.tsx), so this also removes afrontend/backend disagreement: the Settings → Profile preview showed the user's
real avatar while every other surface showed an identicon.
No migration is needed. The hash is computed on read, so existing accounts
resolve correctly as soon as this ships; stored addresses are left untouched.