### Match Any Resource

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any resource. It is used in Cedar policies to apply rules to all resources in the system.

```cedar
//matches any resource
resource

```

--------------------------------

### Cedar Annotation Example

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to add annotations to a Cedar policy. Annotations like '@advice', '@id', and '@shadow_mode' provide metadata that does not affect policy evaluation but can be used by external tools.

```cedar
@advice("My advice")
@id("My ID")
@shadow_mode
permit (
    ...
);

```

--------------------------------

### Match Any Action

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any action. It is used in Cedar policies to apply rules to all possible operations on a resource.

```cedar
//matches any action
action

```

--------------------------------

### Match Actions in List

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any action from a provided list of actions. It is useful for applying a policy to a set of related operations.

```cedar
//matches any of the listed actions
action in [Action::"listAlbums", Action::"listPhotos", Action::"view"]

```

--------------------------------

### Match Specific Action

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching only a specific action, such as 'view'. It is used to define access control for individual operations.

```cedar
//matches only the one specified action
action == Action::"view"

```

--------------------------------

### Logical OR (||) operator examples and policy usage

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Explains the OR operator's short-circuiting logic and its application in policy conditions. Includes examples of safe attribute checking and standard policy syntax.

```Cedar
!(principal has age) || principal.age < 21

permit (principal, action == Action:"read", resource)
when {
    resource.owner == principal ||
    resource.tag == "public"
};

3 || true                  //error (first operand not a boolean)
true || 3                  //Evaluates to true (due to short-circuiting) //Validates
false || 3                 //error (second operand not a boolean)
(3 == 3) || 3              //Evaluates to true (due to short-circuiting) //Doesn't validate
```

--------------------------------

### Match Resource in Hierarchy

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any resource within the hierarchy of a specified entity, such as an Album. It is useful for managing access to collections of resources.

```cedar
//matches any resource that is in the hierarchy of the specified entity of type Album
resource in Album::"alice_vacation"

```

--------------------------------

### Match Specific Resource

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching only a specific resource, such as a particular photo. It is used to define access control for individual resources.

```cedar
//matches only the one specified resource of type Photo
resource == Photo::"VacationPhoto94.jpg"

```

--------------------------------

### Match Actions in Group

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching any action within a specified action group, such as 'admin'. It simplifies policy management by grouping related actions.

```cedar
//matches any action in the "admin" action group
action in Action::"admin"

```

--------------------------------

### Match Principal of Specific Type

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any principal of type User. It is used to apply policies to all users regardless of their specific identity.

```cedar
//matches any principal of type User
principal is User

```

--------------------------------

### Match Resource of Specific Type

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching any resource of a specific type, such as Photo. It is used to apply policies to all resources of a certain kind.

```cedar
//matches any resource of type Photo
resource is Photo

```

--------------------------------

### Cedar Policy: Permit Action Example

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This Cedar policy example demonstrates how to permit a specific action (view) for a principal (Alice) on a resource (VacationPhoto94.jpg). It includes the effect, principal, action, and resource, concluding with a semicolon as required by Cedar syntax.

```cedar
permit (
    principal == User::"alice", 
    action == Action::"view", 
    resource == Photo::"VacationPhoto94.jpg"
);

```

--------------------------------

### Match Any Principal

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates how to match any principal entity of any type. It is used in Cedar policies to define access control rules.

```cedar
//matches any principal entity of any type
principal

```

--------------------------------

### Binary Operator Examples (Equality and Hierarchy)

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Illustrates binary operators, which take two operands. Examples include the equality operator (==) for checking type and value, and the 'in' operator for hierarchy checks.

```cedar
a == b
c in d
```

--------------------------------

### Match Principal in Hierarchy

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching any principal within the hierarchy of a specified Group. It is useful for managing access for groups of users.

```cedar
//matches any principal in the hierarchy of the specified Group
principal in Group::"alice_friends"

```

--------------------------------

### Match Resource of Type in Hierarchy

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match any resource of a specific type within the hierarchy of a specified entity. It allows for granular access control based on resource type and organizational structure.

