[JM-460] LDAP Vcard fields stored in the db Created: 11/Nov/05  Updated: 02/Mar/08  Resolved: 24/Dec/07

Status: Closed
Project: Openfire (ARCHIVED)
Components: Core
Affects versions: 2.3.0 Beta 1
Fix versions: 3.4.3

Type: New Feature Priority: Major
Reporter: MattM Assignee: Daniel Henninger
Resolution: Fixed Votes: 60
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Zip Archive ldapvcardavatar-src.zip     File ldapvcardavatar.jar    

 Description   

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.



 Comments   
Comment by Jason Adolf [ 15/Feb/06 ]

I think this is a great idea as long as it doesn't overwrite information that is automatically populated from LDAP like phone numbers, e-mails, etc. If it simply allows the users to augment information (i.e, we populate the work address from LDAP, user can populate their home info) then I think this would be good.

Comment by Norman Rasmussen [ 28/Apr/06 ]

An alternative is allow binary data to be retrieved from LDAP, and emitted as base64 encoded data. (for jpegPhoto field, etc)

Comment by Álvaro Álvaro [ 27/Jul/06 ]

I think this is the same as http://www.jivesoftware.org/community/message.jspa?messageID=124703#124703 ?
Perhaps this feature requests could be joined ?

Comment by jorge del junglo [ 01/Dec/06 ]

Any idea on when this might be implemented? The stated fix version is just 3.x....

Comment by Allister McNulty [ 03/Jan/07 ]

Any chance of an update as to the scheduling of this one?

TIA!

Comment by MattM [ 20/Feb/07 ]

Hannes Wüthrich contributed a plugin that lets avatars be stored in the database but all other vcard data pulled from LDAP.

I'm thinking about narrowing this issue to be more specific: default to always storing the avatar in the database but all other fields in ldap. This seems to be what most people are looking for and is quick and easy to implement (using Hannes's code).

Is anyone truly interested in mixing and matching between db and LDAP? Or are most people looking for an avatar solution as a first step?

Comment by Keith Conger [ 20/Feb/07 ]

Avatar mapping is all I was looking for.

Comment by Allister McNulty [ 20/Feb/07 ]

I'm happy with avatar mapping too, although the ability to pick and choose what fields are grabbed from the db/directory would be useful (nickname, further personal details, etc)

Comment by Christopher Athans [ 20/Feb/07 ]

I'd like to mix and match for the simple fact that our LDAP may contain information about the user that he/she may not want populated out in his/her V-Card. My vision is that in the Admin/Setup of this plugin, all the V-Card field are listed out and there's a check box that allows the Admin to select which fields can be overridden by the User and Stored in the Database. (By Default, fields are populated from LDAP, then selected fields are updated via DB).

However, avatar mapping is definately something I'd like as well so if you want to release avatar mapping as version 1 of this plugin and then come back to the mix/mapping of fields in the (hopefully) near future, that'd work as well.

Comment by Andy Kress [ 27/Feb/07 ]

Allister makes a good point, but I think that might be better suited for another issue at a future date. I'd like to see support for just the Avatar now....I think it will take care of this specific issue and make most of the people that voted for it happy.

BTW...I installed Hannes' plugin on my test server. Seems to work well. I'm not too excited about using it in production since it replaces the provider and thus will not get code improvments as Wildfire is updated.

Comment by Hannes Wüthrich [ 28/Mar/07 ]

Hi all,

I know, this feature will probably be integrated in openfire soon, but I discovered a serious bug in the current plug-in version. The photo element has not been merged correctly into the ldap vcard - and I think it didn't even work! You can download a fixed version here:

http://www.eyecraft.ch/pub/ldapvcardavatar.jar
http://www.eyecraft.ch/pub/ldapvcardavatar-v1.0.2-src.zip

Make sure you also replace the file plugin-ldapvcardavatar.jar in the lib directory when you upgrade! Sorry for that...

Btw, I was thinking about a configuration interface that allows you to select which fields are read/stored in the db or read from the ldap. The problem is, there is not a fixed set of possible fields in the vcard. A client (other than spark) might want to save more than one business phone number or might even mark an address as home AND business address. The DTD on http://www.xmpp.org/extensions/xep-0054.html allows almost infinite combinations and variations of fields. Because of that, it seems difficult to provide an easy interface, that is able to handle all possible cases as well. If anybody has an idea how to do that, please let me know.

Thanks,
Hannes

Comment by Hannes Wüthrich [ 28/Mar/07 ]

Hi,

