Replying to myself, I worked on the "Private Mode" today (http:// gitorious.org/projects/gitorious/repos/mainline/merge_requests/197)
Now you have an option at config/gitorious.yml called 'gitorious_public_registration'. If 'true', the website behaves exactly like before. But if 'false' it is locked down completely. You have to run script/create_admin to manually create the super user and only this user can add more users to the system. No one from the outside can list or see projects nor source code from there as well. I didn't lock down git-daemon but I am assuming, for now, that this is not so bad because you have to know the name of the project to git clone from it. Take a look and see what do you think. On Jan 8, 11:01 am, AkitaOnRails <[email protected]> wrote: > In the current doc/ folder I added, I also added a 'wishlist' file > (http://gitorious.org/projects/gitorious/repos/mainline/blobs/master/ > doc/WISHLIST). What are everybody's thoughts on that? > > To begin, I am willing to build a very very simple Private mode. This > is necessary because some companies (myself included) need to have a > private Gitorious server on a VPS. But as it is remote on a VPS it > can't be publicly open (and setting access on IP address is not > practical and setting HTTP authentication in the web server layer > feels ugly). > > My Idea: > > - the default mode works exactly like today, no surprises > - create a 'private mode' enabled/disabled flag in gitorious.yml > - install with a default superuser (probably in a migration file) > - create a very simple, bare bone, admin page that allows CRUD ops > over users (including manually adding new users) > - in private mode, the Register link disappears and I have > before_filters to disallow accessing projects unless you have a login > (which only admin-like users can add) > - add a very simple Role model (to begin with, maybe just a 'is_admin' > boolean column on the User model) so the superuser can delegate user > management > > My questions (I didn't dive too much into this code): > > - In private mode, even the "Public URL" can't be accessible. Meaning > that the git-daemon has to recognize this mode, and check if the user > requesting the 'git clone' has it's ssh key registered. Do you think > this is difficult? > - The 'gitorious' command used in the authorized_keys already checks > if the user is registered, so pushing is ok. But does it check for > 'git clone' requests as well? > > I will try to figure that out. > > I don't think we need to make it too complex and granular. For > example, I don't think it is necessary to have groups of people that > can't see some projects in the same gitorious. I am considering that > every user that is registered can see anything, only new users have to > go through the admin first. If you need to have 2 groups of people > where each group can't see what the other is doing, it is better to > have 2 gitorious installations and 2 admins anyway. But I think that > inside the same company every code has to be visible. > > The only requirement is for outside people to not being able to see > what the company is doing. > > If you agree, I will start coding it. Ideas and feedback are welcome. > This change alone should increase companies adoption of Git as there > is no competent front-end available for them yet and Gitorious makes > all projects public. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Gitorious" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/gitorious?hl=en -~----------~----~----~----~------~----~------~--~---
