[...]
>> 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