lurenpluto
commented
1 year ago On an existing basis codes with ACL and protocols, consider a version of the design as follows:
1. Add handler permission to rmeta
The upgraded access types are as follows:
#[derive(Clone, Debug, Serialize, Deserialize, Eq, PartialEq)]
pub enum GlobalStatePathGroupAccess {
Specified(GlobalStatePathSpecifiedGroup),
Default(u32 /*AccessString*/),
Handler, // New Type, should be handled by the dec's acl handler
}2. Reuse the previous handler.acl event
This event once played the role of acl callback in the old ACL mechanism, but after the ACL was restructured into a new logic, this event has been deprecated but still retained. We can reactivate this event, but the Request needs to be redesigned and should include the following fields:
pub struct AclHandlerRequest {
pub dec: ObjectId,
pub path: String,
pub source: RequestSourceInfo,
pub permissions: AccessPermissions,
}3. rmeta management
We can use add_access and remove_access to set the handler permission for a global-state path. When a request needs to use rmeta for verification, it matches the corresponding path. If it corresponds to a handler, it will call the ACL event registered by the corresponding dec for dynamic judgment, thus determining whether the request is rejected or accepted.
4. Custom token for requests
Since the ACL handler is a general rmeta processing mechanism, all places that need to use rmeta to handle permissions need to support custom tokens. It is somewhat difficult to recklessly add a field to many different request modes, so after researching, we consider adding it to the composite structure of req-path:
RequestGlobalStatePathSince req-path itself is a composite structure, you can refer to the design pattern of URLs, providing parameters in the form of ? followed by the parameter, like:
{dec-id}/a/b/c?token=xxxHowever, note the following two points:
-
In the 'o' link protocol, the req-path itself is passed through the URL query pairs parameters. So, if you need to add a token parameter in the req-path, you must escape the characters ? and & (at least the & symbol) to avoid the token not being recognized by the req-path parameters.
-
In the 'r' link protocol, since the req-path itself is a part of the URL path, the token needs to be carried separately in the 'r' protocol. Additionally, since the internal implementation of the 'r' protocol relies on the global-state accessor mechanism, the accessor mechanism also needs to add relevant support for the token field.
streetycat
lizhihongTest
The current permission system has two layers: rmeta and object access, with the following characteristics:
These two levels of permissions can handle many static configurations but are insufficient for some dynamic permission scenarios, such as:
A DEC needs to share a specific resource with others and sets a token (maybe a random password string). As long as others know this token, they can access the resource. The shared token has an expiration time, after which others will no longer have access.
This is a typical token-based sharing mechanism, with tokens being custom-generated and validated by each DEC. Tokens can be a random password or a public key format, etc.
The protocol stack needs to consider how to support this form of dynamic permission. It is reasonable to add it to the rmeta layer, as introduced from the beginning. Since DEC validation is required, the handler system also needs to be involved. The DEC can dynamically handle permission validation requests for each rmeta to determine whether to grant or deny access.