Does not work when logged out:
https://meta.discourse.org/u?exclude_groups=admins&order=likes_received
Logged out:
Logged in:
I stumbled across this because I noticed when logged out of my own forums, I’m no longer excluded from users sorted by likes received.
Is this deliberate to expose members of the admin group even when /u?exclude_groups=admins is set?
I think this might happen because the members of the admin groups are not available for users who are not logged in by default. You can try that, for example, with Meta’s admin group https://meta.discourse.org/g/admins.
You can configure that in the group’s settings, which should solve your problem (I haven’t tested it).
If you could filter the user directory by a group which you don’t know about or where you are not allowed to see its members, that would leak information. This might not be that relevant for the admin group, but imagine you could filter the user directory for the hidden Enterprise customer groups on Meta.
Before posting I did visit https://meta.discourse.org/g/admins which is hidden from users not logged in. Which is why I started the topic. /g/admins is hidden for unregistered users, but they can still see members of Admin group when visiting /u?exclude_groups=admins which seems, at least, strange.
Edit:
Just confirmed my forums are already set to “Logged on users” only:
Still admins are visible on /u?exclude_groups=admins page, like they are also on this forum: Hidden to non-members on /g/admins but visible/listed in /u?exclude_groups=admins even for those not logged in.
Now I am confused. Based on the title, I expected /g/admins and /u?exclude_groups=admins to both work for logged-in users, while they don’t work for users who are logged out.
Maybe we are talking about different states of “hidden” on the groups page:
With “hidden,” I meant something like private - visiting /g/admins does lead logged-out users to the oops page. I think you might be thinking of the fact that most users don’t see the default groups on the groups page (except for moderators) because some additional code hides them. But even though the groups are not shown on the groups page, looking at the page of the group is possible for users clicking a link.
The private hidden is what makes the group secret and is the reason why I think it makes sense that the filter on the user directory doesn’t work. It would leak information. The group that is simply not shown, is not secret.
So you limit it to users who are logged in. If you want visitors to have access to the group, why do you limit visibility and access to the members instead of choosing “everyone”?
Logged out, and URL = /u?exclude_groups=admins:
Sorry if I’m misunderstanding. I thought /u?exclude_groups=admins means that admins are not included in the list? No.
Currently they are only excluded only when logged in but when logged out they are included.
It would be nice if /u?exclude_groups=admins worked for both registered and unregistered visitors.
Can you expand on what you want to tell me with that screenshot?
I see you limit access to the group to logged-in users. You also limit access to the group’s members to logged-in users.
Then you show me that a user who is not logged in cannot access the data of the group members. To me, that makes sense. I would only expect that to work if you had chosen “everyone” in both settings.
It feels like you are saying, “I want to hide the data on who is in the admin group from visitors.” But at the same time, you complain that the data isn’t available to filter the user directory.
You cannot exclude the members of a group when you are not allowed to know who is in it.
Just echoing what @Moin said here. If we made exclude_groups=admins work, then someone could deduce the members of the admin group, even though they’re not supposed to have access.
So I’m afraid this is intentional, and unlikely to change. If you want people to be able to work out the members of the admins group, you’ll need to make it visible to everyone.
The same logic applies to anyone who just registers though. If a brand new user signs up and uses exclude_groups=admins, the admins get hidden from their list, so they can already deduce the membership by comparing filtered and unfiltered.
The bar to “working it out” is just creating a free account, which anyone can do in seconds. So what’s the real difference between a logged-out visitor and a one-minute-old account here?
For context, all I’m actually trying to achieve is in the sidebar plugin there’s a ranking, and I just don’t want the admins group included in the “most likes received” or top contributors list.
That depends on the site configuration - many sites do not have open registration.
So adjusting the visibility of the group should be a good workaround? Or is there a problem with that?
A LOT of them do. Most that I visit
Yeah that’s certainly true. But when it comes to security features, we have to design things to work precisely as they’re described. If someone decides to hide group membership, that needs to work 100% reliably.
Why don’t you change the visibility of the admin group and its members to “everyone” to achieve that? Then the data would be available to visitors and the filter should work. Especially when you say anyone can log in and visit /g/admins, it shouldn’t matter if logged-out users could too.
The thing is, hiding membership isn’t really reliable here anyway. On a lot of forums, mine included, the admins are some of the most active users. So you can just sort the directory by activity and usually spot an admin or two right away.
The admin group membership is easily deduced from exposed activity. Especially since https://meta.discourse.org/u already defaults to sorting by activity:
Sure, you could hide all profiles too. But my point is that the security advantage being claimed in current ignoring of /u?exclude_groups=admins seems little to none, or superficial at best.
So registering doesn’t really add security in this case. Logged out or just create an account, you can work out the admins by sorting, because their activity levels stay public even when I’m trying to keep them out of the list with /u?exclude_groups=admins.
That’s actually why I reported it in the first place. If hiding admins were a deliberate security feature, you’d expect it to prioritize keeping non-users from working it out. But as it stands it’s the opposite: someone logged out can figure it out more easily by just visiting most default: /u.
That inversion is what made me think it was maybe not intended.
Edit:
For me, back to the main issue, its not even about security. That’s a point raised on your end. I would just like the activity of admin not in the rankings for the sidebar plugin and the /u page.
I do see your point, but it’s important to consider that the group security system is not specific to the @admins group. The same security model would need to work for the @super-secret-lurkers group, if a forum had one 
Being able to work out ‘not in a group’ is ultimately the same as being able to see ‘in a group’.
Yup, makes sense. Does updating the admins group to be visible to ‘everyone’ work for you?
No I tried that before opening. Thought maybe non-members had to be able to see the group for the exclusion to work. 
But no, /u?exclude_groups=admins is ignored entirely for unregisted visitors.
It is not about hiding the users, but hiding the information about who is a member of a group. That’s why you can see the members of a hidden group in the directory, but you cannot see the group’s page. You know the user exists, but you don’t know if they belong to a secret group.
For example, you have a group for customer-A, but you don’t want other users of your forum to know that this group exists. Then you limit the visibility of the group, but of course the members are visible everywhere else. You can see them posting and in the user directory. But you don’t know that they are in the customer-A group.
In the same way you limit the visibility of the admin group. Visitors are not allowed to know who is in the group. But they are allowed to know that these users use the forum.
You can already see who’s in the admins @Moin when logged out. Not everyone all at once.
not logged in:
But that was not my issue here about secrecy or security:
No I only toggled the “Who can see this group’s members?”
I don’t want the “Who can see this group” enabled because that allows the /g/admins public accessed.
But I can test to test to see if it causes /u?exclude_groups=admins to be honored.
brb
