[kforge-dev] access control to trac plugin

[John Bywater]

Hi Fredrik,

So, I made a simple KForge access control demo from the latest source:
http://project.kforge.appropriatesoftware.net:9080/

there is a 'graphics' and a 'clippings' project:
http://admin.kforge.appropriatesoftware.net:9080/project/graphics/
http://admin.kforge.appropriatesoftware.net:9080/project/clippings/

the graphics project has the visitor a 'friend' member:
http://admin.kforge.appropriatesoftware.net:9080/project/graphics/members/

the clippings project does not have the visitor as a member:
(same as having the visitor as a 'visitor' member, because standard 
system role is 'visitor'):
http://admin.kforge.appropriatesoftware.net:9080/project/clippings/members/

now, both projects have subversion services:
http://admin.kforge.appropriatesoftware.net:9080/project/graphics/service/svn/
http://admin.kforge.appropriatesoftware.net:9080/project/clippings/service/svn/

with svn repositories available (via DAV) here:
http://project.kforge.appropriatesoftware.net:9080/graphics/svn/
http://project.kforge.appropriatesoftware.net:9080/clippings/svn/

please note:
1. when the above two locations are viewed in a browser (without having 
logged in to kforge), the graphics svn repository is available, but a 
request to read the clippings svn repository is redirected to the kforge 
login:
http://admin.kforge.appropriatesoftware.net:9080/user/login/

2. when the above two locations are used with an svn client (without a 
cached authentication), the graphics svn repository is readable (e.g. 
svn co, svn up) without experiencing a password prompt, the clippings 
repository prompts (using basic auth) for a password, and both 
repositories prompt (using basic auth) for passwords for writes (e.g. 
svn commit).

the more open read behaviour of the graphics svn repository is caused by 
the visitor member having the friend role

it is suspended by making the visitor member have the visitor role

open writes are possible by making the visitor a developer - this 
configuration might be used on a private intranet, but (along with 
making visitors to administrators) probably not something you want to do 
on a public site ;-)

3. the installed default configuration is such that simply adding the 
visitor to the project opens up the project's resources for unchallenged 
read access, but requires a registered and authenticated person for writes.

4. there are a lot of other aspects to the configuration of the access 
control, but I'm trying to get a nice and secure default configuration 
for distribution

...

Fredrik Svensson wrote:

>Brilliant!
>
>Then it's just to checkout everything and start to get familiar with the
>codebase :)
>  
>

We do hope the code is readable, and understandable. To this end, from 
the start of the project we've been following Martin Fowler's "Patterns 
of Enterprise Application Architecture" (PoEAA). There's a book, but 
there's also a wiki. I'll find you the link if you don't know about it 
already. I'm just trying to indicate that there is an overall design, 
which has been made from these patterns. Most of the patterns have names 
that are in fairly common usage, or are at least highly suggestive of 
their function.

But you'll have to let us know what does or doesn't make sense. Some 
bits, of course, are better than others.

With best wishes,

John.

PS If anybody would like to register on the service, i'll happily add 
you as a member of the various projects i've registered, or you can 
create some of your own :-)


>Best Regards
>Fredrik
>
>  
>