Open renyuneyun opened 7 months ago
Hi @renyuneyun , thanks for reaching out.
I understand your concerns, but I think it is correct that a given Access Control Resource may have several Access Controls, and having the acp:AccessControl
type is implicit. For instance, it is omitted in https://solidproject.org/TR/acp#example-access-control.
Is it accurate to say that the graph isn't isomorphic to what you would prefer, but it is semantically equivalent and results in access policies being applied accurately?
Hi @NSeydoux , thanks for looking into this.
Yes, you are right, it is semantically equivalent, and the policies are applied accurately.
I understand that they may have implicit types, and actually would be more inclined to not requiring an explicit type (because it should be inferrable in principle). Although, 1) the solid-client library actually assumes explicit typing and relies on that heavily for ACP; 2) for the manipulation, I would believe it is a better idea to explicitly type every new node the library creates.
Apart from that, the main issue I see is the (seemingly) inconsistency between the code and the actual behaviour, particularly the item 2 and this line of the library (which is called by acp_ess_2.setResourcePolicy()
). The code seems to suggest that no new acp:AccessControl
node should be created, while in reality it creates a new node (without explicitly giving it a type acp:AccessControl
), and named it #defaultAccessControl
.
The behaviour seems to be more aligned with this addPolicyUrl()
function in policy/addPolicyUrl.ts
, rather than the imported control.ts#addPolicyUrl()
.
So, again, this routes back to my question (in the other recent issues) on the relation between these same-name similar-purpose different-implementation functions under different files / directories, and the possibility of them messing up the code.
Search terms you've used
Bug description
I'm following the official document to create a policy (rule) in ACP. The policy was successfully created, and seems to be interpreted by Solid (CSS). However, if I look into the .acr document, things are not as expected.
There are three strange behaviours:
#defaultAccessControl
) foracp:AccessControl
instead of using an existing one (because this line refers to a function which should reuse an existingacp:AccessControl
);a acp:AccessControl
for its type.To Reproduce
Minimal reproduction
See this gist for the example
.acr
file: https://gist.github.com/renyuneyun/834eb5ee542e06a2cc3ee1a57712ca3f. To reproduce, remove, <#defaultAccessControl>
at line 6 and remove line 25-31, and put it to the .acr file.Expected result
acp:AccessControl
node being used;acp:AccessControl
as its type.Actual result
See comment under the gist for the actual
.acr
file after the operation.Environment
Additional information