Allow unauthenticated users to view group details

[linear[bot]]

ABA-509 Viewing groups when not logged in gives 401

Either they should be public, or not visible on the sidebar as pages at all .. I think a fine solution is to make the groups public, but to not show its members. Webapp would need minimal changes to accommodate this. [image.png](https://uploads.linear.app/cc88c5d4-7abd-4e69-a02e-46c77f9a4f98/5d02d5ea-82ab-4e15-8783-5cd40e89db07/9e69ffe6-368c-480b-b41f-3a2885cecafd)

[ivarnakken]

I know the perm system is overly conplex. But it might be better to use the safe_perms property (or something like that). I think it's on the handler class. But a quick grep should lead you to it.

@LudvigHz There is nothing called safe_perms, but are you referring to safe_methods in PermissionHandler? If so, the safe_methods attribute by itself does not grant permissions; it merely defines which actions are considered "safe" or non-modifying. The actual permission checks are performed in methods such as has_perm and has_object_permissions? Or am I missing something?

[codecov[bot]]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (2826e4c) 88.29% compared to head (f88af40) 88.29%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #3461 +/- ## ======================================= Coverage 88.29% 88.29% ======================================= Files 662 662 Lines 21005 21006 +1 ======================================= + Hits 18546 18547 +1 Misses 2459 2459 ``` | [Impacted Files](https://app.codecov.io/gh/webkom/lego/pull/3461?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=webkom) | Coverage Δ | | |---|---|---| | [lego/apps/users/permissions.py](https://app.codecov.io/gh/webkom/lego/pull/3461?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=webkom#diff-bGVnby9hcHBzL3VzZXJzL3Blcm1pc3Npb25zLnB5) | `93.65% <100.00%> (+0.10%)` | :arrow_up: | | [lego/apps/users/tests/test\_abakusgroup\_api.py](https://app.codecov.io/gh/webkom/lego/pull/3461?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=webkom#diff-bGVnby9hcHBzL3VzZXJzL3Rlc3RzL3Rlc3RfYWJha3VzZ3JvdXBfYXBpLnB5) | `100.00% <100.00%> (ø)` | |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[LudvigHz]

There is nothing called safe_perms, but are you referring to safe_methods in PermissionHandler? If so, the safe_methods attribute by itself does not grant permissions; it merely defines which actions are considered "safe" or non-modifying. The actual permission checks are performed in methods such as has_perm and has_object_permissions? Or am I missing something?

Yes, that's the one. The default permission handler will check this attribute against the action and allow the method accordingly. So if you set it to view it should allow users to view the objects in the viewset. Although it requires that the group perm handler does not override too much of the behavior already (it really shouldn't)

[ivarnakken]

Yes, that's the one. The default permission handler will check this attribute against the action and allow the method accordingly. So if you set it to view it should allow users to view the objects in the viewset. Although it requires that the group perm handler does not override too much of the behavior already (it really shouldn't)

ah yes I now see that PermissionHandler has a similar check for this in has_perm

        if require_auth and not authenticated:
            return False
        elif not require_auth and perm in self.safe_methods:         # <----------
            return True
        if not authenticated:
            return False

Adding authentication_map = {VIEW: False, LIST: False} sets require_auth to False on VIEW and LIST methods.

Seems to work fine.

[ivarnakken]

Is this all groups now??

I.e. can any person view any group?

Yes, but not its members. I don’t really see anything wrong with letting them be public, but I’m all ears

[LudvigHz]

The only concern was that there are some random groups that are administrative only and not really meant to be accessible by the public. But yeah at least it's not the members but still we might want to have some filter on what is public (in terms of group type (committee, interest group))