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

svn auth, WAS: RE: Auth in ra_dav

From: Sander Striker <striker_at_apache.org>
Date: 2001-08-24 17:40:09 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.

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.