[Web-SIG] Communicating authenticated user information

Herb Lainchbury herb at dynamic-solutions.com
Tue Jan 24 19:12:03 CET 2006


It seems to me that applications should be concerned only about what
applications need to be concerned about.  If an application happens to be a
login screen for a system, then that application will be concerned with
setting the userid somewhere.  

The fact that the middleware or the webserver wants to log that information
somewhere is none of the applications business.

The middleware is providing the service to the application so the middleware
gets to define the interface for those services.  One of those services is
the userid.  Most applications will just want to know the userid and can get
it by accessing wsgi.userid.   

Applications that need to modify the userid (like login & logout
applications) can do so by setting wsgi.userid.  For example: if the login
application decides that a user has entered sufficient credentials to
satisfy the authentication criteria then it just sets the wsgi.userid
attribute and it's done.

Now, if the middleware wants to do something with that value (like log it),
great, but the application doesn't need to know that and need not be
concerned with it.

There may be other values that applications can set but userid is one that
many applications will need and I prefer the specific member for this
purpose.

BTW, if authentication is being done with HTTP then there's no need for the
login and logout applications and the middleware still has the
responsibility of providing the userid attribute for applications.  The
middleware set that attribute based on the HTTP information available.

Herb Lainchbury
Dynamic Solutions Inc.
www.dynamic-solutions.com


-----Original Message-----
From: web-sig-bounces+herb=dynamic-solutions.com at python.org
[mailto:web-sig-bounces+herb=dynamic-solutions.com at python.org] On Behalf Of
Michal Wallace
Sent: Tuesday, January 24, 2006 9:36 AM
To: Jim Fulton
Cc: web-sig at python.org
Subject: Re: [Web-SIG] Communicating authenticated user information

On Tue, 24 Jan 2006, Jim Fulton wrote:

> Phillip J. Eby wrote:
> ...
> > I'm pointing out that the use case under consideration isn't specific 
> > *enough* yet.  Do people's log files support unicode?  Do the 
> > authentication systems?  This hasn't been made clear, and it should be.
>
> I agree.  I think we should be guided by the common log file format.
> Log data are written to files and are thus not unicode. The user
> info is *just* documentation, so it is really up to the app what to
> show imo.  Further, because the common log file format is space
> delimited, the user info cannot contain spaces.


I'm curious. Suppose that a subset of your site
or application requires users to log in through
an HTML form, but that for some reason there's 
also a general HTTP authentication username and 
password over the whole system.

Which username should the web server log?

I think you guys are trying to solve this at
the wrong level. This problem should be 
handled by the web server itself. Even if you
want to use your own custom forms, there is
already a really nice solution to this problem
for apache:

http://aspn.activestate.com/ASPN/CodeDoc/Apache-AuthCookie/AuthCookie.html

If a particular webserver doesn't allow this
sort of approach, then maybe the work should 
be done there?

Meanwhile, you can always do your own logging
for the events you actually want to record at
the application layer.

Maybe I just don't understand why this is 
important. Can someone (Jim) explain why this
is a requirement in the first place?

Sincerely,
 
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: michal at sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
-------------------------------------

_______________________________________________
Web-SIG mailing list
Web-SIG at python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/herb%40dynamic-solutions.com



More information about the Web-SIG mailing list