milux / ctldap

LDAP Wrapper for ChurchTools
GNU General Public License v3.0
11 stars 8 forks source link

Profile Picture #6

Open sscholl opened 6 years ago

sscholl commented 6 years ago

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

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

milux commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.