[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn auth, WAS: RE: Auth in ra_dav

From: Sander Striker <striker_at_apache.org>
Date: 2001-08-24 17:55:58 CEST

> [...]
> >> If you want to understand our PAM-like authentication, look at:
> >>
> >> * subversion/include/svn_ra.h
> >> * subversion/libsvn_client/auth.c
> >> * issue #456, for future plans.

Hmmm, maybe subversion/svn_repos/hooks.txt is a good one to add to
this list too. The read/write sentinels eliminate all comments
below...

Sander
 
> Ok, comments and stuff to think about:
>
> 1. Will the action specific access control be maintained (as
> currently described in the design doc)?
>
> This is a very usefull feature, to say the least. I'm referring
> to the example idea of a back-end implementation of svn_authorize().
> There roles are mapped to users and repository paths.
>
> To extend this idea it would be nice that if all authentication
> fails, the username is set to 'anonymous', which can then be used
> to allow for adding rules like:
>
> anonymous : visitor /trunk/project
>
> I would also like to be able to specify a rule that would be used
> when other rules fail to work because the repository path isn't
> explicitly mentioned in the rule:
>
> all : visitor /trunk/project
>
> When having a config like so:
>
> striker : hacker /trunk/project/subdir
> x : offlimits /trunk/project2
> anonymous : visitor /trunk/project : visitor /trunk/project2
> all : visitor /trunk/project : visitor /trunk/project2
>
> This would save specifying for user striker that he has 'visitor'
> rights to all the projects not in his rule. This comes into
> view once a new developer gets commit access to a single project
> in the repository, but all other projects are public. IMHO it
> should be possible to do an 'authenticated' checkout for projects
> that can be checked out anonymously.
> Oh, in this particular example a checkout of /trunk/project2 by
> user x would fail, because there is a specification of what should
> be done.
>
> I understand that the svn_security file idea is outdated, but
> something anologue to that would surely be implemented(?), keeping
> these points valid.
>
> 2. Are the supported auth methods going to be configurable (ie. can
> an admin switch the weaker ones off?
>
> 3. ...
>
> Damn I had more stuff, but seem to have forgotten what I wanted
> to say :( Maybe more later (or tell me to please shut up :).
>
>
> Sander
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.