```cedar
//matches any resource of type Photo in the hierarchy of the specified Album
resource is Photo in Album::"alice_vacation"

```

--------------------------------

### Entity Identifier Example with UUID - Cedar

Source: https://docs.cedarpolicy.com/overview/scenario.html

Demonstrates the use of universally unique identifiers (UUIDs) for entity identifiers in Cedar policies, along with a comment to display the human-readable name. This is crucial for security in production systems to prevent identifier reuse.

```cedar
principal == User::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE11111", // alice

```

--------------------------------

### Constructor-Style Function Call (IP Address)

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Shows how to call functions using the constructor-style syntax. This involves placing operands in parentheses after the function name, separated by commas. An example is creating an IP address.

```cedar
ip("127.0.0.1")
```

--------------------------------

### Logical AND (&&) operator examples

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Demonstrates the behavior of the logical AND operator, including short-circuiting and validation constraints. Shows how non-boolean operands result in errors or validation failures.

```Cedar
3 && false                                  //error -- first operand is not a boolean
false && 3                                  //Evaluates to false (due to short circuiting) //Validates
(3 == 4) && 3                               //Evaluates to false (due to short circuiting) //Doesn't validate
(User::"alice" == Action::"viewPhoto") && 3 //Evaluates to false //Validates
true && 3                                   //error -- second operand is not a boolean
(false && 3) == 3                           //Evaluates to false //Doesn't validate (== applied to different types)
```

--------------------------------

### Logical NOT (!) operator examples

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Demonstrates the unary NOT operator for inverting boolean values. Shows usage in policy conditions and basic boolean negation.

```Cedar
forbid (principal, action, resource)
when {
    !(principal in Group::"family")
};

forbid (principal, action, resource)
unless {
  principal in Group::"family"
};

! true                                //false
! false                               //true
! 8                                   //error
if !true then "hello" else "goodbye"  //"goodbye"
```

--------------------------------

### Instantiate Template-linked Policies

Source: https://docs.cedarpolicy.com/bestpractices/bp-relationship-representation.html

Examples of concrete policies created from templates. These demonstrate how to bind specific principals and resources to the defined permission structures.

```Cedar
//Managed relationship permissions
permit (
  principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",  
  action in Action::"DocumentContributorActions",
  resource in Document::"c943927f-d803-4f40-9a53-7740272cb969"
);

permit (
  principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798",
  action in Action::"DocumentReviewerActions",
  resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a"
);

permit (
  principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",
  action in Action::"DocumentContributorActions",
  resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894"
);
```

--------------------------------

### Match Specific Principal

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example shows how to match only a specific entity of type User. It is used in Cedar policies to grant access to a particular user.

```cedar
//matches only the one specified entity of type User
principal == User::"alice"

```

--------------------------------

### Match Principal of Type in Hierarchy

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates matching any principal of type User within the hierarchy of a specified Group. It allows for granular access control based on user type and group membership.

```cedar
//matches any principal of type User in the hierarchy of the specified Group
principal is User in Group::"alice_friends"

```

--------------------------------

### Compare IP Addresses using ip()

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

This demonstrates comparing IP addresses parsed by the `ip()` function. Comparisons are performed using the equality operator `==`. The examples show comparisons between valid IP addresses and ranges, illustrating expected boolean outcomes. Note that comparing different IP versions or an IP address to a string literal will result in `false` and may not validate.

```cedar
ip("127.0.0.1") == ip("127.0.0.1")
ip("192.168.0.1") == ip("8.8.8.8")
ip("192.168.0.1/24") == ip("8.8.8.8/8")
ip("192.168.0.1/24") == ip("192.168.0.8/24")
ip("127.0.0.1") == ip("::1")
ip("127.0.0.1") == ip("192.168.0.1/24")
ip("127.0.0.1") == "127.0.0.1"
ip("::1") == 1
```

--------------------------------

### Cedar Record Data Type Examples

Source: https://docs.cedarpolicy.com/policies/syntax-datatypes.html

Illustrates the syntax and structure of Record data types in Cedar. Records are collections of attributes, where each attribute has a name and a value. Examples show basic record creation, attribute access using dot notation and bracket notation, handling attribute names with special characters, and nested record structures.

