Thanks a lot for your comments. I'll try to describe requirements for our authorization module and current implementation a little bit more.
Requirements: 1. Authorization must happen before mod_cache (also a little bit fixed for our needs), so it must be executed in 'quick_handler'. This is because in our architecture, almost every request is cached. Normal requests and authorized requests. All of them. 2. Authorization configuration should be taken from DB, because it is changed a lot and restarting Apache every time is stupid thing to do in this case. 3. Authorization rules should consist of regular expression, which matches some url and two substitution strings. One for 'granted' and one for 'denied'. This is because sometimes, when user don't have appropriate rights, we should send him same data, but maybe slightly different. For example real time data and 20 minutes delayed data. Sometimes we should send him to 401, sometimes to 403. It depends on which url user is accessing. Current implementation: 1. We keep authorization rules (consisting of url regexp and two substitution strings) in DB. 2. In apache.conf there are stub RewriteRule, which is dynamically substituted with new one. New one, which consist of url regexp A and substitute string AA or AB according to authorization result. 3. User Request -> Our Authorization module (authorization check + mod_rewrite configuration dynamically changed) -> mod_cache -> mod_rewrite substitution with our dynamic rule -> mod_proxy or anything else This is working great in mpm_prefork where only one thread at a time reads mod_rewrite configuration, but will not work in mpm_worker, where many threads read mod_rewrite configuration at the same time. I hope it's more clear now. Our architecture is NOT standard. So many things can be unusual. Let's not dig too deeply here :-) Most non standardiness is in the way we are caching things. We are caching mostly everything, including authorized requests. So authorization must happen before mod_cache. Now i'll try to answer on each comment. On Thu, Feb 4, 2010 at 12:44 AM, Sorin Manolache <[email protected]> wrote: > I think it would be clearer and we could help you better if you pasted > some snippets of your code and hack. I hope it is clearer now, but i'll paste snippets if anything is not enough clear. > I didn't really understand what you wanted to do. And I don't really > understand why mono-threading would break your hack. Normally a > request is processed by a single thread anyway. Mono threading (mpm_prefork) will not break it. Multi threading (mpm_worker) will, because more than one threat at a time reads mod_rewrite configuration, which I am messing up with. > But look what you could do in your authentication module: You could > set an apache request note (or an environment variable) depending on > the authentication. And then call ap_run_translate_name that > re-invokes the rewrite rules. > > Something like > > determine if the user is priviledged or not > apr_table_set(r->notes, "auth_status", priviledged_user ? "yes" : "no"); > ap_run_translate_name(r); > return OK; > > and then in the configuration file you put > > RewriteCond %{ENV:auth_status} yes > RewriteRule url /destination_priviledged > > RewriteCond %{ENV:auth_status} no > RewriteRule url /destination_ordinary > > The first time the translate_name is called, the auth_status note is > not defined. Thus no rewrite rule is applied and the URL is unchanged. > Next apache executes the request authentication hook from where you > invoke again the translate_name callback. I could do that if our rules are kept in apache.conf, but they are not. They are kept in database. I cant keep them in apache.conf, because each change will require apache restart. > By the way. The order in which the callbacks are called is > translate_name, then authentication/authorisation and last fixups. Our authorization module is not standard authorization module, so our order of execution is another. -> authorization -> cache -> translate_name -> fixups -- Marko Kevac
