[kforge-dev] Ticket #38 (defect) created by I love you

Rufus Pollock rufus.pollock at okfn.org
Thu Jan 11 12:15:56 UTC 2007


John Bywater wrote:
> 10: Timeline wrote:
> 
>> Good site
>>
>> URL: http://project.knowledgeforge.net/kforge/trac/ticket/38
>>  
>>
> 
> :-(
> 
> Guess we'll need to grep through Apache logs to see what URL was used?
> 
> Perhaps, Trac tickets can be created with a GET request?

No see below.

> Perhaps, we'll need to check the KForge logs to see what access control 
> events occurred?
> 
> Perhaps, we'll need to start always using https?

Should have written about this yesterday. I spent 1.5 hours :( tracking 
the source of this down. The results are as follows:

1. The modpython access control code in the handlers package is working 
correctly in the sense that the responses are what they should be (nice 
refactoring of the handler code btw)

2. Focusing on trac I confirmed that:

   * These changes to trac are done via a post request

   * As would be expected from 1 non-browser User agents are correctly 
excluded from post requests.

   * Access from non-browser is also handled correctly as per our model 
(an attempt to post on a ticket either to modify or to create) leads 
either to access denied page or to login page. *HOWEVER the changes 
still go through to trac*. To repeat an attempt to submit as visitor on 
a trac system does lead to a redirect (so our accesscontrol works) but 
the post request still gets passed on to the underlying trac application 
and the changes made.

(I checked this both locally and against test.kforgeproject.com)

Looking at our code, in particular [1], I suspect that this may have 
something to do with our technique of dealing with denied browser 
requests by returning OK from the handler and setting the location 
field. I think what is happening is that by returning OK though we 
terminate the modpython access/authen chain we do not terminate 
processing by other handlers so the request gets passed on with the 
redirect only happening once the request handling has finished and the 
result is returned to the browser. I also note that the 'old' system (i 
guess that means pre r1018) did not display this behaviour (we weren't 
getting spammed ...).

Regards,

Rufus

[1]:<http://project.knowledgeforge.net/kforge/trac/browser/trunk/src/kforge/handlers/projecthost.py>




More information about the kforge-dev mailing list