New Field Request: Ability to set Profile Pic with LDAP #1871

@mq2035 commented on GitHub (Mar 14, 2019):

In openldap attribute name is jpegPhoto (from inetOrgPerson), it is binary and it is stored in LDAP.

working code example (in java)
https://github.com/xwiki-contrib/ldap/tree/master/ldap-authenticator

@mq2035 commented on GitHub (Mar 14, 2019): In openldap attribute name is jpegPhoto (from inetOrgPerson), it is binary and it is stored in LDAP. working code example (in java) https://github.com/xwiki-contrib/ldap/tree/master/ldap-authenticator

GiteaMirror commented

@dl5rcw commented on GitHub (Jan 18, 2020):

Using fusiondirectory, the jpegPhoto as mentioned by @mq2035 really makes sense. It should be updated like the other entries to pull changes from ldap.

@dl5rcw commented on GitHub (Jan 18, 2020): Using fusiondirectory, the jpegPhoto as mentioned by @mq2035 really makes sense. It should be updated like the other entries to pull changes from ldap.

GiteaMirror commented

@helmut72 commented on GitHub (Feb 12, 2020):

Yes, would be good, as I have stored jpegPhoto in my Samba4/LDAP server. Many Applications use the photo from LDAP server, which makes sense.

@helmut72 commented on GitHub (Feb 12, 2020): Yes, would be good, as I have stored jpegPhoto in my Samba4/LDAP server. Many Applications use the photo from LDAP server, which makes sense.

GiteaMirror commented

@lafriks commented on GitHub (Feb 12, 2020):

Only problem could be with sync, how to check and download images only if they have been changed to not download all user images on every sync

@lafriks commented on GitHub (Feb 12, 2020): Only problem could be with sync, how to check and download images only if they have been changed to not download all user images on every sync

GiteaMirror commented

2025-11-02 04:16:00 -06:00

@benyanke commented on GitHub (Feb 13, 2020):

That would be an additional piece needed. Most apps I've seen do it on individual login, and then refetch on an administrator's cache clear, or when a scheduled job runs. Ideally it's something you could cache a day or two, since pictures don't change often, especially if you're updating on the login event.

@benyanke commented on GitHub (Feb 13, 2020): That would be an additional piece needed. Most apps I've seen do it on individual login, and then refetch on an administrator's cache clear, or when a scheduled job runs. Ideally it's something you could cache a day or two, since pictures don't change often, especially if you're updating on the login event.

GiteaMirror commented

@helmut72 commented on GitHub (Feb 19, 2020):

Only problem could be with sync, how to check and download images only if they have been changed to not download all user images on every sync

Let the user decide in his settings.

@helmut72 commented on GitHub (Feb 19, 2020): > Only problem could be with sync, how to check and download images only if they have been changed to not download all user images on every sync Let the user decide in his settings.

GiteaMirror commented

2025-11-02 04:16:00 -06:00

@lafriks commented on GitHub (Feb 19, 2020):

I was just thinking if there is more optimal way to check if image has changed

@lafriks commented on GitHub (Feb 19, 2020): I was just thinking if there is more optimal way to check if image has changed

GiteaMirror commented

2025-11-02 04:16:00 -06:00

@helmut72 commented on GitHub (Sep 1, 2020):

It would be a good start if there is just a sync every x day/hour setting with 0 to disable. Then it's the administrators choice. Better than no ldap photo sync.

@helmut72 commented on GitHub (Sep 1, 2020): It would be a good start if there is just a `sync every x day/hour` setting with 0 to disable. Then it's the administrators choice. Better than no ldap photo sync.

GiteaMirror commented

2025-11-02 04:16:01 -06:00

@nedvedad commented on GitHub (Feb 10, 2021):

Or check/download avatar on each user login.

@nedvedad commented on GitHub (Feb 10, 2021): Or check/download avatar on each user login.

GiteaMirror commented

2025-11-02 04:16:01 -06:00

@SonGokussj4 commented on GitHub (Aug 26, 2021):

Any progress with this? I just got LDAP to work after days of fighting with it but no pictures sadly.

