Avatars in LDAP #233

New Issue

2020-11-05T11:51:01Z

raucao commented

2020-11-05 11:51:01 +00:00

Possible, but requires a different object class for users (inetOrgPerson):

https://tools.ietf.org/html/rfc2798#section-2.6

Possible, but requires a different object class for users (`inetOrgPerson`): https://tools.ietf.org/html/rfc2798#section-2.6

raucao added the idea label 2020-11-05 11:51:01 +00:00

raucao added the

service

accounts

label 2020-12-09 13:05:43 +00:00

raucao self-assigned this 2025-05-30 13:30:48 +00:00

greg was assigned by raucao

2025-05-30 13:30:48 +00:00

raucao commented

2025-05-31 11:41:53 +00:00

@greg and I went on a legit wild goose chase for this one.

Long story short: when someone first logs in to Gitea, and they have an avatar set in Akkounts/LDAP, then the avatar (and display name) will be imported from there automatically. Avatars have also been imported for all existing accounts now.

However, if someone logs in to Gitea, does not set an avatar, and then uploads one in akkounts, then it will not be pushed to Gitea, for 2 reasons:

There's currently no admin API for updating avatars from akkounts
We had to turn off the regular LDAP sync task, which would update avatars, so that it doesn't automatically create publicly visible accounts for users who never logged in.

We have also run a query to set the visibility of all users who never logged in to Gitea to "private". Users can change this themselves if they want to. We can also use a similar query later to determine who will have the service enabled already or not.

@greg and I went on a legit wild goose chase for this one. Long story short: when someone first logs in to Gitea, and they have an avatar set in Akkounts/LDAP, then the avatar (and display name) will be imported from there automatically. Avatars have also been imported for all existing accounts now. However, if someone logs in to Gitea, does not set an avatar, and then uploads one in akkounts, then it will not be pushed to Gitea, for 2 reasons: 1. There's currently no admin API for updating avatars from akkounts 2. We had to turn off the regular LDAP sync task, which would update avatars, so that it doesn't automatically create publicly visible accounts for users who never logged in. We have also run a query to set the visibility of all users who never logged in to Gitea to "private". Users can change this themselves if they want to. We can also use a similar query later to determine who will have the service enabled already or not.

raucao commented

2025-05-31 11:44:47 +00:00

Closing this, because it is all finished on the akkounts side, where avatars are now stored properly in the LDAP directory, as well as updated for ejabberd accounts (if they don't have one set yet).

raucao closed this issue

2025-05-31 11:44:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kosmos/chef#233