@toggledbits thanks again for the reverse proxy support! I was wondering whether MSR's login functionality could be further secured, for example by implementing features similar to those Synology uses for DSM (see below).

@toggledbits, did follow your instructions and now reverse proxy works like a charm, thanks! I'm using https on Synology and firewalling functionality (allowing based on geo-ip), further restrictions done in Access Control Profile that DSM offers in reverse proxy configuration. Obviously also using authentication in MSR.

@therealdb what's your baseurl setting? Especially are you using different external port (and not 8111)?

@therealdb although I used only IP addresses and not dns names, I wasn't able to get UI to load. In my setup I'm using MSR in a docker container network and not host networking, so that might cause some additional headaches.

So could you share your configuration (e.g Synology reverse proxy conf, baseurl ...)? Obviously no need to use real IPs. I'm also wondering if https configuration in MSR can be avoided (not using that at the moment), but using let's encrypt cert in DSM. Port forwardings & firewall settings shouldn't be an issue, as /api/v1/log page works fine.

(MSR itself being in a container network having 172.18.0.11 address)

@toggledbits if I’d put public IP there, would it still work as expected when UI is used without a proxy? Also, does it accept dns name or just IPs?

@toggledbits yes I have

baseurl: "http://<private ip>:8111"

I'm trying to use MSR via reserve proxy in Synology DSM, but MSR page does not load

https://<public ip>:30000/reactor/en-US/

At the same time logging page loads normally

https://<public ip>:30000/api/v1/log

I thought maybe authentication was messing it up, but there was no deny entries in the log, and also disabling authentication did not make any difference. For this use case VPN is not an option (that works, but as said not an option for this particular use case).

Any ideas what could cause this? MSR build latest-26242-28d69aa8, Chrome browser

@noelab are constraints also true (or empty)?

A while ago I got rid of my Hubitat, so I'm no longer updating this thread

@tbully maybe not that helpful comment, but I strongly recommend docker (builds)

@toggledbits ...Revisiting this briefly, and a humble request for you to consider.

I'm still struggling with this particular solar inverter that's acting in a non-standard manner (against RFC 7616). Given this behavior, I would like to ask for the following changes to the HTTP request handling:

• If the server returns the header x-www-authenticate, it would be treated equivalently to www-authenticate
• If the server specifies algorithm="SHA256", it would be interpreted as algorithm=SHA-256 (and there might be even extra whitespaces present, e.g. " SHA256 ")

@toggledbits great work, as always!

@toggledbits I have, but it's a bit complicated setup (a proxy in between because of earlier problems with x-www-authenticate & www-authenticate headers). Related to Fronius inverter firmware update (some people have discussed this problem e.g. here)

I'm considering using modbus tcp (in home assistant) instead of http request, as this is getting tricky.

@toggledbits amd64 (synology nas)

...another thing, has ping command been removed?

With build 26140 (on Docker) I'm not able to clone any actions in reactions. Using Chrome if it has any relevance.

I’m using the HTTP Request action in MSR and need to authenticate against an endpoint that uses HTTP Digest authentication. Now that endpoint was changed to use SHA-256 in digest auth, so I would like to know if MSR supports it, or is it limited to MD5-based digest auth?

@toggledbits got it, thanks!

@toggledbits you're right, there's now a new entity "Nordpool" (with a capital N), that appeared after upgrading to 26140:

Some additional information to this case, as if I create a variable with "getEntity", but don't tick the box "Use Name", there's no error: