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

[John Bywater]

Rufus Pollock wrote:

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


Thanks. ;-)

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


Good detective work.

Just to check, you're saying this bug occurs for:

1. Non-cookie browser clients
2. A POST request
3. No access granted (allegedly)

but then the access handlers return OK, so that the request is passed to 
the Trac handler?

Looks like we need a new way of inspiring the redirect. From memory, I 
think the OK was needed to get the redirect working, that is we weren't 
getting spammed but there was a different problem of some sort. Do you 
remember what it was? Was it that DAV clients couldn't post? I can't 
remember.

Perhaps we need to try returning with HTTP_REDIRECT code? But I'm sure 
that's what we were doing before, when it wasn't working. Perhaps it 
wasn't working for some other reason that the return code?

The best I can say is that the refactored code should be a bit easier to 
work with. Perhaps it will give us the chance to finally resolve this 
rather complicated and difficult to test concern.

Best regards,

John.

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