Skip to content
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.

Sign up for GitHub

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

Jump to bottom

External user permissions #4334

Closed
3 of 4 tasks
muellermartin opened this issue Jun 28, 2018 · 4 comments
Closed
3 of 4 tasks

External user permissions #4334

muellermartin opened this issue Jun 28, 2018 · 4 comments
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Milestone
1.12.0

Comments

@muellermartin
Copy link

muellermartin commented Jun 28, 2018 •
edited by lafriks

GitLab provides a special type of local users called "external users". The current version of GitLab's documentation descibes this role as follows:

In cases where it is desired that a user has access only to some internal or private projects, there is the option of creating External Users. This feature may be useful when for example a contractor is working on a given project and should only have access to that project.

External users can only access projects to which they are explicitly granted access, thus hiding all other internal or private ones from them. Access can be granted by adding the user as member to the project or group.

They will, like usual users, receive a role in the project or group with all the abilities that are mentioned in the table above. They cannot however create groups or projects, and they have the same access as logged out users in all other cases.

This type of user is particulary useful when the Gitea instance is private and a guest/external user should access only specific repositories while the rest is hidden. Currently (as of version 1.4.3) local users can see other repositories when they use the "Explore" functionality even if they are not part of any organization or added as collaborator to these repositories.

Remaining tasks:

  • Filter results when exploring users
  • Filter /org/orgname/dashboard content
  • Ability for external users to create organizations and repositories (separate option for count limit)
  • LDAP option to automatically set restricted user
