[Feature Request] Option for overrding presentationUrl in UPNP Device Service XML

[blindfish]

Well, that's certainly not what I would have liked to hear, but thank you for hearing me out and the clear response.
I hope this won't get buried completely, but of course understand if this is not a priority for you.
Thanks again.

[simoncn]

I have an idea for a possible solution. This would be to add a new option to block all access to configuration settings from other devices. If this option is set, you would be able to view and change configuration settings from the device that is running MinimServer but not from any other devices. Would this work for you?

[blindfish]

Hmm, I'm not sure, could you elaborate how this would look on the technical side?
Do you intend to block all access to settings from IP addresses that do not belong to the local machine?

[simoncn]

Yes, block all access to viewing or changing configuration settings for requests from other IP addresses. File serving to other IP addresses would still work.

[blindfish]

So referencing my little diagram in this post, would I be able to specify the IP address for e.g. eth0 as "the one" for configuration viewing/changing?

[simoncn]

You would not be able to specify the eth0 address 172.19.0.8. My proposal would allow access from this address and also from the eth1 address 192.168.1.35 and from the loopback address 127.0.0.1 if this is active.

[blindfish]

Hi,

sorry for my late reply.

If I get this right, this would work in almost any scenario but docker containers.
To access/change configuration, the request would have to originate on the same host, which is possible if MinimServer is running bare metal, in a VM or even LXC. In my case, the reverse proxy "guarding" the configuration access would have to run on the same host for the request to have the proper origin. But for micros ervices, as docker containers, this is not feasible, since I would have to cram the reverse proxy into the same container as MinimServer, which defeats the point of docker.

Kind Regards
blindfish

[simoncn]

I agree that this unfortunately doesn't work when running MinimServer in a Docker container, so a different approach is needed.

From post #3:

(17-07-2023 07:37)blindfish Wrote:  So my first attempt was to add a macvlan to the container so that SSDP would still work, but the web interface would only be accessible on the docker internal bridge network. For that I was looking for a setting to bind the webserver to a specific interface (the internal bridge only). That did not exist.

Although this is not possible at present, it would be possible to add this as an option. This would also restrict use of the web API and mscript to the same specific interface.

Implementing a similar restriction for MinimWatch configuration is more difficult. MinimServer uses the external ohNet package to implement the UPnP protocol for communication between MinimServer and UPnP clients (i.e., UPnP control points and MinimWatch). ohNet provides a setting to limit access to a single subnet but this would apply to all UPnP clients, so using this setting would block client access for UPnP browsing as well as for MinimWatch configuration.

Instead, MinimServer could reject all inbound requests from MinimWatch that don't originate from the permitted subnet. This should prevent configuration changes but it might cause MinimWatch to malfunction or behave in an unexpected way because MinimWatch will receive some inbound messages from MinimServer (automatically sent by ohNet) but it will receive an error result whenever it tries to send back an outbound message. I will need to do some experiments to confirm what would happen in this scenario.

If I can make this work with MinimWatch, would it meet your requirement?

Edit: Unfortunately, this doesn't quite work because binding the web server to a single subnet would also bind the resource server to the same subnet, which creates the same problem you have at present. An alternative would be for MinimServer to provide a configuration option to specify a single IP address (your reverse proxy) that is authorised to perform configuration actions. It would still be necessary to prevent unauthorised MinimWatch configuration actions and I don't know how this would work because these don't use HTTP and therefore can't be filtered by the reverse proxy.

I will give this some more thought.