powered by Jive Software

Disabling install of IM gateway plugin

I need to disable the ability for adminstrators to install the “IM Gateway” Plugin on the admin console webpage.

Currently I use the follwing hack:
  1. Create an empty file in openfire/plugins/ named ‘gateway.jar’.

  2. Set permissions of gateway.jar to read-only.

This causes the green plus icon to disappear on the install new plugins page. No link to click on, no easy way to install the plugin.

My concern is that the plugin still appears on the available plugins page, even though it cannot be installed from there.

How could I remove the IM gateway plugin from the list of available ones ?

Hi John,

Wow, I guess your admins must have caused you a pain in the neck :).

You could also try chmod -w on openfire/conf/available-plugins.xml. That file contains Gateway entry, so you would want to delete that line. When you’re done, restart openfire. The problem with this method is that you’ll never get the updated list of available plugins, and perhaps you don’t bother either .

My admins have not caused me any headaches yet and I hope to keep it that way.

Chmod-ing the available-plugins.xml and making it read-only is a good idea that I had not thought of. I could manually push a modified available-plugins.xml with the rest of my system updates when a new available-plugins.xml becomes available.

Not to get too technical, but my idea/work-around/hack is as follows:
  1. Put a modified version of available-plugins.xml on my webserver

  2. Write a bash script that uses wget to fetch the modified available-plugins.xml and set it to read-only

  3. Run the bash script as a weekly cron job

This allows me to remove any plugins that I do not like and still get updated lists.

By the way, if my users run the IM gateway plugin it will cause the system to be doing things that are against the law. Per Federal Communications Commission rules, Part 97. These infractions commonly carry fines of thousands of dollars. See The Outernet Project for more details.

Thanks Again

h5. Not to get too technical, but my idea/work-around/hack is as follows:

  1. Put a modified version of available-plugins.xml on my webserver
  1. Write a bash script that uses wget to fetch the modified available-plugins.xml and set it to read-only
  1. Run the bash script as a weekly cron job

Well… on the second thought, I don’t think any of these would work because once Openfire fetched (on exact time, daily) the latest update it will cache it. The file is only useful (read) when openfire starts. You might want to verify this from the source code. So, the best way (perhaps the only way without restarting Openfire) could be to hack Openfire source code

You might be able to go about it a different way as well -> after installing or upgrading openfire, go into openfire/src/plugins/admin/webapp/WEB-INF, edit web.xml. and delete:

org.jivesoftware.openfire.admin.available_002dplugins_jsp</servle t-name>

/available-plugins.jsp

That’ll make the web interface for adding new plugins go away… forcing folk to have to have local access to the server to install new plugins (while retaining the ability to update existing plugins)

I will warn you that in 3.4.0 I added the ability to upload plugins through the web interface via a simple form. (plugins that aren’t on the available plugins page) But it’s not quite as trivial as hitting the available plugins page and outright seeing what’s all available.

You may even want to delete:

org.jivesoftware.openfire.admin.plugin_002dadmin_jsp</servlet-nam e>

/plugin-admin.jsp

to remove the plugin interface altogether. (I mean the link will still be there, but it won’t function) Then you can limit to only server access people being able to do -anything- with plugins.

I thought you’re gonna say how hurt you were when some would spend much effort disabling your plugin

BTW, I think what you meant was openfire/ src/ plugins/admin/webapp/WEB-INF, without the src/.

lol =) and yes, i did mean without the src!

I think this is just one of the situations in which different levels of admin access are deemed necessary. Access to what one can do with plugins could have easily been achieved if the admin console were designed from ground up to be object oriented and as MVC as Clearspace. Perhaps the core Java and Web programmers haven’t found a way to join forces yet .

You’re right…

I tried making the available-plugins.xml file read only and the admin colsole still get its updated plugin list.

So… I guess I’ll stick with the empty gateway.jar file for now, to block installation of that plugin.

I’ll also use the firewall to block all ports and servers that the IM gateway would access, just in case:

More of a hack than a fix, but it works.