quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton (JIRA)" <j...@apache.org>
Subject [jira] Created: (MODPYTHON-30) mod_python.publisher nested authentication details
Date Tue, 08 Mar 2005 22:32:52 GMT
mod_python.publisher nested authentication details
--------------------------------------------------

         Key: MODPYTHON-30
         URL: http://issues.apache.org/jira/browse/MODPYTHON-30
     Project: mod_python
        Type: Bug
  Components: publisher  
    Versions: 3.1.4    
    Reporter: Graham Dumpleton


In Apache, if one has a directory which uses authentication, eg:

AuthType Basic
AuthName "Warner Bros"
AuthUserFile /Users/grahamd/Sites/auth/pwdb
Require user daffy

and then in that directory there is a subdirectory which also uses authentication, eg:

AuthType Basic
AuthName "Disney Land"
AuthUserFile /Users/grahamd/Sites/auth/subdir/pwdb
Require user mickey

If one accesses the parent directory, one is prompted for password in realm "Warner Bros"
and entering appropriate login/passwd will result in files being returned.

If one accesses the subdirectory, one is prompted for password in realm "Disney Land"
and entering appropriate login/passwd will result in files being returned.

One can now quite happily move between the two directories without having to supply
login/passwd again and files will be returned.

If one attempts to do the same thing with authentication mechanisms which are available
in mod_python.publisher it will not work if one tries to access the subdirectory, The
browser will get itself stuck in a continual loop, alternating between trying supply the
appropriate credentials for the parent directory and subdirectory.

Code for mod_python.publisher which should show the problem is:

__auth_realm__ = "Warner Bros"
__auth__ = { "daffy": "duck" }

def method1():
  return "method1"

class Object1:

  __auth_realm__ = "Disney Land"
  __auth__ = { "donald": "duck" }

  def method2(self):
    return "method2"

object1 = Object1()

The problem derives from the fact that mo_python.publisher resolves authentication
information while it is traversing to find an object. This means it first requests for
credentials for "Warner Bros". When that is supplied and satisfied, further down the
traversal it finds "Disney Land" and thus asks for that instead. Because the traversal
always starts at the top for each request, it hits "Warner Bros" again, but browser has
supplied "Disney Land" and fails. Browser automatically supplies "Warner Bros" and
gets past that but fails again on "Disney Land". This then cycles with browser continually
requesting adinfinitum.

It seems that the strategy should be not to authenticate while traversing, but simply
accumulate authentication calls at each level and then determine which is the most
deeply nested set which should be applied, rather than applying all of the them. This
would then make it behave the same as native Apache mechanism and browser would
get stuck in a loop.

Some more investigation needs to be done on this yet to determine what constitutes
the top of a authentication realm. It is clear if both __auth_realm__ and __auth__ are
defined at the same level, but what if only one is. If only __auth__ is supplied, should
the realm default to "unknown". If the __auth_realm__ is supplied but not __auth__
does that mean no authentication is applied and everyone is let in at that point. If a
subsequent nested scope then defines __auth__, does it inherit the __auth_realm__
from the parent.

To complicate things, if a resource does not exist, the authentication has to be
applied before not found is returned to be consistent with Apache. Ie., even if resource
does not exist, one has to accumulate auth details and work out most nested even for
the failed request and request authentication is supplied by user first.

All this needs to be compared to Apache to see what it does. More details later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


Mime
View raw message