```cedar
{"key": "some value", id: "another value"}

// Accessing attributes
// record["key"] or record.key evaluates to "some value"

// Nested record access examples
// record["some"]["nested"]["attribute"]
// record.some.nested.attribute
// record["some"].nested["attribute"]

// Additional record examples
{}
{"foo": 2, bar: [3, 4, -47], ham: "eggs", "hello": true }
```

--------------------------------

### Cedar Set Data Type Examples

Source: https://docs.cedarpolicy.com/policies/syntax-datatypes.html

Demonstrates the construction and usage of Set data types in Cedar. Sets are collections of elements, which can be of the same or different types. The examples show non-empty sets with mixed types, single-type sets, empty sets, and sets containing expressions and nested structures. It also highlights validation rules for sets in Cedar policies.

```cedar
// a set of three elements, two of type long, and one of type string
[2, 4, "hello"]

// a set of a single type long
[-1]

// an empty set
[ ]

// a set with a Bool expression, a nested set, and a Bool value
[3<5, ["nested", "set"], true]
```

--------------------------------

### Permit access for any entity or action in Cedar

Source: https://docs.cedarpolicy.com/policies/policy-examples.html

Illustrates how to create wildcard policies that allow any authenticated principal to perform an action, or allow a specific principal to perform any action on a resource.

```Cedar
permit(
  principal,
  action == Action::"view", 
  resource in Album::"alice_vacation"
);

permit(
  principal == User::"alice", 
  action in [Action::"listAlbums", Action::"listPhotos", Action::"view"],
  resource in Account::"jane"
);

permit(
  principal == User::"alice", 
  action,
  resource in Album::"jane_vacation"
);
```

--------------------------------

### Unary Operator Example (Logical NOT)

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Demonstrates the usage of a unary operator, specifically the logical NOT operator (!). It takes a single boolean operand and returns its inverse.

```cedar
! a
```

--------------------------------

### Cedar Schema: PhotoFlash Application Example

Source: https://docs.cedarpolicy.com/schema/human-readable-schema.html

A comprehensive example of a Cedar schema for the hypothetical PhotoFlash application. It defines entities like User, Album, Account, and Photo, along with actions such as uploadPhoto, viewPhoto, and listAlbums.

```cedar
namespace PhotoFlash {
  entity User in UserGroup = {
    "department": String,
    "jobLevel": Long,
  };
  entity UserGroup;
  entity Album in Album = {
    "account": Account,
    "private": Bool,
  };
  entity Account = {
    "admins"?: Set<User>,
    "owner": User,
  };
  entity Photo in Album = {
    "account": Account,
    "private": Bool,
  };
  action "uploadPhoto" appliesTo {
    principal: User,
    resource: Album,
    context: {
      "authenticated": Bool,
      "photo": {
        "file_size": Long,
        "file_type": String,
      },
    }
  };
  action "viewPhoto" appliesTo {
    principal: User,
    resource: Photo,
    context: {
      "authenticated": Bool,
    }
  };
  action "listAlbums" appliesTo {
    principal: User,
    resource: Account,
    context: {
      "authenticated": Bool,
    }
  };
}
```

--------------------------------

### Define Forbid Policies for Access Constraint

Source: https://docs.cedarpolicy.com/policies/policy-examples.html

Examples of using 'forbid' policies to explicitly deny access. These policies take precedence over 'permit' policies and use 'unless' clauses to define exceptions to the denial.

```Cedar
forbid (
  principal == User::"alice",
  action,
  resource
)
unless {
  action in Action::"readOnly"
};
```

```Cedar
forbid (
  principal,
  action,
  resource
)
when {
  resource.private
}
unless {
  principal == resource.owner
};
```

--------------------------------

### Permit access to individual entities in Cedar

Source: https://docs.cedarpolicy.com/policies/policy-examples.html

Demonstrates how to write a policy that grants a specific principal permission to perform a single action on a specific resource.

```Cedar
permit(
  principal == User::"alice", 
  action == Action::"view", 
  resource == Photo::"VacationPhoto94.jpg"
);
```

--------------------------------

### Define Record and Entity Schema Types

Source: https://docs.cedarpolicy.com/schema/human-readable-schema.html

Examples showing how to declare complex record types and entity structures with attributes in Cedar schema files.

```Cedar
{
  name: String,
  features: {
    age: Long,
    height: Long,
    eyecolor: String
  }
}

entity List {
  owner: User,
  flags: {
    organizations?: Set<Org>,
    locales?: Set<Location>,
    tags: Set<String>,
  },
};
```

--------------------------------

### Cedar Policy Example with 'is' Expression

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

This example demonstrates a Cedar policy that uses an 'is' expression to check the type of a resource and a condition to verify ownership. The validator uses schema information to determine the type of 'principal' and 'resource' to ensure the expression's validity.

```cedar
permit(principal, action == Action::"view", resource)
when {
  resource is Photo && resource.owner == principal
};

```

--------------------------------

### Instantiate a template-linked policy

Source: https://docs.cedarpolicy.com/policies/templates.html

This example demonstrates how a template-linked policy resolves placeholders into concrete values, such as 'UserGroup::"friendsAndFamily"' and 'Album::"vacationTrip"', while maintaining the underlying template logic.

```Cedar
permit (
  principal in UserGroup::"friendsAndFamily",
  action in [Action::"view", Action::"comment"], 
  resource in Album::"vacationTrip"
)
unless {
  resource.tag =="private"
};
```

--------------------------------

### Define Context for Cedar Evaluation

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Example JSON structure representing the context object used for evaluating attribute presence in Cedar policies.

```JSON
"context":{
    "role": ["admin", "user"],
    "addr": { "street": "main", "city": "DC"},
    "owner info": { "name": "Alice", "age": 18 }
}
```

--------------------------------

### Prevent Cedar Code Injection with Policy Templates

Source: https://docs.cedarpolicy.com/other/security.html

Demonstrates how dynamic policy creation using string concatenation can lead to Cedar code injection vulnerabilities. It recommends using policy templates instead of string concatenation for safer policy generation.

```cedar
 let src = "permit (" + input + ", action == Action::\"view\", resource) when { principal.level > 3 }";
 let policy = parse(src);
 addToPolicySet(policy);

```

```cedar
 permit (principal == User::"alice", action == Action::"view", resource) when { principal.level > 3 };

```

```cedar
 "principal,action,resource); //"

```

```cedar
 permit (principal,action,resource); //, action == ,Action::"view", resource) when { principal.level > 3 };

```

--------------------------------

### Cedar '.contains()' Function Examples

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Examples illustrating the usage of the '.contains()' function in Cedar for checking if a set contains a specific element. It covers valid and invalid use cases, including type matching and heterogeneous sets. The receiver must be a Set, and the argument must be of the same type as the set elements.

```cedar
[1,2,3].contains(1)                             //Evaluates to true //Validates
[1,"something",2].contains(1)                   //Evaluates to true //Doesn't validate (heterogeneous set)
[1,"something",2].contains("Something")         //Evaluates to false (string comparison is case-sensitive) //Doesn't validate (heterogeneous set)
["some", "useful", "tags"].contains("useful")   //Evaluates to true //Validates
[].contains(100)                                //Evaluates to false // Doesn't validate (has empty-set literal)
context.role.contains("admin")                  //Evaluates to true (if the `context.role` set contains string "admin") //Validates
[User::"alice"].contains(principal)             //Evaluates to true (if principal == User::"alice") //Validates
"ham and ham".contains("ham")                   //error - 'contains' is not allowed on strings

```

--------------------------------

### Accessing Entity Attributes with Dot and Index Notation (Cedar)

Source: https://docs.cedarpolicy.com/policies/syntax-entity.html

Demonstrates how to access entity attributes using both dot notation (entity.attribute) and indexing notation (entity["attribute"]). These methods are interchangeable for retrieving attribute values.

```Cedar
SomeUser.name                  // SomeUser is an entity of type user
SomeEmployee.department        // SomeEmployee is an entity of type employee
SomePhoto.description          // SomePhoto is an entity of type photo.

SomeUser["name"]
SomeEmployee["department"]
SomePhoto["description"]
```

