Comments (8)
I just saw the scope: repo, write:org
message on the bot server page -- might be more clear to have all those steps in one place though.
from gu-who.
Hi there @ekallevig - thanks for your interest in gu:who, hope it can be of use to you!
It was our aim was for the running instance of gu:who to guide you with all the bits of information you need - we haven't probably quite managed to do that as clearly as we should, but most of what you need is there. So if you look at the opening page of a gu-who instance (for instance at https://gu-who.herokuapp.com/ ), you'll see:
...as you can see, the required scopes are repo & write:org.
If you login, or provide an access token, you'll see a page like this:
You're told that all the GitHub issues raised by gu:who will appear to be raised by the account you just logged in with. So it's up to you, you can have them raised as yourself, or you can have them raised by a fresh bot account you create (which I would recommend) - either way, it's best to be consistent on subsequent runs.
The one other wrinkle about the bot account is that due to GitHub restrictions, it can't do the Two-Factor-Authentication checking unless the bot is an owner for that org - this is mentioned in really small type on the opening page:
Aside from that aspect, at the moment bot only needs access to the people repo (tho' if it's an owner, it can access all repos in the organisation).
There are also some instructions on setting up gu:who on Heroku here:
https://github.com/guardian/gu-who/blob/53e806/heroku.md
I'll have a think about presenting this information in a different way, in the mean time, let me know how you go!
from gu-who.
@rtyley Perfect thanks -- exactly the kind of info I'm looking for (and you're right it mostly is all available in various spots). Thanks again.
from gu-who.
@rtyley One other question -- I'm a little nervous to grant write:org
access, would prefer to keep this experiment scoped to the one repo. Is it necessary to write group membership?
from gu-who.
I'm a little nervous to grant write:org access, would prefer to keep this experiment scoped to the one repo.
The write:org
permission is actually surprisingly weak, all it does is allow gu:who
to 'conceal' organisation membership - so if you have org members who are not passing your requirements, they won't be visible to the general public as members of your org.
After 4 weeks of a user failing requirements, gu:who
does actually remove them from your org, but this actually requires them to be an organization admin (which is also required for 2FA support).
https://developer.github.com/v3/orgs/members/#remove-organization-membership
Currently gu:who is all about auditing org membership, not the collaborators on a single repo, so if you just want to control access to a single repo, it's probably not suitable for you right now.
from gu-who.
It's only the writing of data that I was concerned with keeping scoped to the one (people) repo -- just out of an abundance of caution with a 3rd party bot. But you're right that write:org
is limited enough that I'm fine with it. So to be clear, the token would need additional admin:org
permissions to do the 4-week removal process, correct? Is that something that can be turned on/off easily?
from gu-who.
Surprisingly, GitHub doesn't seem to require the admin:org
permission in order to be able to remove a user - we don't add that permission for our own gu:who bot:
"In order to remove a userβs membership with an organization, the authenticated user must be an organization admin."
https://developer.github.com/v3/orgs/members/#remove-organization-membership
The repo
scope is the one you want to be aware of. It grants read/write access to all public and private repositories that the bot-user can see. I have asked GitHub to support finer-grained read:private_repo
& write:labels
scopes, but unfortunately, for the time being, this scope is the only one available to allow gu:who bot to read & set labels on the private people
repository.
So this brings you down to a single choice so far as security goes- you can't do anything useful with scopes, but you can decide how powerful the bot user is. There are two meaningful choices:
a) bot is an org-owner - it can check 2FA and remove users
b) bot only has write access to the people
repo - it can't do 2FA checks, or evict users
It's up to you which you choose, but we only run gu:who as with option a) in our organisation.
from gu-who.
Currently gu:who is all about auditing org membership, not the collaborators on a single repo
We can take this to a separate issue, but would there be interest in gu-who also auditing collaborators on repositories?
from gu-who.
Related Issues (20)
- 403 trying to post directly to service - CSRF Error HOT 2
- Oops, an error occured HOT 5
- Document the "bots" and "2fa_disabled" groups HOT 2
- Runs this regularly on a server? HOT 4
- mention the grace period in the issues that are open HOT 2
- make grace period configurable HOT 2
- add a test mode HOT 2
- warning confuses when issue closed in same comment HOT 1
- Protect against stupid operators who didn't fill out a users.txt before running HOT 9
- Add deployment process in readme HOT 1
- Heroku request timeout HOT 4
- User removed even though all requirements were addressed HOT 4
- Allow anonymous users HOT 3
- The issue for each problematic user is added twice during one audit HOT 4
- Outside collaborators HOT 1
- Users allowed to sponsor themselves
- Hosted and self-hosted instances of gu-who appear to be broken?
- Check references to master
- Update other build configuration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gu-who.