search

ioBroker / ioBroker.proxy

This adapter allows to access other web servers over web adapter.
MIT License
6 stars 6 forks source link

Ability for other adapters to automatically request forwarding of specific URLs #134

Open raintonr opened 7 months ago

raintonr commented 7 months ago

Currently it seems that routing of paths to other adapters must be configured manually. However, imagine a world where an adapter can request a path be send to it without any user intervention. Ie. Imagine the ACME adapter could request /.well-known/acme-challenge/... be forwarded to it for handling (noting that that path cannot currently be handled - see #133).

A mechanism such as this that performed automatic forwarding where necessary would be very useful and simplify installation/administration.

Apollon77 commented 7 months ago

In general a good idea.,m The question is basically how to configure this and also how to store this. So yes an adapter could adjust the config diretcly on the object or via a message, but as soon as this gets persoisted and the other adapter gets deleted this entry stays here ... So when we need some other way to configure such proxy routes which would require a io-package flag/enhancement to dynamically build this on startiup additionally to config or such

raintonr commented 7 months ago

... or via a message ... but as soon as this gets persoisted and the other adapter gets deleted this entry stays here ...

Yes and no. The proxy adapter could monitor status of those adapters it receives messages from and remove rules when the other adapter dies.

Ie.

  1. Proxy adapter starts.
  2. ACME adapter starts, sends message to proxy adapter to forward /.well-known/acme-challenge/...
  3. Proxy adapter receives and acts on this message. Subscribes to system.adapter.acme.0.alive
  4. ACME does it's business and shuts down.
  5. Proxy adapter notices ACME has shutdown (via system.adapter.acme.0.alive subscription) and removes rule.

With this solution Point 2. would need to be achieved with a 'persistant message' library or similar that itself subscribes to the status of the destination proxy adapter (eg. system.adapter.proxy.0.alive) and re-sends any messages if the proxy adapter restarts. This would probably not be useful for the ACME example as that is a short lived process, but this persistence would likely be required for others.

The above does seem slightly inelegant though. I do note that there is a mechanism by which each adapter can contain specific 'settings' relevant only when another specific adapter is installed - think I saw this with history, lovelace, etc. Surely that would be a better option? Only the 'settings' would be set automatically from the adapter and not manually in admin.

raintonr commented 7 months ago

What I just said here...

...an intermediary library, when called to setup an automatic rule, would need to seek out a proxy which has a compatible Route path, port, etc.

.. in fact, maybe that isn't true. If 'settings' for an adapter instance were automatically configured, wouldn't it be down to any proxy instance to look at these (startup or via subscription) and act accordingly? Would then need a mechanism for requesting adapter (Eg. ACME) to check it's 'settings' had been noted and the providing instance was actually running before attempting to use that.