Profile Picture

[sscholl]

Is it possible, that you add the profile picture as field jpegPhoto ?

Client Example.: https://github.com/RocketChat/Rocket.Chat/issues/2042

[milux]

Good idea. I hope that the picture information is contained in the data that is currently fetched from CT. If not, the CT API might need to be updated, which could require some more time.

Edit: Well, it is not. This feature requires an update of the CT code first. I will see when I have time to do a pull request for this, but please be patient, because this could take a while...

[sscholl]

Thanks for this answer! I was thinking about this further. I think, that the 10 second cache is maybe not enough, because the authentication will be much longer when fetching a picture. But on the other side, it should be updated at login.

What are common sync strategies of the users? I have a sync when the user authenticates and every 1 hour - So I don't need a picture update at authentication time.

[milux]

The profile pictures will not be fetched during authentication. The user information is downloaded as one block, everything else would be horribly inefficient. And it's true... depending on the size of the pictures, we need a much higher retention time for the cache iff we download the pictures in the same step. However, we could mitigate that issue by fetching the images separately. Using the hash of these images as a key, the overhead could be reduced to almost zero. Another more complicated question that recently came to my mind: What's the format of those pictures? What exactly is in this jpegPhoto field? Is it an URL? A base64 representation? Binary data? :thinking:

[sscholl]

It seems like, the base64 representation is already the right solution.

I came across the . Database Creation and Maintenance Tools at http://www.openldap.org/doc/admin23/dbtools.html which outlined 2 methods of storing jpegPhoto (towards the end of the documentation). One using base64 encode and the other using location indicated by URL:

    # Bjorn's Entry
    dn: cn=Bjorn J Jensen,dc=example,dc=com
    cn: Bjorn J Jensen
    cn: Bjorn Jensen
    objectClass: person
    sn: Jensen
    # Base64 encoded JPEG photo
    jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
     A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
     ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG

    # Jennifer's Entry
    dn: cn=Jennifer J Jensen,dc=example,dc=com
    cn: Jennifer J Jensen
    cn: Jennifer Jensen
    objectClass: person
    sn: Jensen
    # JPEG photo from file
    jpegPhoto:< file:///path/to/file.jpeg

Which is the recommended method? Please advise.

I don't understand, they are exactly equivalent; watch it with ethereal. Use whichever is more convenient for your application.

https://www.openldap.org/lists/openldap-software/200612/msg00156.html

[milux]

This refers to LDIF formatting, which is not related to the LDAP library used here... If we're unlucky, it's impossible to insert base64-encoded fields... and file pointers make no sense at all here... for obvious reasons.

[milux]

@sscholl Still any interest in this? While reading the link above (https://www.openldap.org/doc/admin23/dbtools.html), the following came to my attention:

If an <attrvalue> contains non-printing characters or begins with a space, a colon (':'), or a less than ('<'), the <attrdesc> is followed by a double colon and the base64 encoding of the value. For example, the value " begins with a space" would be encoded like this:

        cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=

So, my assumption about the field value was indeed wrong. The LDIF representation looks like that because the binary data of the photo is directly contained within the attribute. That means that, if supported by ctldap, we could simply load a JPEG and place it inside the attribute. However, I do not currently have any use case for this. So if you want to see it, you are welcome to provide a PR. :wink: