Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Location of Apache Modules
Date: Wed, 22 Apr 2009 13:49:12 -0400
Message-ID: <A84920684DBB3746A1BEA1296EC9E4EB0324F561@EXCVSRV2.aoins.com>
In-Reply-To: <20090422173706540.OZXL16411@hrndva-omta01.mail.rr.com>
Thread-Topic: Location of Apache Modules
Thread-Index: AcnCqwZwtd+F4TSpRKGfHqdE7VT3NQAxL1yQAACRSNA=
From: "Houser, Rick" <Houser.Rick@aoins.com>
To: modules-dev@httpd.apache.org
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> 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.

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?


Thanks,

Rick Houser
Auto-Owners Insurance
Systems Support
(517)703-2580

-----Original Message-----
From: Michele Waldman [mailto:mmwaldman@nyc.rr.com]=20
Sent: Wednesday, April 22, 2009 1:37 PM
To: modules-dev@httpd.apache.org
Subject: RE: Location of Apache Modules

I'm looking in modules/http/http_request.c.

Is this even in the right ballpark?

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.

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.

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.

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.

Michele

> -----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
>=20
> On Tue, Apr 21, 2009 at 12:51 PM, Michele Waldman=20
> <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.
>=20
> These functions are defined by preprocessor macros such as:
>=20
> AP_IMPLEMENT_HOOK_RUN_FIRST
> AP_IMPLEMENT_HOOK_RUN_ALL
>=20
> The 2nd argument gets baked into function names like ap_run_XXX and=20
> ap_hook_XX.
>=20
> 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=20
> to know that you can't copy/paste to find the definitions/callers and=20
> have to put the names together by hand.
>=20
> >
> > I've been glancing over the server code and I see references to=20
> > "subrequests".
> >
> > That appears what the ajax call may be. =A0I noticed the reference =
in=20
> > the digest modules was the main html file, even though it was=20
> > validating the credentials for the ajax file, which may be treated =
as a subrequest?
>=20
> subrequests are an internal notion only, e.g. some kinds of rewrites=20
> or things like DirectoryIndex are handled internally as subrequests.
> The components of SSI are subrequests as well.
>=20
> >
> > What's throwing me for a loop, is that it is logging in with the=20
> > first request, but not forcing a new login with different=20
> > credentials on subsequent requests.
>=20
> Did your browser send digest credentials on the ajax request?  You can =

> log %{Authorization}i in the access log to quickly tell.
>=20
> If credentials were sent, can mod_log_config log a %u or were they=20
> ignored (due to no Require, satisfy any, etc)?
>=20
>=20
> --
> Eric Covener
> covener@gmail.com