Right now we do have a password reset feature and account confirmation feature as part of the REST API (HTTP web page), but I agree we should move it to the Dashboard (or at least make them available there).

Account creation by non-admin (registration) is a missing feature.

Just a question, regarding not by admin registration (open to everyone), we should add some bot protection I suppose we could consider using https://altcha.org/ for that.

@wojtek @kobit What do you think?

Right now we do have a password reset feature and account confirmation feature as part of the REST API (HTTP web page), but I agree we should move it to the Dashboard (or at least make them available there).

Yes, those are handled via rest API and already have a page but it should be possible to trigger it from the new page - just a link like on the current page:

It would probably fit the new page theme so there shouldn't be a problem

Account creation by non-admin (registration) is a missing feature.

Yup.

Just a question, regarding not by admin registration (open to everyone), we should add some bot protection I suppose we could consider using https://altcha.org/ for that.

Looks great!

Maybe we could even integrate it into tigase-spam (https://altcha.org/docs/v2/sentinel/use-cases/chat-forum-moderation/)?

EDIT: eh... FOSS version seems to lack quite a lot of features though: https://altcha.org/open-source-captcha/

Yes, FOSS version may have some limitations, but it should be easy to integrate with Tigase (at least to protect against spammers or robots trying to create an account). If I'm correct that should work without a need to setup a separate server to handle captcha verification requests.

Definitely we need a protection for open registration.

By the way, on the landing page and/or registration page, please add links to our XMPP apps/clients.

I've managed to add user registration (integrated into the dashboard).

I've worked on this feature and added support for managing users and domains (vhosts) using dashboard. Right now it has simple features (add, removed, enabled/disable, enable/disable registration) for domains but also has support for self-service features (ie. user can login and change his password, reset password or register). Also it is possible to enable userCanCreateDomain, to allow users to register domains (add his own vhost), ie.

http () {
    dashboard () {
        permissionsHelper () {
            userCanCreateDomain = true
        }
    }
}

Additionally, I've added support for serving "static" web pages, This can be done using config entry

http () {
     index (active: false) {} 
    staticPage () {
        filesPath = '/path/to/static/website'
        contextPath = '/'
    }
}

that will disable "index" page and serve static page at / context from path /path/to/static/website.

This feature in combination with a web page built using Jekyll in https://tigase.dev/DevOps/sure.im-website/ should allow us to replace current sure.im website. We would need to add static page files to EB context (generated by Jekyll), mount it to Tigase container, and configure Tigase as I've shown above to serve this page.

I've decided to have web page separated from Tigase (Tigase is only serving static files) and built with Jekyll to keep things simple and easier to maintain.

On the other hand, when Tigase would be deployed in kubernetes, we can skip forcing Tigase to serve static files and using ingress to directly serve sure.im web page.

Below is sure.im website, I've created in https://tigase.dev/DevOps/sure.im-website/ project, in ready to deploy version (generated) to allow us to review what this page can. Please note that "create account" and "register" buttons point to Tigase HTTP API dashboard endpoints that are not in the version deployed at sure.im.

sure.im-website.zip

@kobit Could you please look at created web page for sure.im? Please let me know if I should change something or you can adjust it as it uses the same Jekyll theme as tigase.org website.

@wojtek Could you review changes made to the dashboard? Will created features allow us to replace sure.im website? or do we need anything else?

I think that to fully support vhost management by users using dashboard, we should add support for uploading of SSL certificates for domains. That would allow user to fully control his custom domain (unless we need to add some more advanced options that I do not see need for at this point).

Could you review changes made to the dashboard? Will created features allow us to replace sure.im website? or do we need anything else?

@andrzej.wojcik

I did a quick pull of latest Tigase image and and I think it looks and works OK.

I do wonder if it wouldn't be simpler (deployment wise) to build and bundle the website directly in the distribution package (as we've done with sure-im client, which was a war dependency but in the en it was just a webpage zipped)

Another thing about the website - currently it has fixed/static links to login/register pointing to sure.im -- maybe make them relative and/or configurable (in the context of bundling the website as we've done with sureim client)

I wondered about it and I've came up with a conclusion (maybe I'm wrong) that this website is for sure.im and it is not needed to be part of the Tigase XMPP Server. I do not see any benefits from it being part of the image, moreover I think that it shouldn't be part of our package as it is harder to update (we most likely will update or add stuff to the website more often that update the show sure.im with a new version). Additionally, I think it would be not a good idea to put that in the open-source version (image) of Tigase XMPP Server.

I think that above statement explains why I've chosen to use static/fixed links.

Generally, I think that for general use we have index page at / context and that is OK (or maybe we should move dashboard to the /?). This new page is not a replacement for "sureim" old website/xmpp client bundled in Tigase as it is not an XMPP client. The direct replacement for xmpp client we had at /ui/ would be rather a proper XMPP client or a dashboard.

Hmm... in the end it's a landing page with simple "wrapper" (i.e. having links) around dashboard for registration/simple management so it seems sensible.

Though, deployment wise, having it separate and having to deal with mounts/redirects feels unnecessarily convoluted, but we can simply include/bundle it in the tigase.im deployment image.

Whether we create a special image for sure.im/tigase.im deployment (wrapper extending Tigase XMPP Server image) containing also the site files or not is a separate thing. I just suggested volume mounts as a drop in replacement that needs just reconfiguration.

As for k8s deployments and redirections (additional ingress rule) that seems like a standard way to handle such deployments on k8s.

http () {
    dashboard () {
        permissionsHelper () {
            userCanCreateDomain = true
        }
    }
}

Additionally, I've added support for serving "static" web pages, This can be done using config entry

http () {
     index (active: false) {} 
    staticPage () {
        filesPath = '/path/to/static/website'
        contextPath = '/'
    }
}

Was it included in documentation?

I've added documentation describing this feature and configuration