openfga @ v1.3.8

[BREAKING] this release introduced protobuf API changes to the gRPC API to accommodate changes for the up and coming Conditional Relationship Tuples feature. No changes to the OpenAPI specification for the HTTP API have changed. gRPC clients that are referencing the old protobuf definitions are not compatible with this release and future releases >= v1.3.8. To upgrade to this release please update your existing OpenFGA gRPC clients to the latest protobuf API definitions. Failing to do so can lead to message and field level incompatibilities with existing clients.

Added

• Experimental support for ABAC Conditional Relationships.

  To enable experimental support for ABAC Conditional Relationships you can pass the enable-conditions experimental flag. For example, openfga run --experimentals=enable-conditions. The upcoming v1.4.0 release will introduce official support for this new feature. For more information please see our official blog post. The v1.4.0 release will have more official documentation on openfga.dev.

  ⚠️ If you enable experimental support for ABAC and introduce models and/or relationship tuples into the system and then choose to rollback to a prior release, then you may experience unintended side-effects. Care should be taken!

  Read on for more information.

  If you introduce a model with a condition defined in a relation's type restriction(s) and then rollback to a prior OpenFGA release, then the model will be treated as though the conditioned type restriction did not exist.

  model
    schema 1.1
  
  type user
  
  type document
    relations
      define viewer: [user with somecondition]
  
  condition somecondition(x: int) {
    x < 100
  }
  

  and then you rollback to v1.3.7 or earlier, then the model above will be treated equivalently to

  model
    schema 1.1
  
  type user
  
  type document
    relations
      define viewer: [user]
  

  Likewise, if you write a relationship tuple with a condition and then rollback to a prior release, then the tuple will be treated as an unconditioned tuple.

  - document:1#viewer@user:jon, {condition: "somecondition"}
  

  will be treated equivalently to document:1#viewer@user:jon in v1.3.7 or earlier. That is, Check(document:1#viewer@user:jon) would return {allowed: true} even though at the tuple was introduced it was conditioned.

• Minimum datastore schema revision check in the server's health check (#1166)

  Each OpenFGA release from here forward will explicitly reference a minimum datastore schema version that is required to run that specific release of OpenFGA. If OpenFGA operators have not migrated up to that revision then the server's health checks will fail.

• Username/password configuration overrides for the openfga migrate entrypoint (#1133). Thanks for the contribution @martin31821!

  Similar to the server's main entrypoint openfga run, you can now override the datastore username and password with environment variables. when running the openfga migrate utility.

• Healthcheck definitions in Dockerfile (#1134). Thanks @Siddhant-K-code!

Changed

• Database iterators yielded by the RelationshipTupleReader storage interface now accept a context parameter which allows iteration to be promptly terminated (#1055)

  We have noticed improvements in query performance by adding this because once a resolution path has been found we more quickly cancel any further evaluation by terminating the iterators promptly.

• Improved tuple validation peformance with precomputation of TTUs (#1171)

• Refactored the commands in the pkg/server/commands package to uniformly use the Options builder pattern (#1142). Thanks for the contribution @ilaleksin!

• Upgraded to Go 1.21.4 (#1143). Thanks @tranngoclam!

Fixed

• If two requests were made with the same request body and contextual tuples but the order of the contextual tuples differed, then the cache key that is produced is now the same.(#1187)

• Use NoOp TracerProvider if tracing is disabled (#1139 and #1196)