On Thu, Feb 4, 2010 at 08:20, Kevac Marko <ma...@kevac.org> wrote:
> 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
Try to set an apache request note in the authentication instead of
dynamically changing the configuration of mod_rewrite.c.
Thus, you'll have something like
RewriteRule /url %{ENV:destination}
The configuration would be always the same, just the value of the
"destination" request note changes dynamically, depending on the
authentication.
S
>
> 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 <sor...@gmail.com> 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
>
--
A: Because it reverses the logical flow of conversation.
Q: Why is top-posting frowned upon?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
