Global Moderators group | Smart Home

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).

toggledbits

The attributes in x_hubitat_extra are created from whatever the hub sends to Reactor that isn't handled, to preserve a full view of the data. If the hub stops sending that attribute at some point, the attribute lives on in Reactor, it just isn't touched. At some point, an update (build) that causes Reactor to rebuild the entity will start over with a clean slate of attributes.

So the short answer is, if the attribute isn't there after an upgrade with entity rebuild, the hub no longer provides it (or it got renamed to something else).

It's generally not unusual to get a few errors when a build forces a rebuild of entities, either for a single controller or for all of them (depends on the nature of the upgrade). These usually vanish on a second restart of Reactor, or even just a restart of one controller (if it's limited to just one). If you get a persistent error, post as usual with the logs per the posting guidelines and I'm happy to dig in a bit, but always make sure you've done at least two restarts before reporting, and that the hub and its apps are fully up and running.

There are definitely timing issues at play here. Reactor cannot wait for every controller to start before firing up the Engine and letting Rules go to work, because there's no guarantee every controller will, in fact, start. It would be a huge problem if Reactor waited for every controller to start and be fully initialized. The trade-off is rebuilds of entities can cause temporarily inconsistent states.

toggledbits

Reactor build 26287

Tighten tests for proxied requests so that proxy-handling behavior isn't triggered when proxy configuration has not been established.

toggledbits

I found two cases where proxy-handling behavior can be triggered even though Reactor isn't configured with proxy info. Build 26287 contains fixes for those.

toggledbits

Have you set any of the new proxy configs?

toggledbits

Reactor build 26284

NOTE: Your first startup on this build may log some odd-looking errors while rebuilding entities from various controllers, and that's expected. A second restart should be noticeably cleaner.

New Access Control settings for operation behind reverse proxies. These new settings should enable easier reverse proxy configuration while maintaining local access (i.e. access UI via LAN). DISCLAIMER: Opening your system/network to a public IP address is not something to be trifled with, and if you don't know what you're doing, you will likely regret it at some point. Proceed entirely at your own risk. See further discussion here.
HassController: now recognizes HA's fan service with capabilities (including new capabilities: preset_mode, speed, direction and oscillate) extended by matching the source device's advertised supported features (i.e. not all capabilities will be present on all devices).
HassController: extend media_source capability to media_player devices that support it.
HubitatController: Improve behavior when new devices are added to the hub and published by Maker API. It should now not be necessary to restart Reactor to have the entity fully configured and responsive.
HubitatController: Default polling action is now Refresh (was Poll). On newer firmware, this more reliably produces a device change message when the state has updated (e.g. a switch without instant status was operated manually). Polled devices now allow an action config to override the default action.
HassController: Store HA unique_id and platform on extended attributes (e.g. for use in filtering).
HassController: Bless HA to 2026.10.1