Trace output during execution of a query that shows what's happening. Should make debugging a bit easier.

Notable features include.

• Showing all the applicable rules when querying a call. This shows which rules and the order they will be tried after filtering and sorting has been done.
• Showing Queries, Unifys, Matches, Comparisons and Math operations.
• ShowingFFIi lookups and the results that come back.
• Showing relevant bindings (bindings for variables used in the expressions being traced) alongside so it's easier to see what's happening.

Looks something like this.

query> f(1);
[trace]   QUERY: 'f(1)', BINDINGS: {}
[trace]     FILTERING RULES
[trace]       UNIFY: '1' = '_x_4', BINDINGS: {}
[trace]       UNIFY: '1' = '_x_6', BINDINGS: {}
[trace]       UNIFY: '1' = '_x_7', BINDINGS: {}
[trace]     SORTING RULES
[trace]     APPLICABLE_RULES: [
[trace]       f(x) if new (Foo{x: x}, _instance_2) and .(_instance_2, foo(), _value_1) and _value_1 = x;
[trace]       f(x) if x = 1;
[trace]       f(x) if x + 1 and _op_3 == 2;
[trace]     ]
[trace]     RULE:
[trace]     f(x) if
[trace]       new Foo{x: x}.foo() = x
[trace]     UNIFY: '1' = '_x_10', BINDINGS: {}
[trace]       QUERY: 'new (Foo{x: _x_10}, _instance_2_11) and .(_instance_2_11, foo(), _value_1_12) and _value_1_12 = _x_10', BINDINGS: {"_x_10": "1"}
[trace]         QUERY: 'new (Foo{x: _x_10}, _instance_2_11)', BINDINGS: {"_x_10": "1"}
[trace]           UNIFY: '_instance_2_11' = 'Foo{x: 1}', BINDINGS: {}
[trace]         QUERY: '.(_instance_2_11, foo(), _value_1_12) and _value_1_12 = _x_10', BINDINGS: {"_instance_2_11": "Foo{x: 1}", "_x_10": "1"}
[trace]           QUERY: '.(_instance_2_11, foo(), _value_1_12)', BINDINGS: {"_instance_2_11": "Foo{x: 1}"}
[trace]             LOOKUP: Foo{x: 1}.foo()
[trace]             => 2
[trace]           QUERY: '_value_1_12 = _x_10', BINDINGS: {"_x_10": "1", "_value_1_12": "2"}
[trace]             UNIFY: '_value_1_12' = '_x_10', BINDINGS: {"_value_1_12": "2", "_x_10": "1"}
[trace]             UNIFY: '2' = '1', BINDINGS: {}
[trace]             LOOKUP: Foo{x: 1}.foo()
[trace]             => No more results.
[trace]     RULE:
[trace]     f(x) if
[trace]       x = 1
[trace]     UNIFY: '1' = '_x_13', BINDINGS: {}
[trace]       QUERY: '_x_13 = 1', BINDINGS: {"_x_13": "1"}
[trace]         UNIFY: '_x_13' = '1', BINDINGS: {"_x_13": "1"}
[trace]         UNIFY: '1' = '1', BINDINGS: {}
True
[trace]     RULE:
[trace]     f(x) if
[trace]       x + 1 == 2
[trace]     UNIFY: '1' = '_x_14', BINDINGS: {}
[trace]       QUERY: '_x_14 + 1 and _op_3_15 == 2', BINDINGS: {"_x_14": "1"}
[trace]         QUERY: '_x_14 + 1', BINDINGS: {"_x_14": "1"}
[trace]           MATH: '1' + '1' = '_op_3_15', BINDINGS: {}
[trace]           UNIFY: '2' = '_op_3_15', BINDINGS: {}
[trace]         QUERY: '_op_3_15 == 2', BINDINGS: {"_op_3_15": "2"}
[trace]           CMP: '2' == '2', BINDINGS: {}
True
query>

Fixes #1552

