Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of mmwaldman@nyc.rr.com
 designates 71.74.56.123 as permitted sender)
From: "Michele Waldman" <mmwaldman@nyc.rr.com>
To: <modules-dev@httpd.apache.org>
Subject: RE: Location of Apache Modules
Date: Wed, 22 Apr 2009 19:46:19 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcnCqwZwtd+F4TSpRKGfHqdE7VT3NQAxL1yQAACRSNAADJRN4A==
In-Reply-To: <A84920684DBB3746A1BEA1296EC9E4EB0324F561@EXCVSRV2.aoins.com>
Message-Id: <20090422234617752.KZUL7472@hrndva-omta03.mail.rr.com>

I don't think a checking to see if the logged in user name is different =
from
the credentials user is that much additional overhead.

M*

> -----Original Message-----
> From: Houser, Rick [mailto:Houser.Rick@aoins.com]
> Sent: Wednesday, April 22, 2009 1:49 PM
> To: modules-dev@httpd.apache.org
> Subject: RE: Location of Apache Modules
>=20
> > Folks I've talked to just don't try to get htaccess to work with =
ajax
> for the most part.  They rely on php security.
>=20
> That's probably because on the backend, they still need to handle
> authorization.  Unless all users to your backend should have equal =
access
> to all associated data, you're going to need to handle your =
data-specific
> authorization rules anyhow.  Once session authentication is in place, =
why
> add the additional overhead of a userID check for every http request?
>=20
>=20
> Thanks,
>=20
> Rick Houser
> Auto-Owners Insurance
> Systems Support
> (517)703-2580
>=20
> -----Original Message-----
> From: Michele Waldman [mailto:mmwaldman@nyc.rr.com]
> Sent: Wednesday, April 22, 2009 1:37 PM
> To: modules-dev@httpd.apache.org
> Subject: RE: Location of Apache Modules
>=20
> I'm looking in modules/http/http_request.c.
>=20
> Is this even in the right ballpark?
>=20
> I'm hoping there's one if statement this call is failing causing the =
new
> environment not to be set.  I would think it would be like a check to =
see
> if a user is already logged in.
>=20
> But, I not familiar with http terms.  They have add_common_vars to =
setup
> the env.  But, I don't know how to force it to be implemented.  I'm =
not
> sure what a bridgade is?  But there are functions like =
ap_pass_brigade.
>=20
> Since ajax is so commonly used, I don't see why I am trying to have to
> make this work.  I'm really thinking this should already be able to be
> handled by apache.  Folks I've talked to just don't try to get =
htaccess to
> work with ajax for the most part.  They rely on php security.  I would
> like to use server security.
>=20
> I'm having trouble finding documentation on this and have been =
dragging my
> feet for two weeks on this thinking that it was going to be a quick =
fix.
>=20
> Michele
>=20
> > -----Original Message-----
> > From: Eric Covener [mailto:covener@gmail.com]
> > Sent: Tuesday, April 21, 2009 2:00 PM
> > To: modules-dev@httpd.apache.org
> > Subject: Re: Location of Apache Modules
> >
> > On Tue, Apr 21, 2009 at 12:51 PM, Michele Waldman
> > <mmwaldman@nyc.rr.com>
> > wrote:
> > > I ran a find for functions like ap_hook_auth_checker,
> > ap_run_type_checker
> > > and a few other functions.
> > >
> > > I could not find the function definitions. =A0All I could find was =
a
> > > reference to them in server/export.c.
> > >
> > > Does anyone know where all of the functions are?
> > >
> > > It's difficult to trace through the code if you can't find it.
> >
> > These functions are defined by preprocessor macros such as:
> >
> > AP_IMPLEMENT_HOOK_RUN_FIRST
> > AP_IMPLEMENT_HOOK_RUN_ALL
> >
> > The 2nd argument gets baked into function names like ap_run_XXX and
> > ap_hook_XX.
> >
> > If you're just using grep, you can usually get good results just =
using
> > the unique bit at the end. If you use something like cscope, you =
have
> > to know that you can't copy/paste to find the definitions/callers =
and
> > have to put the names together by hand.
> >
> > >
> > > I've been glancing over the server code and I see references to
> > > "subrequests".
> > >
> > > That appears what the ajax call may be. =A0I noticed the reference =
in
> > > the digest modules was the main html file, even though it was
> > > validating the credentials for the ajax file, which may be treated =
as
> a subrequest?
> >
> > subrequests are an internal notion only, e.g. some kinds of rewrites
> > or things like DirectoryIndex are handled internally as subrequests.
> > The components of SSI are subrequests as well.
> >
> > >
> > > What's throwing me for a loop, is that it is logging in with the
> > > first request, but not forcing a new login with different
> > > credentials on subsequent requests.
> >
> > Did your browser send digest credentials on the ajax request?  You =
can
> > log %{Authorization}i in the access log to quickly tell.
> >
> > If credentials were sent, can mod_log_config log a %u or were they
> > ignored (due to no Require, satisfy any, etc)?
> >
> >
> > --
> > Eric Covener
> > covener@gmail.com
>=20