--------------------------------

### Cedar Permit Policy with Resource Owner Condition

Source: https://docs.cedarpolicy.com/policies/syntax-policy.html

This example demonstrates a Cedar policy that permits a principal to edit a photo resource, with a condition that the principal must be the owner of the photo.

```cedar
permit (
    principal, 
    action == Action::"editPhoto", 
    resource
)
when {
   resource.owner == principal
};

```

--------------------------------

### Granting resource creation permissions in Cedar

Source: https://docs.cedarpolicy.com/bestpractices/bp-resources-containers.html

Examples of Cedar policies that authorize the 'createFile' action by targeting specific container resources like folders or account boundaries.

```Cedar
permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);
```

```Cedar
// Grants permission to create files within an account,
// or within any sub-folder inside the account.
permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);
```

--------------------------------

### String Matching with 'like' Operator

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Explains and demonstrates the 'like' binary operator for string matching with wildcard support. The wildcard '*' matches zero or more characters. Escaping '*' with '\*' matches a literal asterisk.

```cedar
context.location like "s3:*"
"eggs" like "ham*"
"eggs" like "*ham"
"eggs" like "*ham*"
"ham and eggs" like "ham*"
"ham and eggs" like "*ham"
"ham and eggs" like "*ham*"
"ham and eggs" like "*h*a*m*"
"eggs and ham" like "ham*"
"eggs and ham" like "*ham"
"eggs, ham, and spinach" like "ham*"
"eggs, ham, and spinach" like "*ham"
"eggs, ham, and spinach" like "*ham*"
"Gotham" like "ham*"
"Gotham" like "*ham"
"ham" like "ham"
"ham" like "ham*"
"ham" like "*ham"
"ham" like "*h*a*m*"
"ham and ham" like "ham*"
"ham and ham" like "*ham"
"ham" like "*ham and eggs*"
"\\afterslash" like "\\*"
"string\\with\\backslashes" like "string\\with\\backslashes"
"string\\with\\backslashes" like "string*with*backslashes"
"string*with*stars" like "string\*with\*stars"
```

--------------------------------

### Allow Self-Read Access Policy in Cedar

Source: https://docs.cedarpolicy.com/policies/syntax-entity.html

A Cedar policy example that permits any principal to perform the 'readUser' action on a resource, but only when the principal and the resource are the exact same entity. This is useful for scenarios like user directories where users can access their own data.

```cedar
// Allow every user to read their own data in the user directory
permit (
    principal,
    action == Action::"readUser",
    resource
)
when {
    principal == resource // The same entity
};

```

--------------------------------

### Cedar Policy Validation Soundness Proof in Lean

Source: https://docs.cedarpolicy.com/policies/validation.html

This snippet demonstrates the use of the Lean programming language and theorem prover to formally prove the validation soundness property of Cedar's policy validator. This was part of a novel verification-guided development process.

```Lean
theorem validation_soundness_proved:
  ∀ policy schema request, validate(policy, schema) →
  ¬ (∃ err, evaluate(policy, schema, request) = Error err ∧ is_validation_error err)
-- Note: This is a conceptual representation. Actual Lean code would be more detailed.
```

--------------------------------

### Cedar Policy Evaluation with Normalized Data

Source: https://docs.cedarpolicy.com/bestpractices/bp-normalize-data-input.html

An example of a Cedar policy that relies on normalized input fields. It demonstrates how inconsistent formatting, such as case sensitivity or extra slashes, can cause policy evaluation to fail.

```cedar
permit (principal, action, resource)
when {
    context.url.host == "example.com" &&
    context.url.path == "/path/to/page"
};
```

--------------------------------

### Method-Style Function Call (Contains Any)

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Demonstrates the method-style function call, where the function name is appended to the target parameter with a period, and operands are in parentheses. The 'containsAny' example checks if any element from a set is present in another set.

```cedar
a.containsAny([b, c, d])
```

--------------------------------

### Conditional Logic Example in Java

Source: https://docs.cedarpolicy.com/policies/syntax-operators.html

