Release 2021-02-17

Changelog for Release 2021-02-17 (oso 0.11.0) containing new features, bug fixes, and more.

Release 2021-02-10

Changelog for Release 2021-02-10 (oso 0.10.2, go-oso 0.11.0-alpha.1) containing new features, bug fixes, and more.

Release 2021-02-03

Changelog for Release 2021-02-03 (oso 0.10.1, go-oso 0.11.0-alpha) containing new features, bug fixes, and more.

Release 2021-01-20
oso 0.10.0 Breaking changes Anonymous rest variables now properly anonymized Previously, we were not generating unique identifiers for anonymous rest variables (*_) during the rewriting pass. This resulted in unexpected results for queries containing multiple anonymous rest variables, such as: [*_] in [*a] and [*b] in [*_] and b = 1 The above query would return a result with a bound to [1] because *a and *b interacted through the pair of un-anonymized rest variables. After this change, that query now correctly returns a result with a bound to [*_1], where *_1 is the rewritten, anonymized rest variable. New features get_allowed_actions introduced for Python Use Oso.get_allowed_actions to get a list of actions that a user is allowed to take on a resource. These actions can be used for making additional authorization decisions, especially in the frontend (e.g., hiding or showing a button based on the current user’s allowed actions). See our guide here! Running Oso in the browser The Oso JavaScript/TypeScript package on NPM has been updated to work with browser environments using bundlers like webpack. You can see it in action on our new docs site and to see how to use in the browser, see this example. PolarClass implemented for versions 0.7 & 0.8 of the uuid crate PolarClass is now implemented for versions 0.7 & 0.8 of the uuid crate behind the optional uuid-07 feature flag. Ruby library now supports Ruby 3.0 There are no breaking changes. Happy Rubying! oso 0.11.0a0 New features Improved support for constraint propagation and interactions between variables in Polar VM The Polar VM now supports adding constraints during query execution on any unbound variable, including constraints over multiple unbound variables. Constraints can be used within any query, without requiring partial objects to be passed in to oso.query_rule. This allows writing queries in a more declarative style, and allows Polar to correctly answer more queries with unbound variables. The change improves support for the following queries, when run using oso.query_rule or using list filtering adapters with Django or SQLAlchemy: Rules involving intersections between multiple collections on objects allow(actor, action, post: Post) if tag in post.tags and tag in actor.allowed_tags; Calling rules on a field of a constrained variable allow(actor, action, post: Post) if allow(actor, action, post.tag); Comparison operations between constrained partials allow(actor, action, post: Post) if post_tag in post.tags and actor_tag in actor.tags and post_tag = actor_tag; Support for more queries involving negation and constraints. Creation of constrained variables from unbound variables during query execution f(x) if not (x = 1) and x = 2; Since this is a substantial change, we are releasing an alpha build. This build provides an opportunity to give feedback to our engineering team as we complete this functionality. We’re available in Slack for questions and feedback. sqlalchemy-oso 0.5.0a0 Includes support for oso 0.11.0a0. django-oso 0.7.0a0 Includes support for oso 0.11.0a0.
Release 2020-12-22
django-oso 0.5.1 Bug fixes & improvements Fixed type-checking for many-to-many relationships in Django using the related_name field in list filtering policies. sqlalchemy-oso 0.3.0 Breaking changes WARNING: This release contains breaking changes. Be sure to follow migration steps before upgrading. Updates to built-in roles This release makes a number of changes to how the out-of-the-box role support works in the sqlalchemy_oso.roles module. It simplifies the schema of the role model, adds relationships to the user and resource classes, and contains more error checks for various required constraints and things that can go wrong. It also includes docs! Bug fixes & improvements The sqlalchemy-oso library now supports authorization for queries that contain aliases.
Release 2020-12-08
oso 0.9.0 Breaking changes WARNING: This release contains breaking changes. Be sure to follow migration steps before upgrading. Removed “extras” The Oso library previously had some additional default supported classes: Http and Pathmapper. These have been deprecated and removed. To write policies over HTTP requests, either register the suitable application class directly, or use a framework integration (e.g. flask-oso or django-oso) which will do this for you automatically. New features PolarClass implemented for uuid crate PolarClass is now implemented for version 0.6 of the uuid crate behind the optional uuid-06 feature flag. Version 0.6 was chosen for compatibility with Diesel. Thanks to John Halbert for the contribution! Other bugs & improvements Fixed bug where checking if a character is in a string would fail incorrectly. django-oso 0.5.0 Other bugs & improvements The Django AnonymousUser class is available in polar policies under the name auth::AnonymousUser. This name is preferable to the previous fully qualified name because it matches the registered name of the User model (auth::User). The django-oso library no longer prints to stdout when loading policy files. Instead, the Python logging module is used. Relaxed the requirements for the Python oso and django-oso libraries. These now require cffi~=1.14 and django>=2.2, respectively. Thanks to Mike D. for suggesting / implementing the above three improvements! The Django list filtering adapter now fully supports use of the not operator in policies. For the Django list filtering adapter, a rule like allow(_, _, post: Post) if _tag in post.tags; now translates into a constraint that the post must have at least 1 tag. flask-oso 0.6.0 Bumped the minimum required version of the oso dependency. sqlalchemy-oso 0.2.1 Breaking changes WARNING: This release contains breaking changes. Be sure to follow migration steps before upgrading. Simplified sqlalchemy-oso session creation sqlalchemy-oso now associates the current Oso instance, user to authorize, and action to authorize with sqlalchemy_oso.session.AuthorizedSession. This class manages authorization instead of the removed sqlalchemy_oso.hooks.make_authorized_query_cls. The sqlalchemy_oso.hooks module has been renamed to sqlalchemy_oso.session. Update any imports to sqlalchemy_oso.session. The sqlalchemy_oso.hooks.make_authorized_query_cls function has been removed. Use the session API instead. (sqlalchemy_oso.authorized_sessionmaker()). The sqlalchemy_oso.authorized_sessionmaker function no longer accepts extra positional arguments. Use keyword arguments to pass options to the session. New features Improved sqlalchemy-oso support for usage with flask_sqlalchemy The sqlalchemy-oso library now has a built-in wrapper class that makes it easier to use with the popular Flask-SQLAlchemy library. See sqlalchemy_oso.flask.AuthorizedSQLAlchemy for more information. scoped_session support for sqlalchemy-oso The new sqlalchemy_oso.session.scoped_session() session proxy can be used instead of SQLAlchemy’s built-in scoped_session. This creates a session scoped to the current Oso instance, user and action. Initial support for built-in roles in sqlalchemy-oso This release includes the first steps towards out-of-the-box role-based access control (RBAC) support in the sqlalchemy-oso integration. New to the integration is an API for easily creating roles scoped to a resource and assigning them to users of your application. You are then able to write RBAC rules over those managed roles. We will be iterating heavily on this feature over the coming weeks, but we would love to hear any feedback from early testers. Other bugs & improvements matches operations on fields of partials are now handled correctly in the SQLAlchemy list filtering adapter. Previously these operations would result in an error. The SQLAlchemy list filtering adapter now supports all comparisons. Previously comparisons other than == or = would cause an error. For the SQLAlchemy list filtering adapter, a rule like allow(_, _, post: Post) if _tag in post.tags; now translates into a constraint that the post must have at least 1 tag.