This commit catches the assertion error when verifying the right_path does not exist when a path has been identified on the left side of the policy. This refactor was made to better clarify the cause of the error for developers who may not be familiar with the technical limitations of the current SQLAlchemy integration.

In my case, I had assumed that the use of foreign keys and paths on both sides would be more performant, and thus the best choice for a policy, when writing the authorization rules. The resulting error didn't include any context about what was wrong with the policy I had written. This commit aims to address this by providing a best effort guess to provide a starting point for developers to debug the policy issue themselves.

PR checklist:

• [ ] Added changelog entry.

ReferenceError: __dirname is not defined in ES module scope

Unfortunately, oso appears to have trouble running when I build it as part of an ESM project because it references __dirname in certain parts of the code below:

// [email protected]/node_modules/oso/dist/src/polar_wasm_api.js
var path2 = __require("path").join(__dirname, "polar_wasm_api_bg.wasm");

In my own code, where I load the .polar files, I work around this issue using the ESM recommended approach:

import path from 'path';
import { fileURLToPath } from 'url';

const dirname = path.dirname(fileURLToPath(import.meta.url));

await oso.loadFiles([path.resolve(dirname, 'main.polar')]);

• [ ] PolarClass may now be derived on Rust enums.

Hello :wave:

I'm attempting to add support for Rust enums on the #[derive(PolarClass)] proc macro. This involves having the procedural macro generate code to store each enum variant on the Class that is being constructed. A loop in register_class then registers each constant.

I sought to keep the API as simple as possible such that someone looking to add this functionality in their Rust project only needs to add #[derive(PolarClass)] onto their enums (thanks to @joshrotenberg for his input on this 🙂 ). However, this doesn't quite work; I'm hoping some additional eyes on it will help.

The core of the problem seems to be fact that the constants are initially stored on the class as trait objects. Those are then passed around a few times before they get handed to register_constant. The compiler complains about the size of the trait objects not being known. I believe there are ways of handling this in nightly Rust, but I'm not sure what the pattern for addressing this is on stable.

There's also the distinct possibility that I'm missing something simple 🙂

Hello again :slightly_smiling_face: I've just gone for the auto-formatting route this time, except for one change.

I've run isort & Black over all of the Python version of Oso (in that order,) removed the newlines under a few function docstrings that had them as per PEP 257. Black, as far as I know, doesn't have any guide on these, so it shouldn't interfere with anything.

Now, for the manual change - I've removed the newlines between :param:s in oso/oso.py, as they weren't anywhere else - for consistency's sake and all that. Also extra newlines at the end of 2 docstrings in that same file.

I do hope nothing breaks this time.

Here's a small fix to the Ruby gem for Oso that wasn't loading as expected out of the box. It fixes https://github.com/osohq/oso/issues/1089

I wasn't able to find an applicable changelog file to register this. Nor did I know if I was supposed to bump the version in the code. Please let me know if this solution works.

Since it's my first time contributing please give me instructions on accepting the contributors agreement.

Thank you for Oso and the help on Slack!

Hi OsoHQ,

Been enjoying the library, and I hope to use it for an authorization service, however I believe I found a memory leak in the Golang library.

Setup

I was able to reproduce using the oso-go-quickstart example. I forked that repo and the only changes I made were:

