0
votes

We are developing a consumer hardware product. Each device is registered on a central webserver and the owner also have a user account to which the device is linked. The owner may also choose to share the device with other users.

Now, to solve the problem of getting through firewalls etc we are using XMPP: the user access his/her devices using an iOS/Android app. The app connects to the XMPP-server and so does the hardware devices. So the app can access the devices by sending custom XMPP stanzas.

Currently the device and the mobile app use the same JID, so the device will allow messages only from the same bare JID as itself uses. To allow for sharing devices we are planning to use the roster instead: the device will get its own JID ("[email protected]") and will accept stanzas from all JID's in its roster.

The problem I'm having is that the users, devices and device-sharing data are stored on the webserver. I would like to use this same information on the XMPP-server: all users and devices on the webserver are allowed to login to XMPP and the roster of a device is the same as the users that may access it. This information can be accessed through a JSON API.

One way would be to mirror changes as they happen, but I don't like that idea since there are too many steps that could go wrong.

The best solution I can think of is to let the XMPP server use the JSON API instead of its builtin database. It would be read-only, but that is not a problem since all registration and sharing should be done on the webserver.

Any ideas on how to proceed? The functionality described above is more or less all that we need: we don't need S2S, offline messages, etc. We are currently using Ejabberd, but Prosody or Openfire are perhaps better alternatives?

1

1 Answers

1
votes

For authentication, it looks like this ejabberd contribution does exactly what you need:

https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http

For roster, it is easy to write a custom roster module that will be hitting your HTTP backend instead of query the database thanks to ejabberd API. You can have a look at mod_roster as a guide to implement the methods: https://github.com/processone/ejabberd/blob/master/src/mod_roster.erl