[Fixes #13581] Forbid API changing permissions for anonymous and registered members users if user is not allowed to

[sijandh35]

This PR Fixes #13581

This PR should only be merged after the issue(#13578 ) is merged.

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

For all pull requests:

• Confirm you have read the contribution guidelines
• You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
• Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

• There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
• The issue connected to the PR must have Labels and Milestone assigned
• PR for bug fixes and small new features are presented as a single commit
• PR title must be in the form "[Fixes #<issue_number>] Title of the PR"
• New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented

Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

[codecov]

Codecov Report

❌ Patch coverage is 88.59649% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.03%. Comparing base (ff24fb6) to head (9335f5a).
⚠️ Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #13592      +/-   ##
==========================================
+ Coverage   74.00%   74.03%   +0.02%     
==========================================
  Files         932      932              
  Lines       55471    55573     +102     
  Branches     7476     7487      +11     
==========================================
+ Hits        41054    41144      +90     
- Misses      12786    12794       +8     
- Partials     1631     1635       +4     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[giohappy]

@sijandh35 Instead of doing all this logic (including retrieving the Group objects from the DB), shouldn't we just discard the anonymous and registered_members permissions from the perms payload in case the user doesn't have permissions to change it?

I mean:

• We check if the user doesn't have can_manage_anonymous_permissions or can_manage_registered_member_permissions
• In that case, we remove the two groups from request.data.get("groups") without throwing any exception
• The other changes will go through, but the permissions for the two groups remain unchanged

Maybe we can also avoid the check with the grups id, and just rely on the group name? This would save a DB query.

[sijandh35]

@sijandh35 Instead of doing all this logic (including retrieving the Group objects from the DB), shouldn't we just discard the anonymous and registered_members permissions from the perms payload in case the user doesn't have permissions to change it?

I mean:

• We check if the user doesn't have can_manage_anonymous_permissions or can_manage_registered_member_permissions

• In that case, we remove the two groups from request.data.get("groups") without throwing any exception

• The other changes will go through, but the permissions for the two groups remain unchanged

Hi @giohappy Updated it.

Maybe we can also avoid the check with the grups id, and just rely on the group name? This would save a DB query.

Yes, using the group name would reduce the need for the query to fetch the group object. However, from what I see on the client side, when a permission is changed, a PUT request is made, and in the groups key it only sends the ID and permissions — for example: [{'id': 3, 'permissions': 'view'}, {'id': 2, 'permissions': 'edit'}]. That’s why I used the ID.

But if we can pass the group name also from client, that would be better.