Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions authzed/api/materialize/v0/brokenpermissions.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
syntax = "proto3";
package authzed.api.materialize.v0;

import "authzed/api/v1/core.proto";

option go_package = "github.com/authzed/authzed-go/proto/authzed/api/materialize/v0";
option java_multiple_files = true;
option java_package = "com.authzed.api.materialize.v0";

service BrokenPermissionsService {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be BrokenWatchedPermissionsService? I'm also not opposed to leaving it as-is

Suggested change
service BrokenPermissionsService {
service BrokenWatchedPermissionsService {

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all cycles detected during the hydration process.
BrokenWatchedPermissionsService

These don't line up; I think we should just use BrokenPermissionsService, since these will be found during LPS

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? They could also happen during updates, wouldn't they?

// ReadBrokenWatchedPermissions returns all cycles detected during
// the hydration process.
//
// Each cycle a circular dependency in the permission graph.
// The response includes the broken permission, along with the resources involved in each cycle.
rpc ReadBrokenWatchedPermissions(ReadBrokenWatchedPermissionsRequest) returns (stream ReadBrokenWatchedPermissionsResponse) {}
}

message ReadBrokenWatchedPermissionsRequest {
// optional_at_revision defines the specific revision at which the broken watched permissions should be evaluated.
// At this time, it is only compared against the revision of the provided backing store snapshot.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow this. The first line is sufficient to explain the semantics, I'd drop it.
Also please clarify that if no argument is provided, the server will use the latest available revision.

authzed.api.v1.ZedToken optional_at_revision = 2;
}

message ReadBrokenWatchedPermissionsResponse {
// revision is the ZedToken at which the request was evaluated.
authzed.api.v1.ZedToken revision = 1;
// The watched permission that broke.
BrokenWatchedPermission watched_permission = 2;
// The resources involved in the cycle. The resource order does not represent the cycle traversal order.
repeated Resource cycle = 3;
}

message BrokenWatchedPermission {
// resource_type is the type of the resource to watch for changes.
string resource_type = 1;
// permission is the permission to watch for changes.
string permission = 2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The part that gives me a pause is the fact you could technically use a relation here too.
Perhaps I'd rename it to resource_relation, so it also looks symmetric when we eventually add subject_type and subject_relation.

Or you could use resource_permission_or_relation but that seems loooong

}

message Resource {
// object_type is the type of the resource.
string object_type = 1;
// object_id is the id of the resource.
string object_id = 2;
// permission_or_relation is the resource's permission or relation.
string permission_or_relation = 3;
}