@SonGokussj4 commented on GitHub (Aug 26, 2021): Any progress with this? I just got LDAP to work after days of fighting with it but no pictures sadly.

GiteaMirror commented

2025-11-02 04:16:01 -06:00

@zeripath commented on GitHub (Aug 27, 2021):

I have put up a PR. It could do with some testing from people with working LDAPs.

@zeripath commented on GitHub (Aug 27, 2021): I have put up a PR. It could do with some testing from people with working LDAPs.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 1, 2021):

Any chance for me to try that in Docker? I'm using v1.15.0 docker image. (centos 7) Can't try this as local installation.

@SonGokussj4 commented on GitHub (Sep 1, 2021): Any chance for me to try that in Docker? I'm using v1.15.0 docker image. (centos 7) Can't try this as local installation.

GiteaMirror commented

https://www.eldritchkitty.com/~andrew/gitea-1.16.0-dev-195-pr-16851.tar.gz

@zeripath commented on GitHub (Sep 1, 2021):

OK I've pushed up a docker image based on 1.16 (v1.16.0-dev-195-gd01836f4f) - this PR can't be backported to 1.15 without significant work (and as it would be a feature would be unlikely to be merged.)

if the image needs updating please discuss with me on discord or matrix. Similarly if a backport to 1.15 is wanted.

@zeripath commented on GitHub (Sep 1, 2021): OK I've pushed up a docker image based on 1.16 (v1.16.0-dev-195-gd01836f4f) - this PR can't be backported to 1.15 without significant work (and as it would be a feature would be unlikely to be merged.) https://www.eldritchkitty.com/~andrew/gitea-1.16.0-dev-195-pr-16851.tar.gz if the image needs updating please discuss with me on discord or matrix. Similarly if a backport to 1.15 is wanted.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 2, 2021):

Okay so if I want to just try that and then go back I should not just rename image in docker-compose.yml from gitea:1.15 to gitea:1.16-dev (as I renamed your docker) (and there back to 1.15)

I should stop my current Gitea instance, copy folder with data and try your docker image on that?

@SonGokussj4 commented on GitHub (Sep 2, 2021): Okay so if I want to just try that and then go back I should **not** just rename image in docker-compose.yml from gitea:1.15 to gitea:1.16-dev (as I renamed your docker) (and there back to 1.15) I should stop my current Gitea instance, copy folder with data and try your docker image on that?

GiteaMirror commented

@zeripath commented on GitHub (Sep 2, 2021):

Ah you want to use your current data!

You would need to backup or copy your db as there are some database migrations.

(There's a small bug in 1.15.0 dump which will break login_source so you would need to use your db backups or wait for 1.15.1 - which is imminent)

@zeripath commented on GitHub (Sep 2, 2021): Ah you want to use your current data! You would need to backup or copy your db as there are some database migrations. (There's a small bug in 1.15.0 dump which will break login_source so you would need to use your db backups or wait for 1.15.1 - which is imminent)

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 2, 2021):

I would try that in production in my company so... To be safe, I will wait :-) So when 1.15.1 is out, I will update to that, then try to use your 1.16.0-dev, report functionality, then I can go back to 1.15.1?

@SonGokussj4 commented on GitHub (Sep 2, 2021): I would try that in production in my company so... To be safe, I will wait :-) So when 1.15.1 is out, I will update to that, then try to use your 1.16.0-dev, report functionality, then I can go back to 1.15.1?

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 3, 2021):

1.15.1 here. Should I wait for your docker build and go back to 1.15.1 after I try it? Or I have to duplicate my environment and try that on duplicated DB to be sure.

@SonGokussj4 commented on GitHub (Sep 3, 2021): 1.15.1 here. Should I wait for your docker build and go back to 1.15.1 after I try it? Or I have to duplicate my environment and try that on duplicated DB to be sure.

GiteaMirror commented

@zeripath commented on GitHub (Sep 3, 2021):

You will need to back up your db, duplicate it and use the image I provided above.

The reason is that once you use a 1.16-dev build your db is migrated and so you would not be a able to go back to 1.15.

