Post Reply 
 
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
21-07-2023, 08:38
Post: #11
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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.
Find all posts by this user
Quote this message in a reply
22-07-2023, 17:33
Post: #12
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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?
Find all posts by this user
Quote this message in a reply
22-07-2023, 19:43
Post: #13
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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?
Find all posts by this user
Quote this message in a reply
22-07-2023, 20:07
Post: #14
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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.
Find all posts by this user
Quote this message in a reply
23-07-2023, 19:04
Post: #15
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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?
Find all posts by this user
Quote this message in a reply
23-07-2023, 21:43
Post: #16
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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.
Find all posts by this user
Quote this message in a reply
29-07-2023, 09:46
Post: #17
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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
Find all posts by this user
Quote this message in a reply
30-07-2023, 17:16 (This post was last modified: 30-07-2023 20:57 by simoncn.)
Post: #18
RE: [Feature Request] Option for overrding presentationUrl in UPNP Device Service XML
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.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)