Conversation
cdisselkoen
left a comment
There was a problem hiding this comment.
In this PR, the RFC gets the same date for FCP and for Accepted. Is that correct?
Co-authored-by: Craig Disselkoen <cdiss@amazon.com>
Good point -- accepted date was wrong. Will fix in next commit. |
text/0019-stricter-validation.md
Outdated
|
|
||
| ## Updates | ||
|
|
||
| * 2023-11-07: The original text said that `AnyEntity` was used to type unspecified entities. This is not the case in any released version of Cedar -- instead unspecified entities are given a special `Unspecified` type. Updated text to reflect this. |
There was a problem hiding this comment.
Even for validation in permissive mode ?
There was a problem hiding this comment.
Yep, both modes. The type of an unspecified entity (i.e., a principal/resource in an environment where the action was missing appliesTo field(s) in the schema) is Entity({Unspecified}) rather than AnyEntity. AnyEntity is only used for template slots and the UB of actions.
In typechecking, <Unspecified> == <Specified Entity> is typed as False.
There was a problem hiding this comment.
Just double checked the code, and I was too hasty 😬 Here is the revised answer:
"Unspecified" entities are given type AnyEntity by the type checker, but in the rules for typing == and in are special-cased to return False when one element is unspecified.
There was a problem hiding this comment.
This has been true since the initial release, see type_of_equality and typecheck_in.
Will update the note to accurately reflect this. Sorry for the bugs... I have a lot of balls in the air this week.
Updates to RFC #19
appliesTofields in the schema #35By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.