-
Notifications
You must be signed in to change notification settings - Fork 890
Make listing users and groups a privileged endpoint #5002
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We need to change this assumption and correct the db calls: Lines 204 to 205 in 88e24db
|
I can take this task unless somebody else planned to work on it. I see 2 approaches we can apply here. Approach 1: Normal users don't see the Users tab
Approach 2: Leave Groups sub-tab
@sharkymark Which approach do you think will be more convenient for customers? From a security perspective, it depends if there can be secret groups, which should be hidden the same way as users. Side issue: |
We are running IT workshops on coder (#5058) and on every workshop start I have to talk with the participants about leaking there eMails addresses or may use fake addresses to register. Would be good to know if and how this behaviour will be changed in future. May we have to use 'synthetic' emails addresses for every user, but this is a more or less ugly workaround. With other words, a solution from coder would be very nice. |
Just want to add if we remove the I wonder if this is something orgs can do. Preventing users from seeing members in different organizations. |
@sharkymark Should we always hide groups? Should there be public and private groups? Should we show private groups if you are a member? Should we hide all users always to other members? |
Let's only show user what groups they are in, perhaps in the account dropdown as pills.
would users be able to join public groups? is that how it works? I don't think we need to do this immediately
yes
Let's only show user what groups they are in, perhaps in the account dropdown as pills. |
Uh oh!
There was an error while loading. Please reload this page.
Objective
created_by
will be kept on templates, workspace builds, etc. This will require theread
permission on the primary resource being fetched. Included user info will beusername
andavatar_url
.Related:
Version:
v0.12.5+165b6fb
I'll post again for visibility but it seems like an anti-pattern to show the Users UI to any user.
This view shows users' roles so a form of social engineering could occur.
Groups are shown as well, which does seem secure.
If the other issue is being worked, great, but empathizing again.
Lastly, if a large deployment, this is a waste of DB calls if someone bounced onto it.
The text was updated successfully, but these errors were encountered: