[kforge-dev] access control to trac plugin

Sun Feb 12 21:37:36 UTC 2006

Hi Fredrik,

Thanks for your nice message......

Fredrik Svensson wrote:

>Hi,
>
>The company I'm working for is considering using trac as a "*forge" site
>for each customer. They will use trac but I suggested that I should look into
>kforge as well to see if we could use it as a framework around trac...
>  
>

That's good to hear! I think you should look into it :-)

>But we need
>some kind of unified access control for trac and kforge to make this a
>valid choice.
>  
>

Yes, there is unified access control. It works quite well:

If you visit a kforge "trac" service with a web browser, if necessary, 
you will be redirected to the kforge login page for any area requiring 
authorisation. This happens for all plugged-in subsystems like trac and 
svn. A cookie is used. However, if you use an svn client (which doesn't 
support cookies) to check out some code, then, when an action requires 
authorisation, apache prompts for a valid kforge username and password 
(of course unless there is a valid auth in your auth cache).

Kforge discriminates between different types of clients, so whilst login 
details are unified across all clients, and the kforge login screen is 
always the same for web browser clients (i.e. you don't see the basic 
pop-up login promt sometimes), kforge does resort to basic apache 
authentication for svn clients (and we expect to extend this support to 
other clients as necessary).

This means, amongst other things, that tickets/changes/etc. in trac 
projects and svn repositories are marked with real, authenticated kforge 
usernames. And if objects are writable by an unauthentcated user, then 
the 'visitor' person is used to identify changes. So you can rely on the 
names.

Anyway, that's the flavour.... Hope you like it :-)

>I can't find a running site where I can test if there kforge controls the
>url space for trac or if the apache dispatches directly to trac.
>  
>

I'll upgrade my demo site tomorrow, and show you the interaction with 
trac and svn.

There's a range of cases for whether read and write are open; read and 
write require authorisation; and read is open but writing requires 
authorisation (normal?).

>So the question is, is there or will there be any unified access control?
>(I suppose one should use a wsgi login app for both...)
>  
>

That's a good idea, but e.g. svn repository and trac application access 
is controlled with a kforge user model, a kforge access controller, and 
kforge request handlers.

But we should decouple our own access control more.

>Another question is probably if kforge's aim is to be a replacement/alternative
>for a normal gforge installation?
>  
>

Yes, I think so. Alternative ;-)

Best wishes,

John.

>Best Regards
>Fredrik Svensson
>  
>