Skip to content
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

fix: access policy parsing #123

Merged
merged 4 commits into from
Jan 19, 2024
Merged

Conversation

tbrezot
Copy link
Collaborator

@tbrezot tbrezot commented Jan 17, 2024

Simplify parsing code and correct parsing errors. Notice that now, empty access policies can be parsed. Parsing should be more efficient too, but we lack benchmarks for that.

The only downside is that allowing '&' or '|' inside attributes is painful to write. I consider it an acceptable limitation to the expressivness allowed by the parsing operation.

This is a breaking change though. All "Department::R&D" attributes have been renamed into "Department::RD".

@tbrezot tbrezot requested review from ackRow and Manuthor January 17, 2024 15:25
Simplify parsing code and correct parsing errors. Notice that now, empty
access policies can be parsed. Parsing should be more efficient too, but
we lack benchmarks for that.

The only downside is that allowing '&' or '|' inside attributes is
painful to write. I consider it an acceptable limitation to the
expressivness allowed by the parsing operation.

This is a breaking change though. All "Department::R&D" attributes have
been renamed into "Department::RD".
@ackRow
Copy link
Contributor

ackRow commented Jan 18, 2024

Nice refacto!
Maybe we should completely remove the attribute R&D/RD from our examples and tests if we decide to reserve the character &

@tbrezot
Copy link
Collaborator Author

tbrezot commented Jan 18, 2024

Nice refacto! Maybe we should completely remove the attribute R&D/RD from our examples and tests if we decide to reserve the character &

Thanks. I pushed some commits to fix the issue with operator precedence (which was still not correctly applied). Now && can be implicit. I don't know if this is a feature we want to keep. I can add a test if we don't.

About R&D, I think it is OK to keep RD. I have heavily documented the parsing operation so users should not get mislead.

@tbrezot
Copy link
Collaborator Author

tbrezot commented Jan 18, 2024

Also, we can add a parsing rule to parse dimensions which component is not specified into all the disjonction of all its components. For example:

"D1 && D2::A" -> "(D1::A || ... || D1:::L) && D2::A" (provided components from "D1" are "A" ... "L").

It seems pretty natural, does not require much work to implement and seems to fit nicely into the key derivation process. I will give it some more thoughts, but for now I am in favor of adding this feature.

@tbrezot
Copy link
Collaborator Author

tbrezot commented Jan 19, 2024

After reading the code again, it may be more work than I thought. I propose we marge as-is.

@tbrezot tbrezot merged commit f37d53f into feat/partial_coordinates Jan 19, 2024
8 checks passed
@tbrezot tbrezot deleted the fix/access_policy branch January 19, 2024 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants