[kforge-dev] Authentication bug: not finding the cookie

[John Bywater]

John Bywater wrote:

> PS Hope to commit things shortly......


So I think I'm done with kforge.handlers for now. I think the problems 
we were having have been sorted out, every major line of execution is 
under test (I think). I can't see any more refactorings that would 
improve the code, and I'm mostly happy with the names of things.

This was all about the access control handlers for the "project host" 
(ie for the virtual server which serves the project services such as 
Subversion and Trac applications). The issue is to prompt for 
authenticaion in one of two different ways depending on the client 
making the request.

The issue with the password prompt appearing for cookie-capable clients 
was resolved by returning 0 from the access handler when setting a 
redirect, instead of 200. I wrote about this here:

http://project.knowledgeforge.net/kforge/trac/browser/trunk/src/kforge/handlers/projecthost.py#L8

and here:

http://project.knowledgeforge.net/kforge/trac/browser/trunk/src/kforge/apache/apacheconfig.py#L211

I've put all the mod_python handlers for the KForge "project host" in 
the handlers/projecthost.py file. The handlers extend an abstract 
mod_python handler, which has common methods for handling requests, and 
which is in the handlers/base.py file. The project host *access* handler 
has responsibilities for responding to and access control based upon 
session cookies, and for redirecting to the KForge login page or 
deferring control to the authen handler if access is not allowed. The 
project host *authen* handler has responsibilities for authentication of 
and access control based upon credentials supplied through the 'Basic' 
password prompt.

The bug was caused when I replaced the modpython handler return value 
apache.OK (0) with apache.HTTP_OK (200) whilst assuming wrongly that 
they meant they same thing, had the same value, or at least would be 
treated in the same way. Handlers need to return apache.OK (or value 0) 
if they want be the last handler called for a given request under the 
'Satisfy any' condition, perhaps in order selectively to avoid 
triggering an AuthenHandler event with its otherwise unavoidable 'Basic' 
password prompt.

Hope this helps. I'm glad we finally got to the bottom of this, and have 
rewritten the handler code into something maintainable.

Rufus: I'm glad you got the KnowledgeForge service fixed up...  :-) 
Sorry I didn't come to the Copynight: due to refactoring blindness I 
fell asleep at the end of the afternoon and missed most of the evening.

Bye for now,

John.