powered by Jive Software

Using HTTP Bind to notify OpenFire when a new user is created

Hi,

We are integrating OpenFire in a portal application we are building. We are currently using custom user, group, and authentication providers in order to maintain the user database in our own schema. Because the users are not just OpenFire users, but rather users of the whole system, the information we need to administer for each user forces us to have our own administration screens; we cannot use the OpenFire admin screens to manage users because we want to manage all of the user information in one place and OpenFire only supports maintaining a minimal set of fields relevant to the chat functionality.

The custom providers (which are read-only) are working fine except for one thing. If we create a new user via our admin screen, OpenFire does not recognize the new user until we restart OpenFire or forcibly flush the user cache to force OpenFire to re-read the users from our custom provider.

We need a way from our custom application to make OpenFire aware that a new user has been created. Several alternatives have been explored, but the most appealing would be to have our application connect to OpenFire using HTTP and send a registration notification. However, I am wondering if anyone has examples they can share of using HTTP bind to connect to the server and send a registration packet to add the new user. Note that the user really doesn’t have to be added per se (it is already in our database by this time), but the goal is just to make sure OpenFire knows about the new user. Alternatively, if there is a way to forcibly flush the user cache via HTTP, we might also consider this approach. I understand that this would defeat somewhat the intent of the cache, but we don’t expect user creation to be costly or frequent enough to be a big issue for us.

Finally, I am also open to other suggestions regarding how to achieve our goal so feel free to offer any suggestions or comments.

Bill

When you say, “Openfire does not recognize the new user until we restart Openfire or forcibly flush the user cache to force Openfire to re-read the users from our custom provider.” - what do you mean by recognize?

By ‘not recognize’, I mean the server doesn’t seem to know this is a valid existing user and won’t let me log in using the new username.

I should mention that auto-registration (I think that is the right term) is turned off … we don’t want users to be created automatically the first time they log into the server. All users must register via our application before they can use OpenFire. The act of registering adds them to our external database table.

It appears that OpenFire only reads the users from the custom provider at specific sync points … i.e. startup and after the user cache is flushed. Since users are added externally through another application, not OpenFire, it believes the cache is up to date and it never goes back to read my database.

My thought was that if I could somehow have my application tell OpenFire, “Hey, I just created a new user and your cache is out of date”, then it would re-query my database and find the new user.

Is this making any sense to you?

Bill

What I was calling auto registration appears to be called inband account registration on the admin console (Registration & Login). Now that I read the description there, I worry that using HTTP bind to send a registration packet may be the very thing I have disabled. However, it does suggest that you can register the users through a custom web interface … this is indeed what I am trying to do so it seems that my use case was anticipated.

I first had this problem a month or more ago, but I was not having much luck getting an answer since I did not have paid support, only the free variety.

I just went back to try and reproduce this problem and I am unable. It now seems to be working … I can’t explain what changed, but I have made a few configuration changes to the OpenFire server as well as updating from 3.3.1 to 3.3.2 … so who knows what fixed it. But it seems ok for now.