[kforge-dev] access control to trac plugin

Rufus Pollock rufus.pollock at okfn.org
Mon Feb 13 08:15:00 UTC 2006

Just to add to John's previous comments ....

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...
> But we need
> some kind of unified access control for trac and kforge to make this a
> valid choice.
> 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.

The situation at present is a half-way house where Apache *does* 
dispatch directly to trac but with the addition of KForge authentication 
handlers in the Apache processing stack.

This way trac maintains control of its own url space except for 
authentication (and basic authorization) which is done via KForge. In 
the latest version of KForge (0.9.1 -- to be released some time in the 
next few weeks), authentication is exactly as John describes it with a 
single sign-on facility via the KForge login, with fall-back to normal 
Apache auth (still running off KForge user db) for things like svn.

In 0.9.0 (the version currently running on knowledgeforge.net and 
test.kforge.net) all sign in to subsystem applications such as trac and 
svn is done via Apache auth running off the KForge user db (via modpython).

> 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...)

As explained there is and will be unified access control.




More information about the kforge-dev mailing list