Is group management working on the current version?

[Chiyo-no-sake]

I'm trying to implement a document sharing system, and following the WAC specification to grant access to a group of agents, in the following way:

• I have a dataset holding groups on the user's pod at the path /profile/groups.
• Inside that dataset, I created 2 groups: #Company and #Admins (each with type vcard:Group)
• The #Admins group defines the user's webId as a member following the WAC spec
• I then created an ACL file under /profile/groups/.acl, specifying all the modes, the target resource /profile/groups and the acl:agentGroup property, with value the url to the admins group (/profile/groups#Admins)

But still, the user receives 403 when trying to get the data from the pod.
Is there something I am missing?

[bourgeoa]

Could you look at this issue #1442
On CSS access to your /profile/groups should be public.

[Chiyo-no-sake]

While this approach works, I stil have problems in autorizing the read on "normal" (non groups) datasets.
The following is what I am trying to achieve:

• c2 (user) has a pod on /c2, and its webId is located at /c2/profile/card#me

• c1 (user) has a pod on '/c1' and its webId is located at /c1/profile/card#me
  in this pod we have the following setup:

  • /c1/profile/groups (the dataset mentioned in the question)
    • #Admins (thing representing the group)
  • /c1/profile/documents/ (container, will contain all documents for c1)

I want user c2 to be a member of the #Admins group, and grant FULL access to /c1/profile/documents/ to all members of #Admins group.

These are the values of my turtles:

c1/profiles/groups

<#Admins> <http://schema.org/name> "Admins";
    a <http://www.w3.org/2006/vcard/ns#Group>;
    <http://xmlns.com/foaf/0.1/maker> <https://localhost/c1/profile/card#me>;
    <http://www.w3.org/2006/vcard/ns#hasMember> <https://localhost/c1/profile/card#me>, <https://localhost/c2/profile/card#me>.

c1/profile/groups.acl (notice public READ)

<#16708396860224242461812775755> a <http://www.w3.org/ns/auth/acl#Authorization>;
    <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Write>, <http://www.w3.org/ns/auth/acl#Control>, <http://www.w3.org/ns/auth/acl#Append>;
    <http://www.w3.org/ns/auth/acl#accessTo> <https://localhost/c1/profile/groups>;
    <http://www.w3.org/ns/auth/acl#default> <https://localhost/c2-pod-1670839684222/profile/groups>;
    <http://www.w3.org/ns/auth/acl#agentGroup> <https://localhost/c2-pod-1670839684222/profile/groups#Admins>.
<#16708396860268546477660037375> a <http://www.w3.org/ns/auth/acl#Authorization>;
    <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>;
    <http://www.w3.org/ns/auth/acl#accessTo> <https://localhost/c2-pod-1670839684222/profile/groups>;
    <http://www.w3.org/ns/auth/acl#default> <https://localhost/c2-pod-1670839684222/profile/groups>;
    <http://www.w3.org/ns/auth/acl#agentClass> <http://xmlns.com/foaf/0.1/Agent>.

c1/profiles/documents/.acl

<#167083968775109707717489798817> a <http://www.w3.org/ns/auth/acl#Authorization>;
    <http://www.w3.org/ns/auth/acl#accessTo> <https://localhost/c1/profile/documents/>;
    <http://www.w3.org/ns/auth/acl#default> <https://localhost/c1/profile/documents/>;
    <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Read>, <http://www.w3.org/ns/auth/acl#Write>, <http://www.w3.org/ns/auth/acl#Append>, <http://www.w3.org/ns/auth/acl#Control>;
    <http://www.w3.org/ns/auth/acl#agentGroup> <https://localhost/c1/profile/groups#Admins>.

The above configuration results in the following:

• Despite c2 is in Admins group, any read request results in 403 Forbidden
• All request from c1 to the container are successful (Why? If the group is not working this should fail too)
• If I add the webID of c2 directly in the documents ACL file, requests works
• I also tried setting the groupUrl in the agent field (instead of agentGroup) but this doesn't work too.

[joachimvh]

It might be related to #1331. The class responsible for checking group access has a cache which by default expires after one hour. The cache is in-memory so restarting the server clears it. The next major release is going to remove the cache.

This would explain why it works for c1 and not c2 if you did a check first after adding c1 was added, which caused that version of the groups resource to be cached.

[Chiyo-no-sake]

Indeed, building and installing from branch 5c79e60 (latest in branch version 6) resolved the issue, thank you.