@lunny lunny added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Jul 6, 2018
mnsh added a commit to stendahls/gitea that referenced this issue Sep 24, 2018
@mnsh
Restricted users model (go-gitea#4334)
2019541 
* Add User.IsRestricted

* Add "Restricted" column to admin/users

* Add "Is Restricted" checkbox to admin/users/ID
mnsh added a commit to stendahls/gitea that referenced this issue Sep 24, 2018
@mnsh
Restricted users access checking (go-gitea#4334)
c371b60 
* Change access.accessLevel to accept a *User instead of a user ID

* Ditto for AccessLevel, hasAccess and HasAccess

* When user is restricted, don't allow read to public repos

* Update all callers to pass a *User object
@mnsh
Copy link
Contributor

mnsh commented Sep 25, 2018

Such a feature would be very useful to any organization using gitea internally with the need to give customers access to their projects.

I propose introducing a new user flag called "IsRestricted", presented as another checkbox in the user admin pages.

A restricted user's view would be limited to:

  • Repos accessible by the user's teams as well as repos where the user is a collaborator
  • Orgs where the user is member of a team
  • Users that are members of teams in those orgs

To put it another way, a restricted user would simply not see or be able to access anything public.

mnsh added a commit to stendahls/gitea that referenced this issue Oct 7, 2018
@mnsh
Restricted users model (go-gitea#4334)
8349d79 
* Add User.IsRestricted

* Add "Restricted" column to admin/users

* Add "Is Restricted" checkbox to admin/users/ID
mnsh added a commit to stendahls/gitea that referenced this issue Oct 7, 2018
@mnsh
Restricted users access checking (go-gitea#4334)
f130b2a 
* Change access.accessLevel to accept a *User instead of a user ID

* Ditto for AccessLevel, hasAccess and HasAccess

* When user is restricted, don't allow read to public repos

* Update all callers to pass a *User object
mnsh added a commit to stendahls/gitea that referenced this issue Oct 18, 2018
@mnsh
Restricted users model (go-gitea#4334)
b7779a5 
* Add User.IsRestricted

* Add "Restricted" column to admin/users

* Add "Is Restricted" checkbox to admin/users/ID
mnsh added a commit to stendahls/gitea that referenced this issue Oct 18, 2018
@mnsh
Restricted users access checking (go-gitea#4334)
b9b1bdb 
* Change access.accessLevel to accept a *User instead of a user ID

* Ditto for AccessLevel, hasAccess and HasAccess

* When user is restricted, don't allow read to public repos

* Update all callers to pass a *User object
mnsh added a commit to stendahls/gitea that referenced this issue Nov 3, 2018
@mnsh
Restricted users model (go-gitea#4334)
f6cc7e2 
* Add User.IsRestricted

* Add "Restricted" column to admin/users

* Add "Is Restricted" checkbox to admin/users/ID
mnsh added a commit to stendahls/gitea that referenced this issue Nov 3, 2018
@mnsh
Restricted users access checking (go-gitea#4334)
1eea977 
* Change access.accessLevel to accept a *User instead of a user ID

* Ditto for AccessLevel, hasAccess and HasAccess

* When user is restricted, don't allow read to public repos

* Update all callers to pass a *User object
@mnsh mnsh mentioned this issue Mar 8, 2019
Merged
mnsh added a commit to stendahls/gitea that referenced this issue Sep 2, 2019
@mnsh
Restricted users (go-gitea#4334): initial implementation
9335044 
* Add User.IsRestricted & UI to edit it

* Pass user object instead of user id to places where IsRestricted flag matters

* Restricted users: maintain access rows for all referenced repos (incl public)

* Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses

* Add basic repo access tests for restricted users

Signed-off-by: Manush Dodunekov <manush@stendahls.se>
mnsh added a commit to stendahls/gitea that referenced this issue Jan 6, 2020
@mnsh
Restricted users (go-gitea#4334): initial implementation
836f9d8 
* Add User.IsRestricted & UI to edit it

* Pass user object instead of user id to places where IsRestricted flag matters

* Restricted users: maintain access rows for all referenced repos (incl public)

* Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses

* Add basic repo access tests for restricted users

Signed-off-by: Manush Dodunekov <manush@stendahls.se>
sapk added a commit that referenced this issue Jan 13, 2020
@mnsh @sapk @lafriks
Restricted users (#6274)
1751d5f 
* Restricted users (#4334): initial implementation

* Add User.IsRestricted & UI to edit it

* Pass user object instead of user id to places where IsRestricted flag matters

* Restricted users: maintain access rows for all referenced repos (incl public)

* Take logged in user & IsRestricted flag into account in org/repo listings, searches and accesses

* Add basic repo access tests for restricted users

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

* Mention restricted users in the faq

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

* Revert unnecessary change `.isUserPartOfOrg` -> `.IsUserPartOfOrg`

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

* Remove unnecessary `org.IsOrganization()` call

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

* Revert to an `int64` keyed `accessMap`

* Add type `userAccess`
* Add convenience func updateUserAccess()
* Turn accessMap into a `map[int64]userAccess`

Signed-off-by: Manush Dodunekov <manush@stendahls.se>

* or even better: `map[int64]*userAccess`

* updateUserAccess(): use tighter syntax as suggested by lafriks

* even tighter

* Avoid extra loop

* Don't disclose limited orgs to unauthenticated users

* Don't assume block only applies to orgs

* Use an array of `VisibleType` for filtering

* fix yet another thinko

* Ok - no need for u

* Revert "Ok - no need for u"

This reverts commit 5c3e886.

Co-authored-by: Antoine GIRARD <sapk@users.noreply.github.com>
Co-authored-by: Lauris BH <lauris@nix.lv>
@lafriks lafriks added type/feature Completely new functionality. Can only be merged if feature freeze is not active. and removed type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Jan 13, 2020
@lafriks lafriks added this to the 1.12.0 milestone Jan 13, 2020
@stale
Copy link

stale bot commented Mar 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale stale bot added the issue/stale label Mar 13, 2020
@brunoais
Copy link

How close is this to be done?

@stale stale bot removed the issue/stale label Mar 13, 2020
@mnsh
Copy link
Contributor

mnsh commented Mar 13, 2020

It is done (#6274)

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Milestone
1.12.0
Development

No branches or pull requests
6 participants
@lunny @techknowlogick @lafriks @muellermartin @brunoais @mnsh