[kforge-dev] access control to trac plugin
john.bywater at appropriatesoftwarefoundation.org
Sun Feb 12 21:37:36 UTC 2006
Thanks for your nice message......
Fredrik Svensson wrote:
>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
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
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
>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 ;-)
More information about the kforge-dev