@zeripath commented on GitHub (Sep 3, 2021): You will need to back up your db, duplicate it and use the image I provided above. The reason is that once you use a 1.16-dev build your db is migrated and so you would not be a able to go back to 1.15.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 6, 2021):

Finally at work. Did try your image but error happened. Are you sure (did you try it?) it works?

# I've imported your image
docker import https://www.eldritchkitty.com/~andrew/gitea-1.16.0-dev-195-pr-16851.tar.gz

# Renamed
docker image tag b63236d14157 gitea/gitea:1.16.0-dev

# Modified docker-compose.yml
services:
  server:
    image: gitea/gitea:1.16.0-dev

# Started
$ docker-compose up
gitea_ldap_test_db_1 is up-to-date
Creating gitea_ldap_test_server_1 ... error

ERROR: for gitea_ldap_test_server_1  Cannot create container for service server: b'No command specified'

ERROR: for server  Cannot create container for service server: b'No command specified'
ERROR: Encountered errors while bringing up the project.

@SonGokussj4 commented on GitHub (Sep 6, 2021): Finally at work. Did try your image but error happened. Are you sure (did you try it?) it works? ``` # I've imported your image docker import https://www.eldritchkitty.com/~andrew/gitea-1.16.0-dev-195-pr-16851.tar.gz # Renamed docker image tag b63236d14157 gitea/gitea:1.16.0-dev # Modified docker-compose.yml services: server: image: gitea/gitea:1.16.0-dev # Started $ docker-compose up gitea_ldap_test_db_1 is up-to-date Creating gitea_ldap_test_server_1 ... error ERROR: for gitea_ldap_test_server_1 Cannot create container for service server: b'No command specified' ERROR: for server Cannot create container for service server: b'No command specified' ERROR: Encountered errors while bringing up the project. ```

GiteaMirror commented

@zeripath commented on GitHub (Sep 6, 2021):

Sigh.

Works for me.

Not being a docker expert I don't know how to fix this or why it has occurred - at worst the image will contain a gitea binary which at worst you can copy over another image.

@zeripath commented on GitHub (Sep 6, 2021): Sigh. Works for me. Not being a docker expert I don't know how to fix this or why it has occurred - at worst the image will contain a gitea binary which at worst you can copy over another image.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 7, 2021):

Docker inspect gitea/gitea:1.16.0-dev, it will give me {"Config": {"Cmd": null, ...}, ...}
When I googled the problem it gave me "you have no Cmd in dockerfile".

Edit: after inspecting original 1.15 image, it is way too different. So my thoughts are it was not built correctly.

@SonGokussj4 commented on GitHub (Sep 7, 2021): Docker inspect gitea/gitea:1.16.0-dev, it will give me {"Config": {"Cmd": null, ...}, ...} When I googled the problem it gave me "you have no Cmd in dockerfile". Edit: after inspecting original 1.15 image, it is way too different. So my thoughts are it was not built correctly.

GiteaMirror commented

@zeripath commented on GitHub (Sep 8, 2021):

It'll be the way it was exported. Clearly docker export did not work and is not the correct thing to do. I'm not certain how to make that work properly.

~~~I have pushed up an xz compressed binary to https://www.eldritchkitty.com/~~andrew/gitea-v1.16.0-dev-219-g4b6e023a1-pr-16851-linux-amd64.xz~~~~ which once decompressed you can use to replace the /app/gitea/gitea binary within a working docker.

@zeripath commented on GitHub (Sep 8, 2021): It'll be the way it was exported. Clearly `docker export` did not work and is not the correct thing to do. I'm not certain how to make that work properly. ~~I have pushed up an xz compressed binary to https://www.eldritchkitty.com/~andrew/gitea-v1.16.0-dev-219-g4b6e023a1-pr-16851-linux-amd64.xz~~ which once decompressed you can use to replace the /app/gitea/gitea binary within a working docker.

GiteaMirror commented

https://i.imgur.com/zA2LxYh.png

@SonGokussj4 commented on GitHub (Sep 8, 2021):

Thanks. I copied it to a running container and there is a new field "Avatar Attribute" and entered "thumbnailPhoto"

My ldapsearch -x -W -D xxx shows:

