httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevac Marko <ma...@kevac.org>
Subject Re: Using mod_rewrite in my authorization module. Need advice.
Date Thu, 04 Feb 2010 07:20:50 GMT
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 <sorinm@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

Mime
View raw message