Release: Oso 0.10.0 is out – including Authorization for Your UI, Support for Oso in the Browser, and Support for More List Filtering Operations

oso v0.10.0 is out! Here's what's in the release:

• Authorization for Your UI - Different users may need to see different features or views depending on what permissions they have. You can now use Oso.get_allowed_actions to get a list of actions that a user is allowed to take on a resource, which is especially handy for things like hiding or showing a button based on a user's permissions. We also wrote a guide with some best practices. Read the guide.
• oso in the browser - We've updated the oso JavaScript/TypeScript package on NPM to work with browser environments using bundlers like webpack. We'll actually be using this feature to power interactive policies on the browser on our new docs site (coming soon – read more below). To see a quick example on how to get started with oso in the browser, visit the quickstart, and if you have input on where you want to see this feature go open a GitHub issue.

We have been hard at work on a new docs site. We want to sharpen the focus on the specific problems and use cases we hear from users to make it even easier for you to find the solution you need.

Today we're sharing a preview of the new docs site, which is still under construction 🚧. We will continue to ship changes over the coming weeks. We're sharing it early to get your input on what works for you. Have a look here and if you have feedback, open a GitHub issue.

0.11.0-alpha with Support for More List Filtering Operations

Today we are also releasing an alpha of oso 0.11.0 that brings major upgrades to list filtering and its underlying machinery. These changes make it possible to write queries in a more declarative style, and allow oso to answer more queries using unbound variables. For example, with this build you can:

Write hierarchical authorization policies over collections of objects:

# A user can read an Expense if they can read the organization of the expense.
allow(actor, "read", expense: Expense) if
allow(actor, "read", expense.organization);

Write a much broader array of policies using negation and list filtering. A common one might look like this:

# Admins can delete expenses that are not protected or already approved.
allow(actor, "delete", expense: Expense) if
actor.is_admin and
not (expense.is_protected = true or expense.is_approved = true);

Write policies that use list filtering to authorize access to a resource based on an intersection between collections.

# An actor can approve an Expense if she is a manager of the Expense's
# creator AND in the list of approvers for the Expense's project.
allow(actor, "approve", expense: Expense) if
    actor in expense.creator.managers and
    approver in expense.project.approvers and
    actor = approver;

Given the impact of this change to the oso core and in the spirit of conservatism, we are releasing this in alpha, starting with our Python libraries, django-oso v0.7.0a0 and sqlalchemy-oso v0.5.0a0. Feel free to try them out and share feedback!

For more details, read the changelog.

If you ever have questions, we're available to talk to you about how to get from one version to the next, or to discuss anything you'd like about the product, your use case, or authorization more generally – join us on Slack or open an issue.