I've added support to SiskinIM, so that it will try to unregister device via HTTPS if push component is not reachable via XMPP. That will be done automatically.

To make it work, endpoint /rest/push/unregister-device/** (added to PUSH component) needs to be available at https://{push-component-jid}/unregister-device where {push-component-jid} is a jid of a push component (usually locally hosted domain prefixed with push.).

Note: This will work for tigase.org if we will add proper HTTPS endpoint for push.tigase.org, and we would need to do the same for tigase.im and all domains hosted at tigase.im and tigase.org installations (any hosted there domain will use push.hosted-domain as a jid). If that would be not configured then SiskinIM would still block account removal if push component is not accessible via XMPP.

@wojtek What do you think? Do we need to do anything else?

Looks OK.

One moment. I was just pondering a bit more - the issue boils down to user not being able to delete account because it's offline hence can't disable the push (and that would leave "dangling devices" on our servers // in push-component) - correct? If yes, then why should be add all hostnames (i.e. mentioned push.hosted-domain) instead of only push.tigase.im (which is the push endpoint for Siskin)?

@wojtek Because Siskin IM first looks for push component with a special feature on "local" domain and if found uses it before trying to use push.tigase.im. Thanks to that we (at tigase.org and on my installation) we are using local push components instead of default component. That is very useful for testing. Unfortunatelly, at the same time this feature allowed user hosting its domain at tigase.im installation to use push.domain component jid (as it was discoverable).

Ah, now it makes sense :-)

Though, shouldn't we limit push component visibility on tigase.im to only tigase.im (i.e. hide in on VHosts)? For all intents and purposes this wouldn't change anything (it will be routed internally to correct place without any external network connection)? (IMHO this could be more universal solution instead of requiring additional DNS configuration) - what do you think @andrzej.wojcik ?

We could, should, but can we? With just a configuration change? or is possible to force component only to be visible under one top domain name?

From what I remember we don't have anything like that. There is tigase.component.AbstractKernelBasedComponent#isDiscoNonAdmin but it doesn't take any parameter so it's not possible to differentiate whether it should be shown or not on per-vhost basis.

This would definitely require extending current API, but it could also create some overhead (AFAIR currently service disco is more or less uniform for all domains and only difference is 'being admin') but I'm not sure we do want to do that.

Given that this is somewhat 'edge case' let's not move forward with it. I updated all our domains to include push. subdomain and pointed it to same hosts as A record push.tigase.im. and adjusted nginx on the instances to handle it correctly. The only thing is to update tigase.im.