GeoNode
Group permission for download do not work
Expected Behavior
- When setting download permission to a group, the members should be allowed to download it, no matter if the "anyone" or the "registered members" can do it or not.
- When setting viewing permission to a group, the members should be allowed to view it, no matter if the "anyone" or the "registered members" can do it or not.
Actual Behavior
- If "anyone" group is set to "none" in the dataset share options, the layer cannot be seen by any user.
- If "anyone" and "registered members" groups are set to "view", the layer cannot be downloaded by any user.
Steps to Reproduce the Problem
- Create a group and add two users in it (A and B, for instance)
- Upload a dataset while logged in as user A
- In layer share options, allow the group members to download the dataset (including user B)
- Define the "anyone" and the "registered members" groups permission to only view the dataset
- Try to download the dataset (using any user, even admin) and receive the error message "Process failed during execution java.lang.IllegalArgumentException: Unable to locate layer: geonode:
"
Specifications
- GeoNode version: 4.1.3
- Installation type (vanilla, geonode-project): vanilla
- Installation method (manual, docker): docker
- Platform: Ubuntu and CentOS
- Additional details:
I identified the same problem using version 4.1.x.
1 - created a group: "group_test" 2 - created the users "user1" and "user2" and associated them with the group "group_test" 3 - logged in as "admin" and in layer X, I set "None" for the "Anyone" and "Registered members" groups, and then assigned the Download permission to the group "group_test" 4 - logged in as "user1" and verified that although layer X appears in the list, "user1" cannot view the content on the map and also cannot download it 5 - logged in as "admin" and changed the permissions, including "View" for the "Registered members" group, and leaving "None" for "Anyone" 6 - logged in as "user1" and verified that layer X still appeared in the list, but it continued to not display the content on the map and there was no option to download it 7 - logged in as "admin" and changed the permissions, including the "View" permission for the "Anyone" group 8 - logged in as "user1" and verified that now layer X correctly appeared on the map
Conclusions:
- When creating a group in Geonode and assigning "None" to "Anyone" and "Registered members" for a specific layer, and then assigning the "Download" permission to the group, it is expected that only users in that group will have "Download" access. But this does not happen.
- When setting "None" for "Anyone" and "View" for "Registered members", it is expected that only logged in users can view the layer. But this also does not happen because registered users still cannot view the layer.
Questions:
- Is this the expected behavior regarding group permissions in Geonode 4.1.x ? Or is this a bug?
- I'm wrong to expect that by revoking permissions for "Anyone" and "Registered members" and assigning the "Download" permission to the group, only group users should have "Download" access (ignoring anonymous and other registered users)?
@davicustodio @mattiagiupponi Well this Problem persists for long now, and @chumanu (https://github.com/GeoNode/geonode/issues/11447#issuecomment-1718694914) already found the underlying issue and its (temporary solution): So the Issue lies in the way Geoserver REST ROLE Service reads the group permissions. Geoserver seems a bit strikt and only understands group roles if they are in caps and start wird ROLE_ (i.e. mygroup will not work, ROLE_mygroup will not work; but ROLE_MYGROUP will work). So what I did, after I read that solution, I deleted my old groups and creates new one. If you create them with teh Admin Panle you can Name them "mygroup" but in the fiel "slug" type ROLE_MYGROUP. If you now add ressources to that group, the Geoserver will create a correct rule and can serve the data for the members.
It works super, as long as you keep the slug correct for Geoserver to understand :)
@saxas13 I tested it here and it really worked. Thank you for the valuable tip. I will be monitoring the progress of #11447
@saxas13 I second this fix. Fortunately one does not need to delete already existing groups since changing the 'slug' in the admin panel to a 'ROLE_GROUP-IN-UPPER-CASE-LETTERS' format also works.
