LDAP Vcard fields stored in the db


Allow vCard fields to be stored in the database instead of retrieved from LDAP. A great example is avatars. There should be special syntax in the mapping XML to indicate that a field should be stored in the db.




Maxime Cheramy
December 24, 2007, 11:56 PM

Excuse me if I don't understand perfectly what you've said, my English is not perfect (at all). I'll try to be clear, to be sure.

Yes, it's a good news that using the LDAP authentication now allows us to change the avatar. I didn't use the plugin because i've read someone complains about some images who can make crash the server. So I was waiting for it to be officially integrated to openfire.

I thought that this plugin allowed too to change the vcards' contain.

We use the LDAP for the authentication (each user have an email address identical to their jid) and to complete the vcards with initial values. Users want too to change their nickname and to complete their vcard (phone, address, etc.).
Maybe I didn't understand. Will we be able to do that ?

Daniel Henninger
December 24, 2007, 11:35 PM

I'm confused. It sounds like there's little point in you using LDAP for vcards at all at that point. Likewise, you indicated above that the plugin was doing the trick and you just wished it were integrated with Openfire.

Maxime Cheramy
December 24, 2007, 9:39 PM

If I understand, we're now able to store the avatar in the database using ldap.

So the fix doesn't answer to the feature request. Do we need to open a new ticket for this feature ? Because here for example, we'd liked to be able to override all the vcard's forms. (the ldap contains 4000 entries)

We use a lot the muc and some clients use the vcard for the nickname by default...

Thank you.

Daniel Henninger
December 24, 2007, 8:06 AM

We went with only being able to override avatars. We decided on this after evaluating the performance impacts and security implications of allowing everything to be overridden. Mostly performance... If there is a strong need for expanded functionality, we will evaluate that at a later time.

Gaston Dombiak
October 20, 2007, 4:41 AM


Daniel Henninger