Implement Galaxy filters and API key constraints
This commit is contained in:
@@ -37,10 +37,19 @@ The service is defined in
|
||||
|
||||
`DiscoverHierarchy` is a paged unary RPC. The raw request accepts `page_size`
|
||||
and `page_token`; the server defaults omitted page size to 1000 objects and
|
||||
caps every page at 5000 objects. Invalid page tokens and negative page sizes
|
||||
return `InvalidArgument`. Official high-level clients preserve the older
|
||||
caps every page at 5000 objects. Page tokens bind to the cache sequence and the
|
||||
active filter set, so changing filters between pages returns `InvalidArgument`
|
||||
instead of mixing snapshots. Official high-level clients preserve the older
|
||||
"return the full hierarchy" behavior by looping pages internally.
|
||||
|
||||
The request can also slice the cached hierarchy without running new SQL. A
|
||||
caller may choose one root (`root_gobject_id`, `root_tag_name`, or
|
||||
`root_contained_path`) and may combine that with `max_depth`, category ids,
|
||||
template-chain substring filters, an anchored case-insensitive tag-name glob,
|
||||
alarm-only, historized-only, and `include_attributes = false` for a skeleton
|
||||
tree. All filters are applied with AND semantics, and `total_object_count`
|
||||
reports the post-filter count.
|
||||
|
||||
## Hierarchy Cache
|
||||
|
||||
The gateway holds a single shared `IGalaxyHierarchyCache`
|
||||
@@ -145,7 +154,19 @@ message GalaxyAttribute {
|
||||
|
||||
message DiscoverHierarchyRequest {
|
||||
int32 page_size = 1; // omitted/0 uses the server default of 1000
|
||||
string page_token = 2; // opaque offset token returned by the previous page
|
||||
string page_token = 2; // opaque token returned by the previous page
|
||||
oneof root {
|
||||
int32 root_gobject_id = 3;
|
||||
string root_tag_name = 4;
|
||||
string root_contained_path = 5;
|
||||
}
|
||||
google.protobuf.Int32Value max_depth = 6;
|
||||
repeated int32 category_ids = 7;
|
||||
repeated string template_chain_contains = 8;
|
||||
string tag_name_glob = 9;
|
||||
optional bool include_attributes = 10;
|
||||
bool alarm_bearing_only = 11;
|
||||
bool historized_only = 12;
|
||||
}
|
||||
|
||||
message DiscoverHierarchyReply {
|
||||
@@ -249,6 +270,11 @@ privilege to `MxCommandKind.GetSessionState` or `MxCommandKind.GetWorkerInfo`.
|
||||
The mapping lives in `GatewayGrpcScopeResolver`; see
|
||||
[Authorization](./Authorization.md) for the full scope catalog.
|
||||
|
||||
API keys can also carry `browse_subtrees` constraints. `DiscoverHierarchy`
|
||||
intersects those contained-path globs with the caller's request filters.
|
||||
`WatchDeployEvents` still emits deploy notifications, but its object and
|
||||
attribute counts are scoped to the caller's browsable subtrees.
|
||||
|
||||
A request without an API key returns `Unauthenticated`. A request with a key
|
||||
that lacks `metadata:read` returns `PermissionDenied` with the missing scope
|
||||
embedded in the status detail.
|
||||
|
||||
Reference in New Issue
Block a user