Private/public projects
Peter
individually. A private project cannot be accessed by anyone except
the owner and any authorized contributors (if any).
A project can be switched to public or private at any time by toggling
a checkbox in the Project Settings form. Of course, only the owner can
do that (a contributor can't access the Project Settings form at all).
This is how contributor authorization works:
* The owner specifies a passkey in a field in the Project Settings
page.
* A user that wants to become a contributor gets this passkey from the
project owner (they can email for it, call, etc.)
* Once the aspiring contributor has the passkey, he goes to the
project's home page and types it in the box (the box will not show up
if the user is not logged on).
* If the passkey is correct, the user gets instant access to the
project.
I would be very interested in your comments.
There are a few improvements I have in mind, especially to improve
security: at the moment the passkey is stored in the database in the
clear, I'd like to add encryption. There is also no GUI way for the
owner to remove a contributor, or to get a list of them.
Time permitting, I'll work on these two issues next week.
Peter
Peter
http://www.gitorious.org/projects/gitorious/repos/ftsk-gitorious
Peter
Johan Sørensen
On Thu, Jan 15, 2009 at 1:04 AM, Peter <peter.d...@gmail.com> wrote:
>
> I have written a way for projects to be made private or public
> individually. A private project cannot be accessed by anyone except
> the owner and any authorized contributors (if any).
Nice. There's been a few requests for this, so it's quite timely.
> This is how contributor authorization works:
>
> * The owner specifies a passkey in a field in the Project Settings
> page.
> * A user that wants to become a contributor gets this passkey from the
> project owner (they can email for it, call, etc.)
> * Once the aspiring contributor has the passkey, he goes to the
> project's home page and types it in the box (the box will not show up
> if the user is not logged on).
> * If the passkey is correct, the user gets instant access to the
> project.
>
> I would be very interested in your comments.
I'm thinking we should do a proper project memberships model, with
roles attached. That way, adding a member to a project is a matter of
inviting them; type in their email address, wait for them to click the
confirm link.
Rather than doing the "is this a private project?" checking in the
views and helpers like you're doing a lot of place, it's much easier
(both in implementation and maintenance) to check it in a before
filter. There's a find_project method in the application controller
that is used throughout (or should be at least, if it's not I've been
doing it wrong). After it has found a given project would be a good
time to check for its privateness, and either redirect back with a
flash[:error] or render a page and stop the filter chain.
That way we'll have less places where the authorization is done and
that makes maintaining it easier in the long run.
>
> Peter
>
Cheers,
JS
Peter
using the find_project method as you suggest.
I'll do some thinking on the invitation way of getting contributor's
on board. I can see cases where either the "invitation" method or the
"passkey" method would be preferable. For example, I am thinking that
the passkey method would be preferable in a teaching setting (looking
to implement this for my students in one of my uni classes): the group
leader would let the group's members know of their project's pass key,
and the members would sign up without any further effort from the
leader/owner.
In both cases though, a proper membership model would help a lot. And
I can't see why both methods could not use the same model.
Regards,
Peter
Thomas
until now I've not been a contributer in the gitorious group yet, but
I like the discussions and I like gitorious much more. Hopefully we
can switch at our company to git (and gitorious as frontend) really
soon! You've done a great job so far.
Today I thought about security of a private repository you are talking
about. How do you provide read-access to a private repository only for
the contributers? As far as I see, only write-access can be permitted
or forbidden, if a user knows the repository's name, he can clone
whatever he wants. This is only security through obscurity. Do you
have ideas how to improve control for read-access on private
repositories? Or do i miss something?
Kind regards,
Thomas
Johan Sørensen
On Mon, Jan 26, 2009 at 11:11 PM, Thomas <tho...@tschamm.de> wrote:
> Today I thought about security of a private repository you are talking
> about. How do you provide read-access to a private repository only for
> the contributers? As far as I see, only write-access can be permitted
> or forbidden, if a user knows the repository's name, he can clone
> whatever he wants. This is only security through obscurity. Do you
> have ideas how to improve control for read-access on private
> repositories? Or do i miss something?
The way most people do it when they run a private install of Gitorious
is to never actually set up the git-daemon, that way all push and
pulling/cloning has to be done through ssh and thus relying on the
pubkey and permissions (in gitorious) for the particular repository.
>
> Kind regards,
>
> Thomas
Cheers,
JS
Peter
you are right, anyone who knows the name of the repository can clone
it etc. I suppose what Johan suggests will work in a private
installation situation, but not if you want to have a real mix of
public and private. I think in that case the git-daemon must be
running, so the problem is securing the private projects.
I have a couple of early ideas on making that possible, but haven't
had much time to work on it lately. It's the next item in my to-do
list.
If anyone has any ideas or advice to offer, please do!
Peter