[kforge-dev] trac, permissiong working (and working together)

Mon Oct 17 11:36:50 UTC 2005

Rufus Pollock wrote:

> After plenty of random bug pain we finally have trac working together 
> with the permission system. You can check this out by going to:
>
>   http://test.kforge.net/annakarenina/trac/trac/

I don't get a trac service at this location. I get an error:

"ImproperlyConfigured: You need to specify both DATABASE_NAME and 
DATABASE_USER in your Django settings file."

>
> and seeing that
>   a) you will need to log in
>   b) these credentials will work:
>     username: levin
>     password: levin

I could log in as levin here:

http://test.kforge.net/

:-)

>
> One rather cool thing is even though our authentication is entirely 
> seperate from trac's system trac seems to automagically pick up our 
> authentication (so if you log in as X this will be displayed by trac). 
> Assume this is because we are using mod_python auth.

Great. Are we sure it isn't the whole realm that's authenticated, such 
that somebody has access to everything once they have authenticated 
somewhere. Just wondering....

>
> Now that all this is working I plan to move kforge code into a 
> beta.kforge.net site so that we start eating our own dog food. This 
> will also mean we get to use trac for bug tracking etc. Just to 
> summarize now have:
>   * svn plugin
>   * trac plugin
>   * moin plugin
>   * projecthome plugin (project website + dav access. This is actually 
> not yet in but will be as soon as I commit ....)

Very good.

>
> I note for the record that there is the following minor issues that 
> still needs to be resolved re permissiong:
>
>   1. Debian server install prompts for username and password even for 
> open section of site (true to form input of any username and password 
> including blank ones works but it is annoying to have the form pop 
> up). Interestingly on my mac this does *not* happen. Note that this 
> means that one of the modpythontest test cases will fail on std debian 
> ....

It must be that some configuration somewhere can smooth this out....

>
>   2. Despite extensive mailing to mod_python lists still have an issue 
> where a single url generates multiple calls to authenhandler issue. 
> This may at some point turn out to be a performance problem but at 
> present it has no effect on user experience so leaving. Extensive 
> documenation of this issue:
>   kforge.apache.modpython module comments
>   http://www.modpython.org/pipermail/mod_python/2005-October/019184.html

 From Tristan's report, I'd say there's clearly a mod_python bug....

Best wishes,

John.

>
> Regards,
>
> Rufus
>
>