At the HTTP layer, there is no such thing as a logged in user (stateless 
protocol and all), so I assume you must be referring to application specific, 
session based code.  Consider this case:

Alice   - user in group X, Z
Brian   - user in group X, Y

Assume your server handles the authentication, phase.  Now, you know that Alice 
is really Alice, but you still have to confirm that groups X+Z is sufficient 
for the data she's trying to access (otherwise Brian could see it).  That very 
likely is going to require some backend call, which could hit a database, 
perform some calculations, access a remote machine, etc.  Now, you very likely 
also have to do something similar in the authentication phase.  So, that 
combination can double the base load on your authentication subsystem.  By 
contrast, you can just keep that information on the web-server, retrieved via 
session, and spare much of the associated load on the 
authentication/authorization systems.  That can get you down to a fraction of 
the base load, saving a big site one or more LDAP slaves.



Thanks,

Rick Houser
Auto-Owners Insurance
Systems Support

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

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.r...@aoins.com]
> Sent: Wednesday, April 22, 2009 1:49 PM
> To: modules-dev@httpd.apache.org
> Subject: RE: Location of Apache Modules
> 
> > 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:mmwald...@nyc.rr.com]
> 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:cove...@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 
> > <mmwald...@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.  All 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.  I 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
> > cove...@gmail.com
> 




Reply via email to