BUG REPORT- Ability to login as Admin gone

Openfire Openfire Support
1

I’ve discovered a bug which causes you to lose the ability to login as the admin user. I discovered it in the Windows version. Here’s how to duplicate (and fix) the bug.

  1. Set-up Openfire using the Embedded Database.

  2. Create a second user and grant that user admin privileges.

  3. Change the Server Name.

  4. Restart the Server.

You will no longer be able to login to your server using any login.

You have two options to fix the bug.

First, STOP the server.

Second, edit this file:

/openfire/embedded-db/openfire.script

Third, do either of the following:

  1. Remove the lines that read:

INSERT INTO OFPROPERTY VALUES(‘admin.authorizedJIDs’,‘admin@SERVERNAME,seconduser@SERVERNAME’)

  1. Alternatively,you’ll notice on the line above that SERVERNAME is your OLD Serve Name. Change what appears in SERVERNAME from the older Sever Name to the NEW Server Name. Save.

Fourth, Restart the server.

If you do #1, all users who were designataed as administrators will lose their admin status. You will be able to login only using the “admin” user.

If you do #2, all users will retain admin status and be able to login again.

2

Note: They key to the bug is that when you create a SECOND admin user, Openfire adds a field that lists the authorized admins into the database including their JID (USERNAME@SERVERNAME).

When the Server Name is changed, however, Openfire doesn’t update that field to the NEW Server Name, and so nobody can login.

If you never create a second admin user, Open Fire never adds that line to the database, and you’ll never experience the issue even if you change the Server Name.

If you create a second admin user, but you never change the Server Name, you’ll also never experience the issue.

3

I also figured out how to fix this issue if you encounter it when using MySQL as your database in CentOS:

Stop openfire:

service openfire start

Login to MySQL as root:

mysql -u root -p

Select your openfire database (assuming you called it openfire)

USE openfire;

Show table containing fields:

SELECT * FROM ofProperty;

  1. Do one of the following:

A. Delete the table (only admin will be able to login once you’re done):

DELETE from ofProperty where name=‘admin.authorizedJIDs’;

B. Modify the table (all admins will be retained. change SERVERNAME to reflect

correct names and new Server Name):

UPDATE ofProperty

SET

propValue=‘admin@SERVERNAME,otheradmin@SERVERNAME’

WHERE name=‘admin.authorizedJIDs’;

  1. Exit MySQL:

exit

  1. Restart openfire

service openfire start

Now, you’ll be able to login again as admin to the web UI.

4

Hi, thanks for reporting.

Seems like this is already tracked here:

[OF-184] RFE: changing xmpp domain should migrate admin JIDs - Jive Software Open Source

From reading in the comments, some people don’t want to change this behavior.

5

It looks like the people who posted those comments don’t know what they are talking about.

Re-running set-up does NOT fix the behavior.

People sometimes do change the Server Name for legitimate reasons.

For example, I initially deployed the server internally using an internal IP address as the Server Name, and then, when I was ready to move it publicly, changed the server name.

6

And also, it makes very little sense to allow changing the Server Name in web-interface (not setup) if that breaks the application.

Either disable changing the Server Name in the web application OR ensure that it properly re-writes the database everywhere.

As it is now, a simple change in the web configuration breaks the ability to login, and re-running set-up will NOT fix it.