-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AST Tree Support #37
Comments
I ended up copying the file json.go and changed json.policyJSON to json.PolicyJSON. After that, I was able to do a json.Unmarshal to parse the json and then walk through the structs using the Cedar JSON Format docs. This is working fairly well including for parsing the condition expressions. My thought is that moving internal/json/json.go to the top level is all that is needed for those that want to walk a tree-like structure. json_marshall.go and json_unmarshall.go aren't actually needed to be exposed because all they do is translate to/from cedar.Policy which at present does not expose sub-objects. |
Thanks for filing this issue, @independentid. We do intend at some point to have a public interface for walking the AST. We wanted to wait until we'd gotten the internal AST into a shape that we felt was maintainable going forward and then release it publicly. As far as validation goes, we are also planning to add first-class support for that in a similar manner as the Rust SDK. I'll leave this issue open to track the work of making the AST publicly walkable. |
We just made a release that moves our AST into x/exp. So maybe not stable yet, but at least it is publicly accessible now! https://github.com/cedar-policy/cedar-go/releases/tag/v1.0.3 |
In Cedar 0.1.0 there was a way albeit through some code marked experimental to access parsed Cedar AST structure. This was useful when evaluating whether a policy is valid and what is wrong. It is also useful in translating from other formats (e.g. Hexa IDQL).
The main thing is to gain access to each parsers syntactical tree structure, eg.. Principal, Actions, Object, Conditions and then be able to drill into the type of relationships expressed. This is particularly critical parsing condition trees (e.g. converting to JSON Path / SCIM RFC7644 style filter expressions).
One thought was to use the Cedar JSON format, but the negative is it doesn't solve parsing condition expressions.
The text was updated successfully, but these errors were encountered: