This release contains breaking changes. Be sure to follow migration steps before upgrading.
New rule syntax
We have made several major changes to Polar syntax used in writing rules to make the policy more intuitive for non-technical policy readers.
- The if operator is now written as
- The and operator is now written as
- The or operator is now written as
- The not operator is now written as
Taken together, these changes produce rules like:
allow(actor: User, "view", resource: Expense) if role(actor, "accountant") and actor.location = resource.location;
allow(actor: User, "view", resource: Expense) := role(actor, "accountant"), actor.location = resource.location;
Methods can now be called on application classes. For example, with a class
my_rule(x) if Foo.class_method(x) = true;
Rest operator for lists
Lists can now be destructured using the
\*rest operator. This allows
[x, *rest] = [1, 2, 3]
x would be assigned to
More information here: *rest Operator.
Language support for anonymous variables
A variable named
_ is now recognized as an anonymous variable. Previously,
multiple anonymous variables in a rule needed to be named distinctly (
___). This scenario is often encountered when writing rules with
specializers that do not use the argument value:
allow(_: User, "view", _: Resource);
Host language list, string, dictionary and number methods
Because your application objects probably use your language’s built-in
primitive types such as
int, Polar allows you to use
methods on those types for its built-ins, too. That way you can use familiar
str.startswith() on strings regardless of whether they
originated in your application or as a literal in your policy. This applies to
all of the Polar
primitive types: strings, lists,
dictionaries, and numbers, in any supported application language.
More info: Built-in Types.
Stack traces for runtime errors
Now errors occurring during execution of Polar code will include context about
where the issue occurred. The
stack_trace property on exception types
contains a formatted traceback indicating where errors happened:
trace (most recent evaluation last): in query at line 1, column 1 allow(1) in rule allow at line 5, column 13 in file stack-trace.polar call_failing_rule(_x_18) in rule allow at line 5, column 13 in file stack-trace.polar call_failing_rule(_x_18) in rule call_failing_rule at line 3, column 25 in file stack-trace.polar failing_rule(_x_21) in rule call_failing_rule at line 3, column 25 in file stack-trace.polar failing_rule(_x_21) in rule failing_rule at line 1, column 20 in file stack-trace.polar _x_24 in 2 in rule failing_rule at line 1, column 20 in file stack-trace.polar _x_24 in 2
Singleton variable warnings
The usage of a variable only once will now emit a warning on standard error. These often indicate logical errors. This warning can be silenced by prefixing a variable with an underscore. More information: singleton variables.
Set up a 1x1 with an Oso Engineer
Our team is happy to help you get started with Oso. If you'd like to learn more about using Oso in your app or have any questions about this guide, schedule a 1x1 with an Oso engineer.