mail: mymail@MYCOMPANY.CZ
mobile: +420123456789
thumbnailPhoto:: /9j/4AAQSkZJRgABAQEA8ADwAAD/4R1kRXhpZgAATU0AKgAAAAgACwEPAAIAA
 AASAAAAkgEQAAIAAAAKAAAApAEaAAUAAAABAAAArgEbAAUAAAABAAAAtgEoAAMAAAABAAIAAAExAA
...

Updated Authentication Source.
Tried logout, login
Tried Admin --> Monitoring --> Synchronize external user data
Tried to change from User Profile --> Avatar --> Look Up Avatar by Email Address to Use Custom Avatar and back

Still the random avatar. What should I do so that it will pull it out from LDAP?

@SonGokussj4 commented on GitHub (Sep 8, 2021): Thanks. I copied it to a running container and there is a new field "Avatar Attribute" and entered "thumbnailPhoto" My `ldapsearch -x -W -D xxx` shows: ``` mail: mymail@MYCOMPANY.CZ mobile: +420123456789 thumbnailPhoto:: /9j/4AAQSkZJRgABAQEA8ADwAAD/4R1kRXhpZgAATU0AKgAAAAgACwEPAAIAA AASAAAAkgEQAAIAAAAKAAAApAEaAAUAAAABAAAArgEbAAUAAAABAAAAtgEoAAMAAAABAAIAAAExAA ... ``` - Updated Authentication Source. - Tried logout, login - Tried `Admin --> Monitoring --> Synchronize external user data` - Tried to change from `User Profile --> Avatar --> Look Up Avatar by Email Address` to `Use Custom Avatar` and back Still the random avatar. What should I do so that it will pull it out from LDAP? https://i.imgur.com/zA2LxYh.png

GiteaMirror commented

@zeripath commented on GitHub (Sep 8, 2021):

hmm... the avatar was only being updated if something else was updated on the user - I've changed that.

The other question is whether your ldap is giving us the data as []byte or as a base64 encoded string. If it's the latter then it's not currently handling that.

~~~https://www.eldritchkitty.com/~~andrew/gitea-v1.16.0-dev-225-g929885e0c-pr-16851-linux-amd64.xz~~~~

@zeripath commented on GitHub (Sep 8, 2021): hmm... the avatar was only being updated if something else was updated on the user - I've changed that. The other question is whether your ldap is giving us the data as []byte or as a base64 encoded string. If it's the latter then it's not currently handling that. ~~https://www.eldritchkitty.com/~andrew/gitea-v1.16.0-dev-225-g929885e0c-pr-16851-linux-amd64.xz~~

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 8, 2021):

If I enter my thumbnailPhoto into https://codebeautify.org/base64-to-image-converter, it gives me my picture. So I think (and I can't change that) it's base64.

@SonGokussj4 commented on GitHub (Sep 8, 2021): If I enter my `thumbnailPhoto` into https://codebeautify.org/base64-to-image-converter, it gives me my picture. So I think (and I can't change that) it's base64.

GiteaMirror commented

@zeripath commented on GitHub (Sep 10, 2021):

@SonGokussj4 did you try the update above?

@zeripath commented on GitHub (Sep 10, 2021): @SonGokussj4 did you try the update above?

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 13, 2021):

Hi. No I didn't. We use base64 for image and you wrote it doesn't handle the base64 so I didn't even try.

@SonGokussj4 commented on GitHub (Sep 13, 2021): Hi. No I didn't. We use base64 for image and you wrote it doesn't handle the base64 so I didn't even try.

GiteaMirror commented

@zeripath commented on GitHub (Sep 13, 2021):

I don't think you can assume that you're using base64 from that output. If you look at your output above:

thumbnailPhoto:: /9j/4AAQSkZJRgABAQEA8ADwAAD/4R1kRXhpZgAATU0AKgAAAAgACwEPAAIAA
 AASAAAAkgEQAAIAAAAKAAAApAEaAAUAAAABAAAArgEbAAUAAAABAAAAtgEoAAMAAAABAAIAAAExAA
...

