I have a web application (done using Coldfusion) running on one server, where I have a MySQL database containing lots of user info. On another server I have Jive Messenger.
When I add/delete a user in my application, I also want to add/delete a user in my Jive Messenger service. “Inband Account Registration” is disabled, since new accounts should only be created using my web-interface.
How could I implement this? I considered the idea of writing directly to the Jive database to add/del users, but as I understand it there is no way to get Jive to “refresh” it’'s info from the database, and it would not be future-proof if the database layout of Jive were to change in a future version.
Hi Andreas,
How could I implement this? I considered the idea of
writing directly to the Jive database to add/del
users, but as I understand it there is no way to get
Jive to “refresh” it’'s info from the database, and it
would not be future-proof if the database layout of
Jive were to change in a future version.
You are correct, JM does cache users so it wouldn’'t automatically show you the registered users. Interestingly your users should be able to login as that would force JM to look up the database and update its cache.
Some options are
-
use the smack api to add users via the admin user account (inband account disabled may prevent this)
-
use the userimport/export plugin (manual!)
Have a search of the forums - there are lots of similiar posts, and you may find a more suitable solution.
Hope that helps,
Conor.
Hi Andreas,
As Conor stated, trying to keep your existing web application and Messenger user databases in-sync with one another is going to be a real challenge. A preferred option would be to write your own UserProvider and AuthProvider which would allow Messenger to hook directly into your existing user database. Using this approach won’'t allow you to edit/delete users via Messenger but it would greatly simplify integrating the two applications.
Hope that helps,
Ryan
Follow Ryan´s sugestion.
That´s what I did for the same problem.
Even though I´m not a Java-Coder it was a piece of cake.
Cheers
JC
A preferred option would be to write your own UserProvider and AuthProvider which would
allow Messenger to hook directly into your existing user database.
I’‘m not quite sure I’‘m following you, are you saying I should replace the user database completely, doesn’‘t that mean that I’'d have to have add tables for the relations between users etc. to my own database aswell?
Ideally I would want to have something that works just like adding users via the Smack API (which I guess would be something like - connect to XMPPConnection/get AccountManager/use createAccount()) but that only allows my app to add users, not everyone in the world that happens to find out the address to my Messenger server.
A preferred option would be to write your own
UserProvider and AuthProvider which would
allow Messenger to hook directly into your existing
user database.
I’‘m not quite sure I’'m following you, are you saying
I should replace the user database completely,
doesn’‘t that mean that I’'d have to have add tables
for the relations between users etc. to my own
database aswell?
You wouldn’‘t really be replacing the user database, rather you’'d have Messenger authenticate against your existing user table. And yes, the easiest thing to do would be to add the Messenger tables to the same database that your existing application uses.
Ideally I would want to have something that works
just like adding users via the Smack API (which I
guess would be something like - connect to
XMPPConnection/get AccountManager/use
createAccount()) but that only allows my app to add
users, not everyone in the world that happens to find
out the address to my Messenger server.
You could certainly use the Smack API to create and delete accounts as needed, but then you’‘re going to have two user databases with same users in them. A potential problem with keeping two user databaes is what would happen if someone changed their name or password in one of the databases, would you want to keep that data synronized? If so, then you’'d have to create a mechanism for detecting the change and updating the tables properly.
So, you’'ll just have to weight the pros and cons of each approach and go with whichever makes the most sense for you.
Hope that helps,
Ryan