Global Moderators group | Smart Home

toggledbits

@tamorgen said in MFA:

url: "/api/"

Remove the trailing slash.

toggledbits

See edit above

toggledbits

Are you requesting from a browser or curl?

Edit: also source_IP must be source_ip (all lower case).

toggledbits

The allowed list is separate from ACLs. It's just a first check. The ACLs are next. The former doesn't imply the latter, the latter having much more granularity/detail.

toggledbits

You don't need to run the commands from inside the container. You can add an ACL allowing the IP address of the host system or your LAN subnet (as source_ip). But in any case, once you add the user/group ACL entry to permit the endpoint as suggested above, as long as that entry also doesn't restrict IP (i.e. doesn't contain source_ip), any IP that can log in as that user (or a user in that group, if group), will be allowed from anywhere (i.e. authorized queries from outside the container will work).

toggledbits

Interesting exercise. I decided that that alone wasn't sufficient, so I added MFA to the mix. I recommend using both with exposed Reactor systems, and in particular, enable required MFA for all users, so no accounts can accidentally be left open.

toggledbits

Reactor build 26298

SECURITY: Recent discovery of compromised intermediate certificates has been addressed with updated docker images for arm64 and amd64/x86_64. Bare-metal Reactor users are advised to upgrade their node install to at least (within each major version) 22.23.4, 24.22.1, or 26.12.1, and further update their CA certificates on the underlying operating system, as well as any affected packages (e.g. potentially python, OpenSSL, curl, wget, etc.). Any of the popular AIs should be able to provide useful specific guidance if you adequately describe your system configuration. Note that armv7l images cannot be fully patched at this time due to limitations in underlying packages. Upgrading to 64-bit is currently the only path.

Security: Reactor Access Control now supports Multi-factor (Two-Factor) Authentication. Configuring MFA is highly recommended for users granting access to Reactor from outside their LANs (e.g. via reverse proxy or tunnel). See docs
Security: Reactor Access Control now blocks host IP addresses for consecutive login failures (configurable, default: 4 failures within 3 hours gets blocked for 48 hours). See docs
Security: docker images have an updated node version to address recent discovery of compromised eMudhra intermediate certificates, and others. The image OS certificate store has also been updated accordingly. ref ref ref
HubitatController: New x_hubitat_sys.restart and x_hubitat_sys.reboot actions (on system entity); see docs
HassController: Bless HA to 2026.10.4

toggledbits

OK. Please do this: make the httpapi section of config/logging.yaml look like below (or add if not present):

  httpapi:
    level: 5
    streams:
      - type: file
        name: "httpapi.log"
        recycle: true
        keep: 4
        maxsize: 2
        level: 999

Also add trusted_proxy: "127.0.0.2" to your config/reactor.yaml (after the baseurls is a good spot).

Restart Reactor. Launch a request from the remote side of the tunnel. There should be messages logged in httpapi.log for that request that say either httpapi#1 starting request from <ip> for... or httpapi#1 starting proxied request from <ip> via <ip> for....

If the logged message is the first form, or it's the second form and the two IP addresses logged ("from" and "via") are identical, there is no stable internal (CloudFlare) address seen on the request from your tunnel. This means you can't use allowed_ips (at all) unless your external request address is stable and can be listed in it.

If the logged message is the second form (<ip> via <ip>), and the two IP addresses are different, then the second address is the (detectable) inside address of the tunnel. In that case, you would replace the 127.0.0.2 in trusted_proxy with that ("via") IP address, and add pass_all_proxy: true to config/reactor.yaml.

Since your tunnel is not a reverse proxy, I suspect you're going to be in the former situation. I'm just hoping to be surprised.

toggledbits

There's a reason that I ask that log data is always posted with context (lots of preceding lines): often there are messages before that provide hints or additional data that are important to troubleshooting. There is a line logged for httpapi prior to one you included that would be useful to see. I'd also like to see all of the related configuration settings as you have them right now.

toggledbits

@tamorgen said in Reactor Build 26284 stuck at Loading Reactor UI:

proxy_baselurl: https://reactor.xyz.com #not xyz.com

Must include port number

@tamorgen said in Reactor Build 26284 stuck at Loading Reactor UI:

Edit: I also tried it with quotes around the URL. I'm not sure why, but in your documentation you have quotes around the baseurl URL and the proxy_baseurl with an IP, but in the next section with a FQDN, there is no quotes. Is that intentional, or does it matter?

Best practice to quote it. Makes no difference to Reactor as long as the YAML parser accepts it (the quotes assure that).

Global Moderators

Posts

Reactor build 26298

Member List