> >Noah, > > > >I already answered your question through Jim Harter at Covalent. You > >cannot pass information from an input filter to the access checker, > >because the input filter runs during the handler phase, and the > >access_checker function runs long before that. > > It wasn't clear until recently that the input filters run during the handler > phase (which is after the hooks). Could we clarify the order of events here > so third party developers can see the flow? I believe the answer is no, but > is it possible to subvert an input filter from being executed? Is there > anything I should be aware of when running as an input filter that's > different from running in the hooks? > > I don't think it is clear where filters fall in the order of request > processing. After doing some hacking and talking to some
The hooks are all run, (meaning post_read, access_checker, check_user, fixups, etc). Then the handler is run. The handler is used to read all POST data, and generate and send content. > >You will need to do your access checking as a part of the input filter, > >and deny access within the access checker. As I told you, the HTTP_IN > >filter has a couple of examples of how to do this. > > How could I possible do my access checking as a part of the input filter and > deny access within the access checker if the access checker runs first? > There are cases where I might want to deny access based on what I find in > the input filter (did I say access enough here?). You don't absolutely NEED to do the access checking in the access_checker phase. It is commonly done there, because modules that do access checking based on non-request body information can do it in the access_checker phase. However, the _only_ way to do access checking based on the request body, is to do it in the filter itself. If you create an input filter that can determine if the request is allowed or not, then to allow access, just return the data to the next filter in the chain, and to deny it, create a brigade with an error bucket and send it down the output_filters stack, then return AP_FILTER_ERROR to the next filter. As I said, examples of this can be found in the HTTP_IN filter. Ryan > > >While it is true that there isn't much information available for writing > >input filters, the best source currently available is the filters used in > >Apache itself. > > > >Ryan > > What about things like setting headers or performing a redirect from within > an input filter? Are there examples of this as well. What input filters are > good to look at besides ap_http_filter? > > On Mon, 19 Aug 2002, Arliss, Noah wrote: > > > Greetings, > > > > I have been working on a port to Apache 2.0 for some time now and have run > > into a road block that I would like to get feedback on. I need to run my > > module in the access_checker hook with the ability to read in Post data in > a > > non-destructive manor. In apache 1.3 this was possible by hacking the > > request structure and putting the post data back for ap_get_client_block > to > > read again. In Apache 2.0 this does not appear possible and I've been told > > to look at input filters. So I was wondering if it would be possible to > > somehow read data in my input filter and then pass it along to the > > access_checker phase? When are input filters executed? I'm hoping this > will > > spark a discussion on the new apache 2.0 architecture here, since there is > > not a lot of information out there about filters yet and I'm sure others > > will benifit from this discussion. > > > > Thanks in advance for the help, > > > > Noah Arliss > > > > -- _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