There is a double : after the field's name. That could imply that the object is stored as []byte but it's being rendered as base64. My code explicitly asks for the bytes. Now you were previously expecting synchronization to occur - it wasn't because of an oversight - but it does happen now. So it would be helpful to know if my interpretation above is correct or if I have to read the data and detect it's base64 and then do a conversion.

Because if I have to convert for you - it is very likely that there will have to be conversions for others.

If I don't then that's fine and I can save 200 lines of code messing around with dealing with this issue.

@zeripath commented on GitHub (Sep 13, 2021): I don't think you can assume that you're using base64 from that output. If you look at your output above: ``` thumbnailPhoto:: /9j/4AAQSkZJRgABAQEA8ADwAAD/4R1kRXhpZgAATU0AKgAAAAgACwEPAAIAA AASAAAAkgEQAAIAAAAKAAAApAEaAAUAAAABAAAArgEbAAUAAAABAAAAtgEoAAMAAAABAAIAAAExAA ... ``` There is a double `:` after the field's name. That could imply that the object is stored as []byte but it's being rendered as base64. My code explicitly asks for the bytes. Now you were previously expecting synchronization to occur - it wasn't because of an oversight - but it does happen now. So it would be helpful to know if my interpretation above is correct or if I have to read the data and detect it's base64 and then do a conversion. Because if I have to convert for you - it is very likely that there will have to be conversions for others. If I don't then that's fine and I can save 200 lines of code messing around with dealing with this issue.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 13, 2021):

That makes sense. Thanks for the explanation.
I'll try that right away.

@SonGokussj4 commented on GitHub (Sep 13, 2021): That makes sense. Thanks for the explanation. I'll try that right away.

GiteaMirror commented

@SonGokussj4 commented on GitHub (Sep 14, 2021):

So I updated the file, restarted gitea docker-compose restart, entered thumbnailPhoto, then tried log-out, log-in, synchronize data, nothing.
Then I downed docker docker-compose down and started it again docker-compose up -d, logs show me this:

server_1  | Downgrading database version from '194' to '189' is not supported and may result in loss of data integrity.
server_1  | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;`
server_1  | Received signal 15; terminating.
gitea_ldap_test_server_1 exited with code 0

Edit:
Ignore the above. I repeated the copying (I forgot that when I d-c down my container, it will replace all default files...)
I filled the Avatar Attribute field but nothing happens.
Interesting enough, I couldn't log back in.
The log was:

Completed POST /user/login 500 Internal Server Error

Not sure what's happening.

@SonGokussj4 commented on GitHub (Sep 14, 2021): So I updated the file, restarted gitea `docker-compose restart`, entered `thumbnailPhoto`, then tried log-out, log-in, synchronize data, nothing. **Then** I downed docker `docker-compose down` and started it again `docker-compose up -d`, logs show me this: ``` server_1 | Downgrading database version from '194' to '189' is not supported and may result in loss of data integrity. server_1 | If you really know what you're doing, execute `UPDATE version SET version=189 WHERE id=1;` server_1 | Received signal 15; terminating. gitea_ldap_test_server_1 exited with code 0 ``` Edit: Ignore the above. I repeated the copying (I forgot that when I `d-c down` my container, it will replace all default files...) I filled the `Avatar Attribute` field but nothing happens. Interesting enough, I couldn't log back in. The log was: ``` Completed POST /user/login 500 Internal Server Error ``` Not sure what's happening.

GiteaMirror commented

https://www.eldritchkitty.com/~andrew/gitea-v1.16.0-dev-262-g5f7352645-pr-16851-linux-amd64.xz

@zeripath commented on GitHub (Sep 15, 2021):

OK I think I've got it working completely now! (Discovered our test ldap actually had jpegPhoto attributes already so was able to use that.) I wasn't actually passing the attribute to the LDAP request.

@zeripath commented on GitHub (Sep 15, 2021): OK I think I've got it working completely now! (Discovered our test ldap actually had jpegPhoto attributes already so was able to use that.) I wasn't actually passing the attribute to the LDAP request. https://www.eldritchkitty.com/~andrew/gitea-v1.16.0-dev-262-g5f7352645-pr-16851-linux-amd64.xz

GiteaMirror commented