Fire Arrow Server 2.1.4

Fire Arrow Server 2.1.4 has been released.

• (bugfix) Reading attachment content with $binary-access-read now follows your existing read rules instead of returning 403 Forbidden

Bug Fixes

Reading binary content was denied despite read access

The $binary-access-read operation returns the raw bytes of a resource's stored attachment — for example, fetching the content behind a Binary (or another resource whose attachment was offloaded to storage). It is meant to follow the same access rules as reading the resource itself: a caller who is allowed to read a resource type should be able to read that resource's binary content.

Before 2.1.4, $binary-access-read was rejected with 403 Forbidden even when the caller had a matching read rule (for example, read allowed on Binary). The server treated it as an extended operation rather than a read, so ordinary read rules never applied and there was no way to permit it through normal authorization configuration.

Starting with 2.1.4, $binary-access-read is treated as a read of the resource's binary content. A read rule that already grants access to a resource type now also permits $binary-access-read on instances of that type — no separate rule is required:

fire-arrow:
  authorization:
    validation-rules:
      # Grants read on Binary — this same rule now also authorizes
      # $binary-access-read on those Binary instances.
      - client-role: Device
        resource: Binary
        operation: read
        validator: DeviceCompartment

Compartment scoping still applies to each instance: the content is served only for instances the caller could retrieve with a normal read, so DeviceCompartment, PatientCompartment, and similar validators narrow $binary-access-read exactly as they narrow ordinary reads. Writing binary content with $binary-access-write is unchanged and continues to be governed by update/write rules. Deployments that do not use $binary-access-read are unaffected.