Forum OpenACS Development: Overriding rp_filter

Posted by Dave Bauer on
We have one instance where we need a filter to run _before_ rp_filter, the filter that generally processes every request. The existing override of rp_filter is rp_resources_filter which handles unauthenticated access to public files such as icons, css files etc. Things where it does not make sense to check pemmissions on every request.

I have a new requirement to support HTTP authentication for RSS feeds. In this we need to run a filter before rp_filter. I did a hack that works by calling ns_register_filter in the WebDAV support package that sort of worked but requires all URLs to have a certain prefix.

In the case of rss feeds, I wanted to retain the context of the URL (I need to know the URL to check permissions) so I setup rp_filter with a priority, just like all the other filters. I set the rp_filter priority to 0 and the rp_resources_filter priority to -1000 so now you can register a filter between these two filters by calling ad_register_filter with a priority between -1000 and 0. It works.

There are some other issues where some code to setup a session needs to be called, but the HTTP authentication code works correctly with this change.

What does everyone think? This change seems to make the priority setting of rp_filter a little more useful, although you need to understand the security implications of overriding rp_filter.

2: Re: Overriding rp_filter (response to 1)
Posted by Andrew Piskorski on
On the AOLserver list, there've been comments off and on for ages (principally by non-OpenACS users, I think) about how it would be preferable for the OpenACS request processor to play nicer with other AOLserver filters, rather than insisting on always running first, and then hijacking all processing of the request from then on. I don't recall the details, but that sounds related to what you're talking about, Dave?
3: Re: Overriding rp_filter (response to 1)
Posted by Dave Bauer on

Pretty much, I am allowing you to specify the order or all filters, including rp_filter, which is what you refer to as "hijacking" filters. You can register any filters you like and of course, you can hack them to run before rp_filter by naming your package someting that comes before acs-tcl.

I am just making it simpler by giving rp_filter an explicit priority, which you can override by making your filter a higher priority.

In general one should understand that you are also overriding the built it, well-tested, mature security code in the request processor when you do that.