Hello! I am running into an issue with the sqlalch...
# help
l
Hello! I am running into an issue with the sqlalchemy
get_query
method. I have posted an issue here: https://github.com/cerbos/query-plan-adapters/issues/69 I would love any help or advice! Thanks!
d
Hi Lindsay! What’s the value of
p
in this snippet:
Copy code
plan_resource = PlanResourcesInput.Resource(kind="org")
plan = c.plan_resources("org.read", p, plan_resource)
query = get_query(plan, <http://models.Org|models.Org>, {"request.resource.id": models.Org._id})
This?
Copy code
{
  "id": "user_764c63",
  "roles": [
    "user"
  ],
  "attr": {
    "orgs": {
      "org_dd60a6": {
        "role": "owner"
      }
    }
  }
}
l
yes, that's right
d
I’m not a Python dev, but this line
query = get_query(plan, <http://models.Org|models.Org>, {"request.resource.id": <http://models.Org|models.Org>._id})
doesn’t look right to me. The last argument takes known resource attributes, if any. If the resource ID is known, you can get the resource by ID from the database; the query plan isn’t needed.
l
Thanks! My understanding is that the last arg to
get_query
is supposed to be a mapping between the policy parameters and the mapping to the database. This query is supposed to return a list of orgs the principal is allowed to
org.read
. You can see a similar example in the cerbos sqlalchemy example project: https://github.com/cerbos/python-sqlalchemy-cerbos/blob/6161da479d031e8bdcd2d7cf4fc6fac7fc991e97/main.py#L90-L99
🤔 1
d
In that snippet,
get_query
takes four arguments. Attributes map is the 3rd argument, and mapping to the DB is the 4th argument.
What if you pass
{}
instead of
{"request.resource.id": <http://models.Org|models.Org>._id}
?
l
If I pass a blank dict, the error is the same,
KeyError: 'variable'
d
Okay. I’m looking into the query plan output. It should be more simple.
l
Thanks!
Let me know if you need more information
or if a call would be helpful
d
Thank you. I have all the info to sort out the query plan part.
1
The query plan API should work for the policy as it is now, but there’s a workaround.
I’ve created an example in the playground:. I changed the structure of the principal attributes object.
Copy code
{
  "id": "user_764c63",
  "roles": [
    "user"
  ],
  "attr": {
    "orgs_roles": {
      "org_dd60a6": "owner"
    }
  }
}
And the policy:
Copy code
apiVersion: "api.cerbos.dev/v1"
derivedRoles:
  name: common_roles
  definitions:
    - name: OrgViewer
      parentRoles: ['user']
      condition:
        match:
          any:
            of:
              - expr: P.attr.orgs_roles[R.id] == "owner"
              - expr: P.attr.orgs_roles[R.attr.org_id] == "owner"
              - expr: P.attr.orgs_roles[R.id] == "viewer"
              - expr: P.attr.orgs_roles[R.attr.org_id] == "viewer"
That simplified the output of the query planner a lot. Hopefully, the ORM will be able to handle it.
l
hmm ok, I'll check it out. Thanks for taking a look!
Just FYI, I was following the principal structure in this "best practices" docs page: https://docs.cerbos.dev/cerbos/latest/policies/best_practices#_static_policies_dynamic_context so I was hoping it would be an appropriate way to lay out principal data
d
Yes, this is a bug in the query planner. I’ve suggested a temporary workaround while we are fixing it.
Thanks for reporting it.
l
ooh got it. Thanks so much!
🙌 2
s
Thanks both. I'll dig in to the SQLAlchemy adapter side of things.
d
The PR has been merged.
s
I'll dig in to the SQLAlchemy adapter side of things.
Dennis' PR solves the SQLAlchemy adapter issue too. If you pull the latest version of Cerbos, it should resolve your issue.
l
Thank you! The query does work now with the dev version of cerbos image 🎉 🙏
🎉 2