DO NOT REPLY [Bug 35781] New: - ap_sub_req_method_uri() bypasses Limit security config

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35781>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35781

           Summary: ap_sub_req_method_uri() bypasses Limit security config
           Product: Apache httpd-2.0
           Version: 2.1-HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: dan.kubb-apache@onautopilot.com


When using ap_sub_req_method_uri() to perform a subrequest, it skips over all stages straight to the 
Type Handler phase.  This skips over any access/authentication/authorization handlers that have been 
defined, and allows the type/response phases to be executed directly -- when in fact the client may not 
be permitted by Limit security settings.

In my particular setup, I allow GET/HEAD/POST/OPTIONS to all users; but I limit PUT/DELETE to specific 
users.  I have a piece of code that executes when a POST (that contains specific instructions) is recieved, 
that performs a subrequest on the current URI as a PUT/DELETE.   In effect, I am tunneling PUT/DELETE 
over POST, something that allows me to have a uniform interface for all clients, while still allowing 
normal behaviour for web browser clients that are limited to GET/POST method calls only.

The behaviour I expected was for the security limits I set up for PUT/DELETE to be honored, and 
disallow the request should something in the AAA stages not pass; however the use of 
ap_run_quick_handler() at the end of ap_sub_req_method_uri() bypasses all of these handlers.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org