[jira] Updated: (MODPYTHON-119) DBM Session test shouldn't use default database.
[ http://issues.apache.org/jira/browse/MODPYTHON-119?page=all ]
Jim Gallacher updated MODPYTHON-119:
Fix Version: 3.2.x
(was: 3.3)
> DBM Session test shouldn't use default database.
>
>
> Key: MODPYTHON-119
> URL: http://issues.apache.org/jira/browse/MODPYTHON-119
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.7
> Reporter: Graham Dumpleton
> Assignee: Jim Gallacher
> Fix For: 3.2.x
>
> The test_Session_Session_conf() of test/test.py doesn't override the default
> DBM session database name that would be used for prefork/worker MPM variants.
> This means that if there is already an instance of Apache running as its
> designated user which has already created the session database and the tests
> are run as a different user, the test will fail. Further, if mod_python has
> never previously been used and no session database exists, the test will
> succeed, but when someone goes to use sessions in the installed mod_python,
> it will fail in the case where the session database created by the test was
> as a different user to that which Apache runs as.
> The test suite should ensure that it overrides any defaults and stores such
> databases in test suite document tree. It should possibly also ensure that
> such transient files are removed so as not to create a problem on subsequent
> tests.
> Test might therefore be changed to:
> def test_Session_Session_conf(self):
> database = os.path.join(TESTHOME,"mp_sess_test.dbm")
> c = VirtualHost("*",
> ServerName("test_Session_Session"),
> DocumentRoot(DOCUMENT_ROOT),
> Directory(DOCUMENT_ROOT,
> PythonOption('session_dbm "%s"' % database),
> SetHandler("mod_python"),
> PythonHandler("tests::Session_Session"),
> PythonDebug("On")))
> return str(c)
--
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: Fix Version: 3.2.x (was: 3.3) > 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.7 > Environment: Any platform using bash 3.1.x > Reporter: Jim Gallacher > Assignee: Jim Gallacher > Priority: Minor > Fix For: 3.2.x > > 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
[jira] Assigned: (MODPYTHON-108) Let Cookie support new HttpOnly property to prevent cross-site cookie stealing
[ http://issues.apache.org/jira/browse/MODPYTHON-108?page=all ] Jim Gallacher reassigned MODPYTHON-108: --- Assign To: Jim Gallacher > Let Cookie support new HttpOnly property to prevent cross-site cookie stealing > -- > > Key: MODPYTHON-108 > URL: http://issues.apache.org/jira/browse/MODPYTHON-108 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.2.7, 3.1.4, 3.3 > Reporter: Deron Meranda > Assignee: Jim Gallacher > Priority: Minor > > The Cookie.Cookie class does not allow the new "httponly" cookie property to > be set. It needs to be added to the valid slots on the cookie metaclass. > Also note that like the "secure" cookie attribute, it is simple a boolean > flag without any value. > The HttpOnly flag was invented by Microsoft but seeing widespread support as > a way to prevent cross-site scripting from stealing cookies using client-side > Javascript. This is especially important for security-sensitive cookies, > such as session keys. > The mod_python session object should also explicitly set the HttpOnly > property on the cookies it creates. > See also these related references: > 1. http://msdn.microsoft.com/workshop/author/dhtml/httponly_cookies.asp > 2. > http://search.cpan.org/~mschout/Apache-AuthCookie-3.08/lib/Apache2/AuthCookie.pm > 3. https://bugzilla.mozilla.org/show_bug.cgi?id=178993 > 4. > http://www.linux.com/howtos/Secure-Programs-HOWTO/cross-site-malicious-content.shtml -- 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] Assigned: (MODPYTHON-131) Make name of mutex directory configurable.
[ http://issues.apache.org/jira/browse/MODPYTHON-131?page=all ] Jim Gallacher reassigned MODPYTHON-131: --- Assign To: Jim Gallacher > Make name of mutex directory configurable. > -- > > Key: MODPYTHON-131 > URL: http://issues.apache.org/jira/browse/MODPYTHON-131 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.2.7 > Reporter: Graham Dumpleton > Assignee: Jim Gallacher > > Creating an issue for this so it can be tracked. > Been pointed out in: > http://www.mail-archive.com/python-dev@httpd.apache.org/msg01271.html > that on Mandriva Linux, that is is necessary to manually change the mutex > directory in mod_python.c source code. Area of code is: > #if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE) > char fname[255]; > snprintf(fname, 255, "/tmp/mpmtx%d%d", glb->parent_pid, n); > #else > char *fname = NULL; > #endif > There should be an option to configure program to allow this to be more > easily changed. > Way of changing the value through Apache configuration to also be > investigated further. -- 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] Assigned: (MODPYTHON-111) Sessions don't set accessed time on read
[ http://issues.apache.org/jira/browse/MODPYTHON-111?page=all ] Jim Gallacher reassigned MODPYTHON-111: --- Assign To: Jim Gallacher > Sessions don't set accessed time on read > > > Key: MODPYTHON-111 > URL: http://issues.apache.org/jira/browse/MODPYTHON-111 > Project: mod_python > Type: Bug > Components: documentation, session > Versions: 3.1.4 > Environment: Suse 10, Apache2 worker > Reporter: Sebastjan Trepca > Assignee: Jim Gallacher > > When you read or access session it does not set new accessed time so it > eventually dies(depends on the timeout). > It only sets the accessed time when you save the session and that is not how > sessions normally function(at least not on all other systems). IMHO it should > set its accessed time when it was actually accessed and not only when saved. > A bit more about this issue can be found here: > http://www.modpython.org/pipermail/mod_python/2006-January/019889.html -- 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] Resolved: (MODPYTHON-119) DBM Session test shouldn't use default database.
[ http://issues.apache.org/jira/browse/MODPYTHON-119?page=all ]
Jim Gallacher resolved MODPYTHON-119:
-
Fix Version: 3.3
Resolution: Fixed
> DBM Session test shouldn't use default database.
>
>
> Key: MODPYTHON-119
> URL: http://issues.apache.org/jira/browse/MODPYTHON-119
> Project: mod_python
> Type: Bug
> Components: core
> Versions: 3.2.7
> Reporter: Graham Dumpleton
> Assignee: Jim Gallacher
> Fix For: 3.3
>
> The test_Session_Session_conf() of test/test.py doesn't override the default
> DBM session database name that would be used for prefork/worker MPM variants.
> This means that if there is already an instance of Apache running as its
> designated user which has already created the session database and the tests
> are run as a different user, the test will fail. Further, if mod_python has
> never previously been used and no session database exists, the test will
> succeed, but when someone goes to use sessions in the installed mod_python,
> it will fail in the case where the session database created by the test was
> as a different user to that which Apache runs as.
> The test suite should ensure that it overrides any defaults and stores such
> databases in test suite document tree. It should possibly also ensure that
> such transient files are removed so as not to create a problem on subsequent
> tests.
> Test might therefore be changed to:
> def test_Session_Session_conf(self):
> database = os.path.join(TESTHOME,"mp_sess_test.dbm")
> c = VirtualHost("*",
> ServerName("test_Session_Session"),
> DocumentRoot(DOCUMENT_ROOT),
> Directory(DOCUMENT_ROOT,
> PythonOption('session_dbm "%s"' % database),
> SetHandler("mod_python"),
> PythonHandler("tests::Session_Session"),
> PythonDebug("On")))
> return str(c)
--
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] Resolved: (MODPYTHON-122) configure fails when using bash 3.1.x
[ http://issues.apache.org/jira/browse/MODPYTHON-122?page=all ] Jim Gallacher resolved MODPYTHON-122: - Fix Version: 3.3 Resolution: Fixed > 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.7 > Environment: Any platform using bash 3.1.x > Reporter: Jim Gallacher > Assignee: Jim Gallacher > Priority: Minor > Fix For: 3.3 > > 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
[jira] Resolved: (MODPYTHON-135) [SECURITY] A Security Issue with FileSession in 3.2.7
[ http://issues.apache.org/jira/browse/MODPYTHON-135?page=all ] Jim Gallacher resolved MODPYTHON-135: - Resolution: Fixed Fix has been ported from 3.2.x to trunk. > [SECURITY] A Security Issue with FileSession in 3.2.7 > - > > Key: MODPYTHON-135 > URL: http://issues.apache.org/jira/browse/MODPYTHON-135 > Project: mod_python > Type: Bug > Components: session > Versions: 3.2.7 > Reporter: Graham Dumpleton > Assignee: Jim Gallacher > Fix For: 3.2.8 > > As announced on the mailing list: > http://www.modpython.org/pipermail/mod_python/2006-February/020284.html > If you are using the recently released mod_python 3.2.7 please beware that a > security issue was discovered in the FileSession code. > You are vulnerable only if you are using mod_python 3.2.7 AND you are using > FileSession to keep sessions. FileSession is new in 3.2.7 and is not enabled > by > default, therefore if you are using mod_python Session in its default > configuration you are not vulnerable. > The extent of this vulnerability is limited. Only a user who already has an > account (or some ability to write to the filesystem) on the system running > httpd could exploit it, and to the best of our knowledge such a user could > potentially cause httpd to execute arbitrary code. > We are working on a security release of the next version of mod_python and > expect it to be out shortly. Until then, please do not use FileSession. -- 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 workflow (was Re: My plans for mod_python changes (260206).)
Justin Erenkrantz wrote: On 3/4/06, Graham Dumpleton <[EMAIL PROTECTED]> wrote: Actually, if want to get that pedantic and formalised, it does look like one can select an alternate workflow. The level of administration access we have probably does not allow us to change it, let alone see what options exist. Come up with the workflow that everyone here feels that best suits mod_python and open a JIRA issue to get our JIRA admins to set it up as you want it. (Given I have almost no idea how this works in JIRA, I'd want Jeff or someone more knowledgable setting it up.) Use the JIRA component under the Infra project: https://issues.apache.org/jira/browse/INFRA Is this something we want to persue? Mod_python is a pretty simple project, so I'm not sure we need a really sophisticated workflow. I'll be happy if we all adopt the same policy on how and when the status of an issue is changed. (Although that "On Hold" status looks nice. ;)) Jim
Re: My plans for mod_python changes (260206).
Graham Dumpleton wrote: On 04/03/2006, at 4:59 AM, Jim Gallacher wrote: More in the way of a general observation rather than on these specific issues, but I wouldn't necessarily mark things as resolved just on the basis of the fix being committed. For the big changes at least, I think we should see some testing on a couple of different platforms. Maybe we could announce development milestones and ask the community for a round of testing? Issues would be marked as resolved after each milestone test cycle. That way we are more likely to catch problems early and hopefully reduce the time it takes for the next beta cycle. We should do whatever we can to avoid the 7 months it took to get 3.2 out. (Actually, it was even longer than that, as Grisha first mentioned a 3.2 release last spring). Ideally trunk would always be in a stable enough condition that we could do a release within a month of making a decision. Jim, have read through the JIRA documentation page you once referred me to about status values and what they mean and for "Resolved" it states: http://www.atlassian.com/software/jira/docs/v3.3.2/images/docs/ config/statuses-addstatus.png A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened and or closed. The issue for us is whether one expects a reporter to verify a fix for an issue before it has even been committed to the repository. For them it would probably be a pain to have to first checkout latest version from repository and then also apply a patch. If they do say it is okay, then by rights should verify it again after it has then been committed as who is to say the final commit isn't stuffed up somehow. I think in most cases it is too much to expect the reporter to verify a fix. To do so assumes that they are closely following mod_python and their particular issue. That may not be the case, especially if we defer the fix to a future version. The reporter may not be subscribed to python-dev and so not be aware that their bug is receiving any attention. I'm sure we've all reported bugs in other projects but never followed up. Perhaps the reporter has stopped using mod_python so the issue no longer matters to them, but it is still a bug that *we* want fixed. They way I read all the status values is that it would be quite reasonable once a fix has been committed to mark it as resolved. If the reporter then disagrees it can be reopened. If they agree it is okay, then it should be closed there and then and not wait until some milestone. If a problem is later found, then a new issue can be created and linked to the original. As I argue above I don't think we should depend too heavily on feedback from the original reporter, as I think that is the exception rather than the rule. We should use our own judgement on setting the status if we can reproduce the bug. If the bug is specific to a particular platform to which we don't have access, then a higher level of involvement from the reporter will be required. I'm not saying we should ignore feedback from the reporter, just that it shouldn't be a requirement. Without moving issues through resolved/closed in a timely fashion, too me it just makes it harder to work out where one is up to amongst the large list of issues. Agreed. I still think we should declare milestones for general testing purposes, but that is really a separate issue from this JIRA housekeeping discussion. Jim
[jira] Updated: (MODPYTHON-142) Make req.no_cache and req.no_local_copy writable.
[ http://issues.apache.org/jira/browse/MODPYTHON-142?page=all ] Graham Dumpleton updated MODPYTHON-142: --- Attachment: MP142_20060305_grahamd_1.diff Attached "MP142_20060305_grahamd_1.diff" containing proposed changes. > Make req.no_cache and req.no_local_copy writable. > - > > Key: MODPYTHON-142 > URL: http://issues.apache.org/jira/browse/MODPYTHON-142 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.2.8 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > Attachments: MP142_20060305_grahamd_1.diff > > If a handler sets req.no_cache to be true, then Apache will internally add > appropriate "Expires" header. Also the req.no_cache attribute is consulted > by mod_cache to know when not to cache. The alternative is that a handler > must know to set both: > req.headers_out['Cache-Control'] = 'no-cache' > req.headers_out['Expires'] = '-1' > It would be better to allow handlers to set req.no_cache as it isolates them > from any future changes in respect of special headers that may need to be > additionally set if standards change in any way. > Not entirely sure if req.no_local_copy attribute is somehow related. It > somehow affects whether 304 errors are returned in some cases. Certain > modules such as mod_include set this, so no reason that a mod_python handler > wouldn't want to set it also. -- 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-142) Make req.no_cache and req.no_local_copy writable.
[ http://issues.apache.org/jira/browse/MODPYTHON-142?page=all ] Graham Dumpleton updated MODPYTHON-142: --- Description: If a handler sets req.no_cache to be true, then Apache will internally add appropriate "Expires" header. Also the req.no_cache attribute is consulted by mod_cache to know when not to cache. The alternative is that a handler must know to set both: req.headers_out['Cache-Control'] = 'no-cache' req.headers_out['Expires'] = '-1' It would be better to allow handlers to set req.no_cache as it isolates them from any future changes in respect of special headers that may need to be additionally set if standards change in any way. Not entirely sure if req.no_local_copy attribute is somehow related. It somehow affects whether 304 errors are returned in some cases. Certain modules such as mod_include set this, so no reason that a mod_python handler wouldn't want to set it also. was: If a handler sets req.no_cache to be true, then Apache will internally add appropriate "Expires" header. Also the req.no_cache attribute is consulted by mod_cache to know when not to cache. The alternative is that a handler must know to set both: req.headers_out['Cache-Control'] = 'no-cache' req.headers_out['Expires'] = '-1' It would be better to allow handlers to set req.no_cache as it isolates them from any future changes in respect of special headers that may need to be additionally set if standards change in any way. Not entirely sure if req.no_local_copy attribute is somehow related. It somehow affects whether 302 errors are returned in some cases. Certain modules such as mod_include set this, so no reason that a mod_python handler wouldn't want to set it also. > Make req.no_cache and req.no_local_copy writable. > - > > Key: MODPYTHON-142 > URL: http://issues.apache.org/jira/browse/MODPYTHON-142 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.2.8 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > > If a handler sets req.no_cache to be true, then Apache will internally add > appropriate "Expires" header. Also the req.no_cache attribute is consulted > by mod_cache to know when not to cache. The alternative is that a handler > must know to set both: > req.headers_out['Cache-Control'] = 'no-cache' > req.headers_out['Expires'] = '-1' > It would be better to allow handlers to set req.no_cache as it isolates them > from any future changes in respect of special headers that may need to be > additionally set if standards change in any way. > Not entirely sure if req.no_local_copy attribute is somehow related. It > somehow affects whether 304 errors are returned in some cases. Certain > modules such as mod_include set this, so no reason that a mod_python handler > wouldn't want to set it also. -- 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] Created: (MODPYTHON-142) Make req.no_cache and req.no_local_copy writable.
Make req.no_cache and req.no_local_copy writable. - Key: MODPYTHON-142 URL: http://issues.apache.org/jira/browse/MODPYTHON-142 Project: mod_python Type: Improvement Components: core Versions: 3.2.8 Reporter: Graham Dumpleton Assigned to: Graham Dumpleton Fix For: 3.3 If a handler sets req.no_cache to be true, then Apache will internally add appropriate "Expires" header. Also the req.no_cache attribute is consulted by mod_cache to know when not to cache. The alternative is that a handler must know to set both: req.headers_out['Cache-Control'] = 'no-cache' req.headers_out['Expires'] = '-1' It would be better to allow handlers to set req.no_cache as it isolates them from any future changes in respect of special headers that may need to be additionally set if standards change in any way. Not entirely sure if req.no_local_copy attribute is somehow related. It somehow affects whether 302 errors are returned in some cases. Certain modules such as mod_include set this, so no reason that a mod_python handler wouldn't want to set it also. -- 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] Work started: (MODPYTHON-142) Make req.no_cache and req.no_local_copy writable.
[ http://issues.apache.org/jira/browse/MODPYTHON-142?page=all ] Work on MODPYTHON-142 started by Graham Dumpleton > Make req.no_cache and req.no_local_copy writable. > - > > Key: MODPYTHON-142 > URL: http://issues.apache.org/jira/browse/MODPYTHON-142 > Project: mod_python > Type: Improvement > Components: core > Versions: 3.2.8 > Reporter: Graham Dumpleton > Assignee: Graham Dumpleton > Fix For: 3.3 > > If a handler sets req.no_cache to be true, then Apache will internally add > appropriate "Expires" header. Also the req.no_cache attribute is consulted > by mod_cache to know when not to cache. The alternative is that a handler > must know to set both: > req.headers_out['Cache-Control'] = 'no-cache' > req.headers_out['Expires'] = '-1' > It would be better to allow handlers to set req.no_cache as it isolates them > from any future changes in respect of special headers that may need to be > additionally set if standards change in any way. > Not entirely sure if req.no_local_copy attribute is somehow related. It > somehow affects whether 302 errors are returned in some cases. Certain > modules such as mod_include set this, so no reason that a mod_python handler > wouldn't want to set it also. -- 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] Work started: (MODPYTHON-124) Improvements associated with the req.ap_auth_type attribute.
[ http://issues.apache.org/jira/browse/MODPYTHON-124?page=all ] Work on MODPYTHON-124 started by Graham Dumpleton > 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 > Assignee: Graham Dumpleton > Fix For: 3.3 > > 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
