The first step that we went through was securing the WebAdmin REST API of the James server. As part of this :
— We enabled an optional HTTPS configuration.
— We set up authentication using the JWT mechanism.
Those two steps will allow people safely exposing their James WebAdmin API over the internet.
The setup we choosed for connecting James administration is the following:
— Store the James WebAdmin endpoint in OpenPaaS database. As a domain administrator, I will be able to update it.
— The browser will then use the new JS library james-admin-client we built during the barcamp to perform the calls on James WebAdmin. We chose to provide a separate JS library to ease the implementation of a standalone JAMES web administration user interface.
— Then we can display the result inside the JAMES panel, in the OpenPaaS Admin module.
In the near future, we would like to implement this as a separate OpenPaaS module that would plug into the ADMIN module.
Then, we wanted to demonstrate we can easily add new configuration features using what have been introduced previously. We chose for that Domain Aliases definition and mail Quotas. Quotas are users limitations when storing mails. In James it is the total size of their e-mails as well as the total e-mail count. Domain aliases allow to convert the domain of the recipients of a mail. For instance re-writte *@old.linagora.com to *@new.linagora.com. We implemented the JAMES REST endpoints for Domain Aliases, as well as integration in the james-admin-client library. However, we missed time to integrate it in the frontend. Concerning quotas, we succeed to implement a working prototype.
Now it is time to review all this cool code, and get it merged! You can follow the event on twitter and watch our demo on youtube.