• upgraded to the latest oso v0.11.3 -> v0.12.3 (https://github.com/bhb603/oso-go-quickstart/blob/main/go.mod#L5)
• added a policy:

  allow(actor: String, "GET", expense: Expense) if  
          expense.SubmittedBy = actor;
  

• Dockerized the app and deployed it to a kubernetes cluster with this simple deployment (my ultimate use case would be to deploy in kubernetes, which is why I replicated that here)

Testing

I have some load-testing tooling which can generate requests against the service. Since this quickstart example only has one endpoint, it just requests:

curl -H "user: [email protected]" http://oso-go-quickstart.oso:5050/expenses/1

Which would check oso.IsAllowed(User("[email protected]"), "GET", expense) and return:

HTTP/1.1 200 OK
Content-Length: 40
Content-Type: text/plain; charset=utf-8

Expense{{500 coffee [email protected]}}

Results

Memory Usage increases linearly when the service is under load, until it reaches the limit I set for the container (256M) at which point Kubernetes kills the container (OOMKIlled) and it restarts, producing the saw tooth graph below.

The rate of memory increase is proportional to the load (reqs per second), i.e. it increases ~2.5x faster when I was hitting it at 25rps vs 10rps, and flattens out with 0rps.

Memory usage under load:

More Metrics:

Add a job that looks for changes in the docs made by a diff by building the docs against the branch and base branch.

If there are changes, will comment on the PR, as in #937 and require a comment to acknowledge the changes (you must manually re-run the job). The intent of this is to catch PRs that inadvertently break the docs, like changes to code included in code snippets.

If you make a PR changing the docs intentionally, just comment "Docs changes ok" after uploading, and the job will pass on the first run.

If you don't make any changes to the docs (#936), the job also passes, with no comment required.

PR checklist:

• [ ] Added changelog entry.

Hi!

Thanks for that awesome work on the Oso Framework! We are really enjoying working with it!

Currently, we are evaluating whether the sqlalchemy-oso library would fit our needs. Are there any plans regarding the new SQLAlchemy 2 update?

Trying to include it in our project leads to the following error message:

Because sqlalchemy-oso (0.6.0) depends on sqlalchemy (>=1.3.20,<1.4.0) and no versions of sqlalchemy-oso match >0.6.0,<0.7.0, sqlalchemy-oso (>=0.6.0,<0.7.0) requires sqlalchemy (>=1.3.20,<1.4.0).

Would love to hear from you!

• Bumps jnr-ffi to a newer version with Apple Silicon support.
• Updates release workflow to build a fat (x86_64 + aarch64) .dylib and to use that in the .jar build

Fixes the issue I mentioned in https://github.com/osohq/oso/issues/808#issuecomment-1023495977 (at least partially?).

~With the newer version I was able to build the .jar on a M1 machine and the final resulting .jar ran as expected with a aarch64 JRE. However the resulting .jar didn't run on the x86 JRE anymore (though I guess that is expected behavior).~

~Not sure how the .dylib for the release build is built (as the java Makefile references a debug build and specificlally makes a note that it shouldn't be used in release builds?), but I would assume that for properly building a fat .jar some additional step of cross-compiling and building a fat .dylib might be required.~

EDIT: updated PR to include a build of a fat .dylib

The documentation indicates that POLAR_LOG=1 enables tracing. Intuitively you would think that POLAR_LOG=0 disables tracing, particularly if you use the setting in a dotfile/docker-compose.yaml etc.

However, it seems that POLAR_LOG just needs to be set to anything to enable tracing, and to be unset to disable tracing. I've tested this with the go, node, python and rust libraries, and it's the same with all four:

Here's an example using the node library:

❯ which oso
/Users/alexhafner/.volta/bin/oso
❯ echo $POLAR_LOG
0
❯ oso
query> 1+2=3
[debug]   QUERY: 1 + 2 = _op_1 and _op_1 = 3, BINDINGS: {}
[debug]     QUERY: 1 + 2 = _op_1, BINDINGS: {}
[debug]     QUERY: _op_1 = 3, BINDINGS: {_op_1 = 3}
true
query> %
❯ unset POLAR_LOG
❯ oso
query> 1+2=3
true
query> %
❯ export POLAR_LOG=foo
❯ oso
query> 1+2=3
[debug]   QUERY: 1 + 2 = _op_1 and _op_1 = 3, BINDINGS: {}
[debug]     QUERY: 1 + 2 = _op_1, BINDINGS: {}
[debug]     QUERY: _op_1 = 3, BINDINGS: {_op_1 = 3}
true
query>

This was tested on main while reviewing the changes from https://github.com/osohq/oso/pull/1115

It would be helpful for developers if tracing could be disabled by setting POLAR_LOG=0.