I released another version. Please goto http://www.igniterealtime.org/forum/thread.jspa?threadID=25450.

  • Hannes
Comment by Carlos [ 02/Jun/07 ]

an error appears when copy the file plugin-ldapvcardavatar.jar to the directory lib.

It does not allow that Openfire started

db = Oracle
Openfire = 3.3.1

java.lang.NoClassDefFoundError: org/jivesoftware/wildfire/ldap/LdapVCardProvider
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jivesoftware.util.ClassUtils.loadClass(ClassUtils.java:60)
at org.jivesoftware.util.ClassUtils.forName(ClassUtils.java:39)
at org.jivesoftware.openfire.vcard.VCardManager.initialize(VCardManager.java:267)
at org.jivesoftware.openfire.XMPPServer.initModules(XMPPServer.java:503)
at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:396)
at org.jivesoftware.openfire.XMPPServer.<init>(XMPPServer.java:148)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:93)
at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:49)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.exe4j.runtime.WinLauncher$1.run(Unknown Source)
Exception in thread "Thread-1" java.lang.NullPointerException
at org.jivesoftware.openfire.handler.IQOfflineMessagesHandler.stop(IQOfflineMessagesHandler.java:200)
at org.jivesoftware.openfire.XMPPServer.shutdownServer(XMPPServer.java:859)
at org.jivesoftware.openfire.XMPPServer.access$600(XMPPServer.java:90)
at org.jivesoftware.openfire.XMPPServer$ShutdownHookThread.run(XMPPServer.java:811)

Comment by Carlos [ 02/Jun/07 ]

The previous error no longer appears after updating the version

Comment by Todd Getz [ 26/Jul/07 ]

This should not be done. The information in an LDAP server is generally set bay an approved administrator. This insformation should not be altered without approval. If you are going to make this change it should be a separate plugin from the avatars, so we have a choice to use it or not.

Comment by Joe Sherman [ 26/Jul/07 ]

Todd

I think you are not completely understanding this issue... The idea is to allow people to create the vcard with content from different sources (such as an ldap server and the openfire database)... There is no thought of making ldap read/write... As an administrator I would like for my users to be able to use all the features of the vcard with out needing to store the avatar image in the ldap directory... I was hoping that we could make it so openfire would pull all the text data from ldap but the avatar image from the openfire db... This would propably done in the vard mapping seciton of the openfire.conf...

Comment by Maxime Cheramy [ 03/Aug/07 ]

I agree Joe :

Here, we're going to set up an OpenFire using the LDAP for all the students BUT we're not allowed to write on the LDAP.
So we want to be able to use the avatars and the other vcards stuffs without writing on the LDAP so using the internal openfire db.

The current plugin is great for this ! But it would be nice to be added natively in openfire.

Comment by Hannes Wüthrich [ 03/Aug/07 ]

Hello everybody,

The LDAPVCardAvatar plugin has a new home. Make sure to use http://www.eyecraft.ch/coding/ldapvcardavatar/ in the future! I think the files here are a little outdated...

Yes I also agree: It would be great to allow other VCard fields to be stored in the DB as well while using the LDAP (or any other) provider and then merge all the data on VCard retrieval. The problem is, I can't think of a simple and consistent way to configure and implement this. There are some ideas on http://www.igniterealtime.org/forum/message.jspa?messageID=143051&tstart=0 but I'm not sure if this actually works.

Cheerio,
Hannes

Comment by Juan Jose Alonso [ 09/Oct/07 ]

this feature, will be ever be available? I have been waiting a lot of versions but always is delayed. Is there any patch to get Avatars stored in the DB?. I have tried with lafdapavatar plug in but with no results...

Comment by Juan Jose Alonso [ 09/Oct/07 ]

Hi,

with the last version of Openfire, the plug in works!!!

Openfire database is Oracle; in which table is avatar information stored?

Thanks,
JJ.-

Comment by Gaston Dombiak [ 20/Oct/07 ]

New home for LDAP VCard Avatar: http://www.eyecraft.ch/2007/08/03/a-new-home-for-ldap-vcard-avatar/

Comment by Daniel Henninger [ 24/Dec/07 ]

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.

Comment by Maxime Cheramy [ 24/Dec/07 ]

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.

Comment by Daniel Henninger [ 24/Dec/07 ]

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.

Comment by Maxime Cheramy [ 24/Dec/07 ]

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 ?

Generated at Tue Apr 23 16:39:39 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100251-rev:1799943389865e673b0a2c8607653e705b66f09c.