[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