Rules service facade scoping #2675

Activity

1. richturner

   added

   DiscussNeeds discussion within the planning teamNeeds discussion within the planning team

   on Apr 8, 2026
2. richturner commented on Apr 23, 2026

   

   richturner

   on Apr 23, 2026

   MemberAuthor

   More actions

   The datapoint services are exposed in rules but given Groovy rules requires super user permissions the current risks are manageable
3. ebariaux

   removed

   DiscussNeeds discussion within the planning teamNeeds discussion within the planning team

   on Aug 26, 2026
4. denniskuijs

   assigned

   ebariaux

   on Oct 16, 2026
5. ebariaux commented on Oct 20, 2026

   

   ebariaux

   on Oct 20, 2026

   Contributor

   More actions

   Some work has already been done in Enforce realm / asset scope limitation on rules engines for HistoricFacade · Issue #3333 · openremote/core and Enforce realm / asset scope limitation on rules engines for PredictedFacade · Issue #3329 · openremote/core.

   NotificationsFacade and AlarmFacade need to be updated for proper scoping.

   UsersFacade and WebhooksFacade should also be reviewed to ensure scoping is fully implemented.
6. ebariaux

   added sub-issues on Oct 26, 2026

   • Avoid mutating caller queries in AssetsFacade #3478
   • Preserve caller path filters in asset-scoped rules queries #3479
7. ebariaux commented on Oct 26, 2026

   

   ebariaux

   on Oct 26, 2026

   Last edited by ebariaux

   Contributor

   More actions

   Work has been addressed in different PRs or sub-issues:

   • Alarm facade: PR Enforce realm and asset scoping for rule alarms #3459.
   • Notifications facade: PR Fix rules notification scoping and reject scoped topic/condition push delivery (breaking change) #3472 (includes the breaking-change and migration notes).
   • Users facade: PR Fix user query scoping and filtering in rules facades #3475.
   • Assets facade query isolation: Avoid mutating caller queries in AssetsFacade #3478, PR Prevent rules asset queries from retaining scope restrictions across executions #3481.
   • Assets facade caller path-filter preservation: Preserve caller path filters in asset-scoped rules queries #3479, PR Preserve caller path filters in asset-scoped rules queries #3488.
   • Separate functional bug discovered during the review: batch dispatch with repeated asset targets, AssetsFacade.dispatch rejects batches with multiple events for the same asset #3476, PR Fix batch dispatch of multiple attribute events to the same asset #3477.

   The remaining integration work is to combine the pending fixes, adapt the affected asset facade test stubs and expectations to the required-path storage overload, and run the affected suites together before closing this review.

   WebhooksFacade review conclusion: no realm/asset scoping change is required. This facade acts as an outbound HTTP client: it builds a target from the configured URL and authentication, then sends the configured method, headers and payload. It does not expose an inbound HTTP endpoint, look up OpenRemote entities, or automatically attach the rule author's OpenRemote credentials. There is no meaningful realm or asset-subtree restriction to apply to the HTTP destination.

   The earlier comment in #2819 about arbitrary URLs concerns outbound-network/SSRF policy, which is separate from realm/asset scoping. We consider that accessing any URL is part of the scope of OpenRemote HTTP connections and restrictions should be managed at the infrastructure level.