Demonstrates a conditional expression in Java that, while syntactically valid, contains a type mismatch that would not pass static type checking. This highlights a difference in validation strictness compared to Cedar.

```java
if (false) { return 1 == "hello"; } else { return true; }
```

--------------------------------

### Cedar EntityTypes Grammar

Source: https://docs.cedarpolicy.com/schema/json-schema-grammar.html

Defines the structure for listing entity types within a Cedar schema. It starts with the keyword 'entityTypes' followed by a JSON object containing individual entity type definitions.

```plaintext
EntityTypes ::= 'entityTypes' ':' '{' [ EntityType { ',' EntityType } ] '}'
```

--------------------------------

### Forbid Access to Private Resources - Cedar

Source: https://docs.cedarpolicy.com/overview/scenario.html

This policy enforces a security rule where only the owner of an account can access resources tagged as 'private'. It uses 'forbid' with 'when' and 'unless' clauses to define the conditions under which access is denied, regardless of other permits.

```cedar
// Only the owner can access any resource tagged "private"

forbid ( principal, action, resource )
when { resource.tags.contains("private") }    // assumes that resource has "tags"
unless { resource in principal.account };     // assumes that principal has "account"

```

--------------------------------

### Permit Access to Photos in an Album - Cedar

Source: https://docs.cedarpolicy.com/overview/scenario.html

This policy allows members of the 'janeFriends' group to view and comment on any photo within the 'janeTrips' album. It leverages the 'in' operator, which works transitively, ensuring access to nested albums and their contents as well.

```cedar
// Jane's friends can view all photos in her janeTrips album

permit (
    principal in Group::"janeFriends",
    action in [Action::"view", Action::"comment"],
    resource in Album::"janeTrips"
);

```

--------------------------------

### Define and Use Common Types in Cedar Schema

Source: https://docs.cedarpolicy.com/schema/schema.html

Demonstrates how to define a reusable 'commonContext' type and apply it to multiple actions ('view' and 'upload') in a Cedar schema. This avoids redundant attribute definitions.

```cedar
type commonContext = {
    ip: ipaddr,
    is_authenticated: Bool,
    timestamp: Long
};

action view appliesTo {
    context: commonContext
};

action upload appliesTo {
    context: commonContext
};
```

--------------------------------

### Define Cedar Entities (Principal, Action, Resource)

Source: https://docs.cedarpolicy.com/policies/syntax-datatypes.html

Entities represent principals, actions, or resources in Cedar. They are defined using a 'namespace::type::"unique-identifier"' format. Examples show different entity types like File, Action, User, and nested namespaces.

```cedar
// A resource of type File
File::"myfile.txt"

// An action to allow reading a resource of type File
Action::"ReadFile"

// A principal of type User with a full UUID as 
// the entity identifier and its friendly name in comments
User::"a1b2c3d4-e5f6-a1b2-c3d4-EXAMPLE11111"

// A principal of type User in a Namespace PhotoFlash
PhotoFlash::User::"alice"

// A principal of type File in a nested namespace
Nested::Namespace::App::File::"myFile.txt"
```

--------------------------------

### Create Decimal Values with decimal()

Source: https://docs.cedarpolicy.com/policies/syntax-datatypes.html

Illustrates how to create decimal values using the decimal() function. Decimal values have a whole number part and a decimal part with up to four digits. The function requires a string literal for validation.

```cedar
decimal("12345.1234")
```

--------------------------------

### Defining Namespaced Entities in Cedar

Source: https://docs.cedarpolicy.com/overview/terminology.html

Demonstrates the use of namespace prefixes separated by double colons to resolve ambiguity between identical entity types across different services or product lines.

```Cedar
Database::Action::"createTable"
Database::Table::"c7b981f1-97e4-436b-9af9-21054a3b30f1"
Furniture::Action::"createTable"
Furniture::Table::"c7b981f1-97e4-436b-9af9-21054a3b30f1"

ExampleCo::Database::Table::"c7b981f1-97e4-436b-9af9-21054a3b30f1"
ExampleCo::Furniture::Table::"c7b981f1-97e4-436b-9af9-21054a3b30f1"
ExampleCo::This::Is::A::Long::Name::For::Something::"12345"
```