Re: mod_python 3.2.7 available for testing
2006/2/8, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>: > > On Tue, 7 Feb 2006, Graham Dumpleton wrote: > > > I'll also say +1 as core group vote. This means all 4 have voted > > as +1 and no need to wait 72 hours now to see if I would veto it. > > OK, I stuck the file on apache.org/dist for mirrors to pick it up. Next > step is the download page change, then the announcement. > > Nicolas - do we have a win32 file as well? > > Grisha > [Sorry for the duplicate mail, Grisha] Yup, you can download them from http://nicolas.lehuen.com/download/mod_python/ Regards, Nicolas
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Sébastien Arnaud wrote: Hi, I would like to report: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 After replacing the troubling line (line 3038, configure): from: MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` to (Deron's 1st suggestion): MP_VERSION=`echo $MP_VERSION | sed 's/"//g' ` I guess now it's up to you to decide if you want to integrate the patch or if you want to leave it as is for this release ;) In the interest of actually *releasing* something I think this should wait for a future bug fix release. In the interim the fix is simple enough that someone on an affected platform can manually change configure.in. It's not an ideal solution, but then neither is an endless series of beta and release candidates. ;) I'll create a JIRA issue so this doesn't get lost. Jim
[jira] Created: (MODPYTHON-122) configure fails when using bash 3.1.x
configure fails when using bash 3.1.x - Key: MODPYTHON-122 URL: http://issues.apache.org/jira/browse/MODPYTHON-122 Project: mod_python Type: Bug Components: core Versions: 3.1.4, 3.2 Environment: Any platform using bash 3.1.x Reporter: Jim Gallacher Assigned to: Jim Gallacher Priority: Minor A bug in bash 3.1 causes configure to fail. This has been report on recent versions of Gentoo and and deicussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\"//g` fixes it for bash 3.1. I wonder why we are using \\" since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) on my system just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest we either adopt the gentoo fix, or avoid the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d '"'` -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MODPYTHON-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=all ] Jim Gallacher updated MODPYTHON-122: Description: A bug in bash 3.1 causes configure to fail. This has been reported on recent versions of Gentoo and and discussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\"//g` fixes it for bash 3.1. I wonder why mod_python is using \\" since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest mod_python adopts the gentoo fix, or avoids the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d '"'` was: A bug in bash 3.1 causes configure to fail. This has been report on recent versions of Gentoo and and deicussed on the mod_python mailing list: http://bugs.gentoo.org/show_bug.cgi?id=118948 http://www.modpython.org/pipermail/mod_python/2006-January/019965.html http://www.modpython.org/pipermail/mod_python/2006-January/019969.html According to the gentoo bug report, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\"//g` fixes it for bash 3.1. I wonder why we are using \\" since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) on my system just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest we either adopt the gentoo fix, or avoid the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d '"'` > configure fails when using bash 3.1.x > - > > Key: MODPYTHON-122 > URL: http://issues.apache.org/jira/browse/MODPYTHON-122 > Project: mod_python > Type: Bug > Components: core > Versions: 3.1.4, 3.2 > Environment: Any platform using bash 3.1.x > Reporter: Jim Gallacher > Assignee: Jim Gallacher > Priority: Minor > > A bug in bash 3.1 causes configure to fail. This has been reported on recent > versions of Gentoo and and discussed on the mod_python mailing list: > http://bugs.gentoo.org/show_bug.cgi?id=118948 > http://www.modpython.org/pipermail/mod_python/2006-January/019965.html > http://www.modpython.org/pipermail/mod_python/2006-January/019969.html > According to the gentoo bug report, the problem in configure.in is the double > backslash escape sequence in the line: > MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` > Changing this to: > MP_VERSION=`echo $MP_VERSION | sed s/\"//g` > fixes it for bash 3.1. > I wonder why mod_python is using \\" since the gentoo fix seems to work ok > with bash 3.0 (and GNU sed) just as well. Is it there to support other > shells, other sed versions, older bash versions... ?? > I suggest mod_python adopts the gentoo fix, or avoids the problem altogether > by using tr. eg. > MP_VERSION=`echo $MP_VERSION | tr -d '"'` -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Hooking handler with ap_hook_map_to_storage().
On Tue, 7 Feb 2006, Graham Dumpleton wrote: /* [2 1/2] map filename to storage */ ap_hook_map_to_storage(PythonStorageHandler, NULL, NULL, APR_HOOK_MIDDLE); The function name doesn't ring a bell, so I probably was not aware of it. Could this be something more recent than the last release of mod_python? In any event - sounds like an interesting idea. Grisha
Re: mod_python 3.2.7 available for testing
I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Grisha
Re: mod_python 3.2.7 available for testing
+1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 Jim Gallacher wrote: Mod_python 3.2.7 tarball is available for test. Here's hoping this will be to final time we need your help testing before the official release. 3.2.7 adds a fix for the connection read issue that was causing problems on FreeBSD. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you for your assistance, Jim Gallacher
Re: Hooking handler with ap_hook_map_to_storage().
On 2/7/06, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]> wrote: > On Tue, 7 Feb 2006, Graham Dumpleton wrote: > > > /* [2 1/2] map filename to storage */ > > ap_hook_map_to_storage(PythonStorageHandler, > >NULL, NULL, APR_HOOK_MIDDLE); > > The function name doesn't ring a bell, so I probably was not aware of it. > Could this be something more recent than the last release of mod_python? > In any event - sounds like an interesting idea. Hmm. I wasn't aware of these hooks either. But I agree it does sound quite interesting (and potentially useful). I need to go read up on them some more. -- Deron Meranda
Re: mod_python 3.2.7 available for testing
Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 Jim
Re: mod_python 3.2.7 available for testing
OK so my core group vote is +1 for this release. It has been tested on a wide array of OSes, both threaded and forked MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test on MacOSX and Solaris would have been great but maybe the recommended MPM on those platform is the forked one, so we don't have to worry about those. Regards, Nicolas 2006/2/7, Jim Gallacher <[EMAIL PROTECTED]>: > Gregory (Grisha) Trubetskoy wrote: > > > > I think we have enough +1's. (If someone could tally them up in a single > > e-mail, that'd be great.) Should we start a core-group vote, or wait > > some more? On the bash issue - I think we can leave it as is, the > > affected distros will just have to maintain a patch in their build systems. > > Let's vote. > > Here is the test summary: > > +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 > +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 > +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 > +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 > +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 > +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 > +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 > +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 > +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 > +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 > +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 > +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 > +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 > +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 > > With configure fixed manually to deal with bash bug: > +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 > > Plus we have the following tests from the svn revision which corresponds > to 3.2.7: > +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 > > Jim >
Re: mod_python 3.2.7 available for testing
I assumed we would have a separate thread for the core vote, but what the heck. :) +1 is my core vote. Jim Nicolas Lehuen wrote: OK so my core group vote is +1 for this release. It has been tested on a wide array of OSes, both threaded and forked MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test on MacOSX and Solaris would have been great but maybe the recommended MPM on those platform is the forked one, so we don't have to worry about those. Regards, Nicolas 2006/2/7, Jim Gallacher <[EMAIL PROTECTED]>: Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 Jim
Re: mod_python 3.2.7 available for testing
On Tue, 7 Feb 2006, Jim Gallacher wrote: I assumed we would have a separate thread for the core vote, but what the heck. :) +1 is my core vote. +1 from me as well. Grisha
Re: mod_python 3.2.7 available for testing
Gregory (Grisha) Trubetskoy wrote: On Tue, 7 Feb 2006, Jim Gallacher wrote: I assumed we would have a separate thread for the core vote, but what the heck. :) +1 is my core vote. +1 from me as well. When the core group votes for a release candidate, is it a consensus vote or a majority vote? To quote from the Apache voting guidelines, "An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes)". My interpretation of the rest of guideline is that a consensus vote is only required for actual code changes. Perhaps we should set our own policy for a vote on a release candidate? See http://httpd.apache.org/dev/guidelines.html. If this is a majority vote, then the polls are closed and 3.2.7 is the winner. :) (And I didn't even use a calulator this time. ;) ) Jim
[jira] Commented: (MODPYTHON-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=comments#action_12365490 ] Graham Dumpleton commented on MODPYTHON-122: Or as someone else suggested, maybe: MP_VERSION=`echo $MP_VERSION | sed 's/"//g'` or: MP_VERSION=`echo $MP_VERSION | sed 's/["]//g'` The single quotes should be enough to protect it without needing a slash. > configure fails when using bash 3.1.x > - > > Key: MODPYTHON-122 > URL: http://issues.apache.org/jira/browse/MODPYTHON-122 > Project: mod_python > Type: Bug > Components: core > Versions: 3.2, 3.1.4 > Environment: Any platform using bash 3.1.x > Reporter: Jim Gallacher > Assignee: Jim Gallacher > Priority: Minor > > A bug in bash 3.1 causes configure to fail. This has been reported on recent > versions of Gentoo and and discussed on the mod_python mailing list: > http://bugs.gentoo.org/show_bug.cgi?id=118948 > http://www.modpython.org/pipermail/mod_python/2006-January/019965.html > http://www.modpython.org/pipermail/mod_python/2006-January/019969.html > According to the gentoo bug report, the problem in configure.in is the double > backslash escape sequence in the line: > MP_VERSION=`echo $MP_VERSION | sed s/\\"//g` > Changing this to: > MP_VERSION=`echo $MP_VERSION | sed s/\"//g` > fixes it for bash 3.1. > I wonder why mod_python is using \\" since the gentoo fix seems to work ok > with bash 3.0 (and GNU sed) just as well. Is it there to support other > shells, other sed versions, older bash versions... ?? > I suggest mod_python adopts the gentoo fix, or avoids the problem altogether > by using tr. eg. > MP_VERSION=`echo $MP_VERSION | tr -d '"'` -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: mod_python 3.2.7 available for testing
On Feb 7, 2006, at 9:32 AM, Jim Gallacher wrote: When the core group votes for a release candidate, is it a consensus vote or a majority vote? To quote from the Apache voting guidelines, "An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes)". Release votes are majority votes. That prevents some forms of voting abuse and allows progress to be made even when it isn't perfect. My interpretation of the rest of guideline is that a consensus vote is only required for actual code changes. Perhaps we should set our own policy for a vote on a release candidate? See http://httpd.apache.org/dev/guidelines.html. If this is a majority vote, then the polls are closed and 3.2.7 is the winner. :) (And I didn't even use a calulator this time. ;) ) We usually wait for 72 hours or until all the voters vote, since some times it only takes one discovered failure to cause everyone else to change their votes. Roy
Re: mod_python 3.2.7 available for testing
Nicolas Lehuen wrote .. > OK so my core group vote is +1 for this release. > > It has been tested on a wide array of OSes, both threaded and forked > MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test > on MacOSX and Solaris would have been great but maybe the recommended > MPM on those platform is the forked one, so we don't have to worry > about those. My vote is redundant again, but I can add one of the configurations that Nicolas wanted to see: +1 MacOSX 10.3.9 PPC, Apache-2.0.55-worker, Python-2.3 I'll also say +1 as core group vote. This means all 4 have voted as +1 and no need to wait 72 hours now to see if I would veto it. I'm too busy anyway, finding new features/improvements to add to JIRA, to look at 3.2.7 in particular to find bugs. ;-) Graham > Regards, > Nicolas > > 2006/2/7, Jim Gallacher <[EMAIL PROTECTED]>: > > Gregory (Grisha) Trubetskoy wrote: > > > > > > I think we have enough +1's. (If someone could tally them up in a single > > > e-mail, that'd be great.) Should we start a core-group vote, or wait > > > some more? On the bash issue - I think we can leave it as is, the > > > affected distros will just have to maintain a patch in their build > systems. > > > > Let's vote. > > > > Here is the test summary: > > > > +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 > > +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 > > +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 > > +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 > > +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 > > +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 > > +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 > > +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 > > +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 > > +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 > > +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 > > +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 > > +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 > > +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 > > > > With configure fixed manually to deal with bash bug: > > +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 > > > > Plus we have the following tests from the svn revision which corresponds > > to 3.2.7: > > +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 > > > > Jim > >
Re: mod_python 3.2.7 available for testing
On Tue, 7 Feb 2006, Graham Dumpleton wrote: I'll also say +1 as core group vote. This means all 4 have voted as +1 and no need to wait 72 hours now to see if I would veto it. OK, I stuck the file on apache.org/dist for mirrors to pick it up. Next step is the download page change, then the announcement. Nicolas - do we have a win32 file as well? Grisha
[jira] Created: (MODPYTHON-124) Improvements associated with the req.ap_auth_type attribute.
Improvements associated with the req.ap_auth_type attribute. Key: MODPYTHON-124 URL: http://issues.apache.org/jira/browse/MODPYTHON-124 Project: mod_python Type: Improvement Components: core Versions: 3.3 Reporter: Graham Dumpleton The "req.ap_auth_type" attribute is set to the authentication type corresponding to the type of authentication processing successfully carried out in respect of a request. For example, if one has Apache configuration: AuthType Basic AuthName "Restricted Files" AuthUserFile /usr/local/apache/passwd/passwords Require valid-user it is expected that the request uses basic authentication header as appropriate. These headers will be dealt with by inbuilt Apache core module. Upon successful authentication, the Apache core module will set "req.ap_auth_type" attribute to be "Basic" and set "req.user" to the user ID of the logged in user. If instead Apache support for digest authentication was used, eg: AuthType Digest ... then "req.ap_auth_type" attribute will be set to "Digest". If authentication was not requested, ie., no AuthType directive, the "req.ap_auth_type" is set to Python None. The intent is that you should be able to implement authentication handlers in mod_python using PythonAuthenHandler, but you can't actually do this correctly at the moment as there are a few things missing. Firstly, in order to trigger the PythonAuthenHandler, you must still define the AuthType/AuthName/Require directives. In order to ensure that our authentication handler is triggered and not the builtin ones or some other one, the AuthType directive should specify a string other than "Basic" or "Digest". This would be a name we choose and can basically be anything. For example, you might choose a descriptive name like "Python-Basic-DBM" to denote basic authentication is used against a DBM database but using the Python authentication handler. AuthType Python-Basic-DBM AuthName "Web Application" Require valid-user PythonAuthenHandler basicdbmauth PythonOption basicdbmauth.UserDatabase /.../users.dbm When the authentication handler in "basicdbmauth" is called, the "req.ap_auth_type" field is still None. This is because authentication hasn't succeed yet. In terms of being able to implement the authentication handler correctly, the first problem is that there is no way to access the actual value associated with the AuthType directive. This needs to be consulted to determine if the authentication handler should actually do anything. Second is that the value associated with the AuthName directive can't be determined either, something which may influence against which database authentication should be done. Thus first lot of changes that need to be made are that "req" object needs to have two new methods called "get_auth_type()" and "get_auth_name()". These will map to the Apache API functions called "ap_auth_type()" and "ap_auth_name()". Note that "ap_auth_type()" is returning a different value to "req.ap_auth_type". With those two functions, authentication handler can then be written as: def authenhandler(req): if req.get_auth_type() != "Python-Basic-DBM": return apache.DECLINED realm = req.get_auth_name() # Do all the processing of Authorization header and # validate user etc. If not okay, return appropriate error # status. If okay, keep going. req.user = ... from header req.ap_auth_type = "Python-Basic-DBM" return apache.OK As well as returning apache.OK, convention is to set "req.user" and "req.ap_auth_type". This is where the final problem occurs. That is that "req.ap_auth_type" is read only and cannot actually be set as necessary. Thus in addition to "req.get_auth_type()", "req.get_auth_name()", need to make "req.ap_auth_type" writable. Having made these changes it would then actually be possible to write authentication handlers correctly, ie., whereby they correctly look at AuthType etc to see whether they should be applied. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MODPYTHON-124) Improvements associated with the req.ap_auth_type attribute.
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=comments#action_12365525 ] Graham Dumpleton commented on MODPYTHON-124: FWIW, where example gave: # Do all the processing of Authorization header and # validate user etc. If not okay, return appropriate error # status. If okay, keep going. req.user = ... from header req.ap_auth_type = "Python-Basic-DBM" If "req.get_basic_auth_pw()" were used to do the decoding of the "Authorization" header, the "req.user" and "req.ap_auth_type" fields would have been automatically populated with the user ID and auth type of "Basic" respectively. The "req.ap_auth_type" attribute still needs to be writable though if it was desired that totally new or unsupported authorisation schemes needed to be implemented. > Improvements associated with the req.ap_auth_type attribute. > > > Key: MODPYTHON-124 > URL: http://issues.apache.org/jira/browse/MODPYTHON-124 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.3 > Reporter: Graham Dumpleton > > The "req.ap_auth_type" attribute is set to the authentication type > corresponding to the type of authentication processing successfully carried > out in respect of a request. For example, if one has Apache configuration: > AuthType Basic > AuthName "Restricted Files" > AuthUserFile /usr/local/apache/passwd/passwords > Require valid-user > it is expected that the request uses basic authentication header as > appropriate. These headers will be dealt with by inbuilt Apache core module. > Upon successful authentication, the Apache core module will set > "req.ap_auth_type" attribute to be "Basic" and set "req.user" to the user ID > of the logged in user. > If instead Apache support for digest authentication was used, eg: > AuthType Digest > ... > then "req.ap_auth_type" attribute will be set to "Digest". > If authentication was not requested, ie., no AuthType directive, the > "req.ap_auth_type" is set to Python None. > The intent is that you should be able to implement authentication handlers in > mod_python using PythonAuthenHandler, but you can't actually do this > correctly at the moment as there are a few things missing. > Firstly, in order to trigger the PythonAuthenHandler, you must still define > the AuthType/AuthName/Require directives. In order to ensure that our > authentication handler is triggered and not the builtin ones or some other > one, the AuthType directive should specify a string other than "Basic" or > "Digest". This would be a name we choose and can basically be anything. For > example, you might choose a descriptive name like "Python-Basic-DBM" to > denote basic authentication is used against a DBM database but using the > Python authentication handler. > AuthType Python-Basic-DBM > AuthName "Web Application" > Require valid-user > PythonAuthenHandler basicdbmauth > PythonOption basicdbmauth.UserDatabase /.../users.dbm > When the authentication handler in "basicdbmauth" is called, the > "req.ap_auth_type" field is still None. This is because authentication hasn't > succeed yet. > In terms of being able to implement the authentication handler correctly, the > first problem is that there is no way to access the actual value associated > with the AuthType directive. This needs to be consulted to determine if the > authentication handler should actually do anything. Second is that the value > associated with the AuthName directive can't be determined either, something > which may influence against which database authentication should be done. > Thus first lot of changes that need to be made are that "req" object needs to > have two new methods called "get_auth_type()" and "get_auth_name()". These > will map to the Apache API functions called "ap_auth_type()" and > "ap_auth_name()". Note that "ap_auth_type()" is returning a different value > to "req.ap_auth_type". > With those two functions, authentication handler can then be written as: > def authenhandler(req): > if req.get_auth_type() != "Python-Basic-DBM": > return apache.DECLINED > realm = req.get_auth_name() > # Do all the processing of Authorization header and > # validate user etc. If not okay, return appropriate error > # status. If okay, keep going. > req.user = ... from header > req.ap_auth_type = "Python-Basic-DBM" > return apache.OK > As well as returning apache.OK, convention is to set "req.user" and > "req.ap_auth_type". > This is where the final problem occurs. That is that "req.ap_auth_type" is > read only and cannot actually be set as necessary. > Thus in addition to "req.get_auth_type()", "req.get_auth_name()", need to > make "req.ap_auth_type" writable. > Having made these changes it would then actually be possible to write > authentication handle
