httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: mod_auth_anon help please
Date Tue, 28 Sep 1999 15:53:58 GMT

On Tue, 28 Sep 1999, you wrote:

Note to the author: I've Cc:-ed in the main http mailing list, as this is
an interesting puzzle and I'd like to see if anyone else comes up with a
much more clever answer, or proves me wrong; hence I've taken out some of
distingishing details. I hope you do not mind.).

> We're interested in getting the username/password from the client 
> without a challenge because we are running a private and public 
> website from the same system. Ideally, we'd like to continue logging
> the authenticated users' hits as they traverse to the public
> (non-authenticated) pages.  But, we don't want to burden the public
> with a username/password (for obvious reasons).

Yes.. this was the RQ which actually lead to mod_auth_anon originally.

> This far,  running Apache 1.3.6 on Solaris, with Basic Authentication
> at the .htaccess level (on the public branch of the website), we've been
> able to use the external mod_auth_anon module, in combination with
> the "Satisfy All" directive in the .htaccess file, to get the 
> username/password to come across for our public hits, but the public
> (non-authenticated) user still gets annoyed with a password challenge
> even though they can just click [OK] to get rid of it. If we switch to 
> "Satisfy Any" (so that either "allow from all" or "require-user" will
> satisfy),
> then the public password challenge goes away, but I lose the
> username/password for the already authenticated users.

Ok, you are absolutely correct; unfortunately you have hit a snag here
which is not 'solvable' directly but inherent to the HTTP protocol and the
way the browsers implement it.
 
> We're hoping to find an answer on how to retrieve the username/password
> for a user that has already been authenticated, even though they traverse
> to non-authentication pages, yet let the public through uncontested to the
> public areas.
 
I do not think HTTP does not allow for unsolicited password spewing easly.
But there might be a workable work around.

Workaround 1

The easiest way is having either type of user use different path's, which
are just symlinks to one place. That allows you to set different rules on
either paht. I.e. one uses /intern/docs/ and the other /extern/docs/. If
either user uses a different site, or when you generate the pages with the
link dynamically.. you can make sure that those href=""s are different.

Workaround 2

Then another option is that if you know that your 'internal' users come
from a certain IP you can do things like allowing in if the IP is NOT
in your internal range; or when the user is AUTH-ed. I.e. the reverse of
what you would normally do.

Workaround 3

Ok, but there might be a middle ground. Which requires more detailed
knowledege of the workings of the browser. And not all are the same
unfortunately: The story goes a bit like this:

As far as I know, A browser will ONLY solicit a user name and password
to the server when

	challenged
or
	the URI is 'deeper' and a challenge was seen higher
	up in the same three, which was met successfull.

Furthermore a browser will solicit a username/password which it
successfully used before without asking the user when

	challenged with the same REALM string (authName)
and
	the FQHN is still the same (* not exact, different
		browsers do this a bit different.)

So with this information you can construct a three of URI's like

	a/b
	a/b/c

Where 'b' is protected, but 'a','c' are not and 'a' has pointers
straight into 'c', as have pages in 'b'.

This will require some symlinking and rewriting- as to be able to protect
on Directory level; so you can single out 'a/b/*' to be protected without
protecting the URI a/b/c/*.

Now a customer who has visitied any page in 'a' and then requests
a page from 'c' will not solicit its UID. 

But a customer who has been in 'b' and then gets a page from 'c' will in
all likelyhood offer its user id password to 'c' even when not prompted.
(Unless it gets there without visiting 'b'.)

Ok.. now the problem is.. the 'b' users which fetch from 'c' will not have
the UserID displayed in the log; as apache does not bother decoding it, as
there was no need.

To counter this I think you will have a need to write a small module which
just has one entry;

#include "httpd.h"
#include "http_config.h"
#include "http_core.h"
#include "http_log.h"
#include "http_protocol.h"
#include "http_request.h"

module MODULE_VAR_EXPORT xxx_auth_module;

static int xxx(request_rec *r)
{
    conn_rec *c = r->connection;
    int res = DECLINED;
    
    res = ap_get_basic_auth_pw(r, &sent_pw); /* ignore errors */

    return DECLINED;
}

module MODULE_VAR_EXPORT xxxx_auth_module =
{
    STANDARD_MODULE_STUFF,
    NULL,			/* initializer */
    NULL,
    NULL,			/* dir merger ensure strictness */
    NULL,			/* server config */
    NULL,			/* merge server config */
    NULL,
    NULL,			/* handlers */
    NULL,			/* filename translation */
    xxxx,
    NULL,
    NULL,			/* check access */
    NULL,			/* type_checker */
    NULL,			/* fixups */
    NULL,			/* logger */
    NULL,			/* header parser */
    NULL,			/* child_init */
    NULL,			/* child_exit */
    NULL			/* post read-request */
};

But I'd be interested in more elegant solutions.

Dw


Mime
View raw message