[jira] Closed: (MODPYTHON-130) Improvements associated with modifications times.
[ https://issues.apache.org/jira/browse/MODPYTHON-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-130. -- Improvements associated with modifications times. - Key: MODPYTHON-130 URL: https://issues.apache.org/jira/browse/MODPYTHON-130 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 In order to be able to more easily maintain last modified response header and ETag, should expose: ap_set_etag() ap_update_mtime() ap_set_last_modified() through the request object. Ie., req.set_etag() req.update_mtime() req.set_last_modified() Direct assignment to mtime wouldn't be allowed and req.update_mtime() perfered as it will only update mtime if replacement value is newer. See mailing list for brief discussion on this: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01212.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-129) HandlerDispatch doesn't treat OK/DECLINED result properly for all phases.
[ https://issues.apache.org/jira/browse/MODPYTHON-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-129. -- HandlerDispatch doesn't treat OK/DECLINED result properly for all phases. - Key: MODPYTHON-129 URL: https://issues.apache.org/jira/browse/MODPYTHON-129 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.7 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Todays daily bug report, or is it? ;-) The Python*Handler documentation says: Multiple handlers can be specified on a single line, in which case they will be called sequentially, from left to right. Same handler directives can be specified multiple times as well, with the same result - all handlers listed will be executed sequentially, from first to last. If any handler in the sequence returns a value other than apache.OK, then execution of all subsequent handlers is aborted. That is, no matter which phase is being processed, mod_python will stop processing them if a value other than OK is returned. Problem is that this isn't how Apache itself treats the result from handlers. Apache actually implements two different ways for dealing with the result from the handlers. Which is used depends on which processing phase is occuring. This is all specified by the Apache magic macro code: AP_IMPLEMENT_HOOK_RUN_FIRST(int,translate_name, (request_rec *r), (r), DECLINED) AP_IMPLEMENT_HOOK_RUN_FIRST(int,map_to_storage, (request_rec *r), (r), DECLINED) AP_IMPLEMENT_HOOK_RUN_FIRST(int,check_user_id, (request_rec *r), (r), DECLINED) AP_IMPLEMENT_HOOK_RUN_FIRST(int,auth_checker, (request_rec *r), (r), DECLINED) AP_IMPLEMENT_HOOK_RUN_ALL(int,access_checker, (request_rec *r), (r), OK, DECLINED) AP_IMPLEMENT_HOOK_RUN_FIRST(int,type_checker, (request_rec *r), (r), DECLINED) AP_IMPLEMENT_HOOK_RUN_ALL(int,fixups, (request_rec *r), (r), OK, DECLINED) What this gobblegook expands to are loops which will stop processing handlers based on the result. For the AP_IMPLEMENT_HOOK_RUN_ALL macro, all handlers in the phase will be run unless one returns something other than OK or DECLINED. Returning OK means that it did something and it worked okay. Returing DECLINED means that it didn't do anything at all. In both these cases, it still goes onto the next handler in that phase. After that it will go onto the next phase. Returning an error will cause appropriate error response to go back to client with any other handlers in the phase, as well as later phases being skipped. Returning DONE is much like returning an error but Apache interprets it as meaning a complete response was constructed and that it doesn't have to generate any response. For the AP_IMPLEMENT_HOOK_RUN_FIRST macro, all handlers will be run only if they all return DECLINED. In other words, if a handler returns OK it will skip the following handlers in that phase and then move onto the next phase. Returning an error or DONE is like above. In the case of mod_python, what it does doesn't fit into either. It is closer to behaving like the AP_IMPLEMENT_HOOK_RUN_ALL macro except that it stops processing further handlers in the phase if DECLINED is returned. As to what problems this causes, imagine you had registered multiple authentication handlers which supported different authentication mechanisms. This is the case where AP_IMPLEMENT_HOOK_RUN_FIRST macro is used. The idea is that each authentication handler would check the value associated with the AuthType directive to determine if it should do anything. If it was not the AuthType it implements, if it were a C based handler module, it would returned DECLINED to indicate it hadn't done anything and that the next handler should instead be tried. Each handler would thus be called until one handler says that is for me, says the user is valid and returns OK or returns an error rejecting it. If you wanted to write these multiple authentication handlers in Python you can't do it. This is because the way mod_python works, if you return DECLINED it would actually skip the remainder of the mod_python declared handlers whereas you still want them to be executed. Apache would still execute any other C based handlers in the phase though. The only way to get mod_python to execute later mod_python handlers in the phase is to return OK, but if you do that and it happens to be the last handler in the mod_python list of handlers, it will return OK to Apache and
[jira] Closed: (MODPYTHON-132) Expose ap_construct_url() in request object.
[ https://issues.apache.org/jira/browse/MODPYTHON-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-132. -- Expose ap_construct_url() in request object. Key: MODPYTHON-132 URL: https://issues.apache.org/jira/browse/MODPYTHON-132 Project: mod_python Issue Type: Improvement Components: core Affects Versions: 3.3 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Apache provides the function ap_construct_url(). Its purpose is: char *ap_construct_url (pool *p, const char *uri, const request_rec *r) This function builds a fully qualified URI string from the path specified by uri, using the information stored in the request record r to determine the server name and port. The port number is not included in the string if it is the same as the default port 80. For example, imagine that the current request is directed to the virtual server www.modperl.com at port 80. Then the following call will return the string http://www.modperl.com/ index.html: char *url = ap_construct_url(r-pool, /index.html, r); This may be a solution to issue previously discussed about how to create a full URL for purpose of doing a redirect. Even if not perfect, should be exposed as req.construct_url(). After all, the Apache folks are more likely to get this correct and maintain it, better than we can do our own version in Python. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-134) Setting PythonDebug to Off, doesn't override On setting in parent scope.
[
https://issues.apache.org/jira/browse/MODPYTHON-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-134.
--
Setting PythonDebug to Off, doesn't override On setting in parent scope.
Key: MODPYTHON-134
URL: https://issues.apache.org/jira/browse/MODPYTHON-134
Project: mod_python
Issue Type: Bug
Components: core
Affects Versions: 3.2.7
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Fix For: 3.3
If you put:
PythonDebug On
in your main Apache configuration file, one would assume that you can then in
a .htaccess file say:
PythonDebug Off
and that in the .htaccess file would override that in the main Apache
configuration for any requests landing in the directory the .htaccess file is
for. That is, that PythonDebug would be Off.
You might assume this, but it doesn't work.
Similarly, even within a .htaccess file, if you have:
PythonDebug On
Files xxx
PythonDebug Off
/Files
one would assume that accessing /xxx in that directory would see
PythonDebug being Off.
That doesn't work either.
The problem comes about from the fact that each container context has a
separate table object. All these table objects are merged together, with
values in more specific containers pertaining to a request, overriding those
from a parent container. Unfortunately, in mod_python 3.X (wasn't the case in
2.7), the python_directive_flag() function was added and coded to not put an
entry in the table object for the Off case.
The current code for the python_directive_flag() function is:
static const char *python_directive_flag(void * mconfig,
char *key, int val, int set)
{
py_config *conf;
conf = (py_config *) mconfig;
if (val) {
apr_table_set(conf-directives, key, 1);
}
else {
if (set) {
apr_table_set(conf-directives, key, 0);
}
else {
apr_table_unset(conf-directives, key);
}
}
return NULL;
}
Note that the line section:
if (set) {
apr_table_set(conf-directives, key, 0);
}
was only added back in mod_python 3.2.7 specifically to fix problem with
PythonAutoReload not working as documented in MODPYTHON-106. Back in
mod_python 2.7, setting the value to 0 is what always occured, it didn't
use to use unset:
apr_table_unset(conf-directives, key);
Since the unset instead of adding in 0 was used, there was no table object
value for Off and so it can't override On in a parent container and so it
still inherits the On value. Thus why it can't be turned Off once On.
Seems the only solution is to go back to using:
static const char *python_directive_flag(void * mconfig,
char *key, int val)
{
py_config *conf;
conf = (py_config *) mconfig;
if (val) {
apr_table_set(conf-directives, key, 1);
}
else {
apr_table_set(conf-directives, key, 0);
}
return NULL;
}
But to do this, other parts of mod_python.c are going to have to be changed.
Specifically MODPYTHON-106 identified:
One can't just always set it to 0, as other code in mod_python.c uses the
fact
that an option exists to mean it is set. Ie., it doesn't check the value,
thus setting
it to 0 will cause that code to think the option used in that case
(PythonInterpPerDirectory,
PythonInterpPerDirective) is set to on when it isn't, thus causing that to
stop working
correctly.
Thus code associated with PythonInterpPerDirectory and
PythonInterpPerDirective is going to have to be changed to check the value in
the table object and see if it is 1. There seems no other choice now.
Note that any user code which also merely checks for the existing of the
directive, such as PythonDebug, without testing the value would also need to
be changed as it will potentially not work properly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-135) [SECURITY] A Security Issue with FileSession in 3.2.7
[ https://issues.apache.org/jira/browse/MODPYTHON-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-135. -- [SECURITY] A Security Issue with FileSession in 3.2.7 - Key: MODPYTHON-135 URL: https://issues.apache.org/jira/browse/MODPYTHON-135 Project: mod_python Issue Type: Bug Components: session Affects Versions: 3.2.7 Reporter: Graham Dumpleton Assigned To: Jim Gallacher Fix For: 3.3, 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. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-137) Add req.server.get_options() for obtain PythonOption values set at global level.
[ https://issues.apache.org/jira/browse/MODPYTHON-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-137. -- Add req.server.get_options() for obtain PythonOption values set at global level. Key: MODPYTHON-137 URL: https://issues.apache.org/jira/browse/MODPYTHON-137 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.3 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3, 3.2.10 Attachments: grahamd_20060228_MP137_1.diff The req.server.get_config() member seems like it is supposed to allow access to values of configuration directives set at global context. It seems though to have a few problems with it though. See MODPYTHON-133 and MODPYTHON-134. Regardless of that, it seems it may be appropriate to provide an equivalent for PythonOption directive settings. Specifically req.server.get_options(). This would return a table object giving all PythonOption value settings performed at global scope. This would be useful where a value needs to be set globally in one place and not be overridable in more constrained configuration containers. This might for example be used as a way or allowing the mutex directory to be specified in the Apache configuration as well as as a configure command line option. See MODPYTHON-131. See commentary along with some patches in: http://www.mail-archive.com/python-dev@httpd.apache.org/msg01295.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-139) Running make clean/distclean doesn't clean up test directory.
[ https://issues.apache.org/jira/browse/MODPYTHON-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-139. -- Running make clean/distclean doesn't clean up test directory. - Key: MODPYTHON-139 URL: https://issues.apache.org/jira/browse/MODPYTHON-139 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.3 Reporter: Graham Dumpleton Assigned To: Jim Gallacher Fix For: 3.3 Even after running a distclean, the following files are left in test directory. ? test/testconf.pyc ? test/httpdconf.pyc ? test/Makefile ? test/htdocs/dummymodule.pyc ? test/htdocs/cgitest.pyc ? test/htdocs/tests.pyc Should be addressed as part of test suite rewrite. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-140) util.redirect() returns wrong SERVER_RETURN status value
[ https://issues.apache.org/jira/browse/MODPYTHON-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-140. -- util.redirect() returns wrong SERVER_RETURN status value Key: MODPYTHON-140 URL: https://issues.apache.org/jira/browse/MODPYTHON-140 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.2.8 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Attachments: grahamd_20060302_MP140_1.diff The util.redirect() function ends with: raise apache.SERVER_RETURN, apache.OK Although this will work when used in a handler run in the response/content handler phase, it will not always provide the desired result in a phase such as authenhandler where returning apache.OK actually means that the handler sucessfully authenticated the user. One particular scenario that can result in undesirable behaviour is where a URL matches to a directory and Apache decides to iterate over files listed in DirectoryIndex trying to find an actual file. As it checks for each file, it will trigger any authenhandler. If the authenhandler decides it wants to redirect using util.redirect(), a status of apache.OK is being returned. All this does is make Apache think that authentication was successful and it ignores the fact that a redirection was being requested. The redirection only occurs when it gets to the last file listed in DirectoryIndex and it gives up, or it found one of the files. The desired result should be that it should stop looking through files immediately the redirection occurs. To solve this problem and because util.redirect() is generating a complete response anyway, it should be returning apache.DONE and not apache.OK. Thus it should be using: raise apache.SERVER_RETURN, apache.DONE By making this change, it will be safe to use util.redirect() in phases earlier than the response/content handler phase. This is not just because of the redirection issue described above, but is also because returning apache.OK as it does now doesn't actually stop any later phase from running, so a response/content handler would still run if one exists, with the content being appended to the content already generated by the util.redirect() function. Even if the util.redirect() was used in a response/content handler, without this change any stacked handlers not yet executed for the phase may still be run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-144) Make apache._server/apace._interpreter part of public API.
[ https://issues.apache.org/jira/browse/MODPYTHON-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-144. -- Make apache._server/apace._interpreter part of public API. -- Key: MODPYTHON-144 URL: https://issues.apache.org/jira/browse/MODPYTHON-144 Project: mod_python Issue Type: Improvement Components: core Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 Within the mod_python.apache module there exists two private variables called _server and _interpreter. These are initialised when an interpreter is first created. The variables are set to be an instance of the mod_python serverobject and the name of the interpreter. In effect, these would be the same as are available to a request handler as req.server and req.interpreter. The problem with those in the req object is that they are only available to the request handler. If these variables in the mod_python.apache module are made part of the public API, they would then be accessible by any code. Since server.get_options() now exists and server.get_config() works properly, making these public would allow code running at global scope when a module is being imported to consult the server level config and/or options to customise their runtime behavour. Thus, proposed that these variables be renamed to apache.server and apache.interpreter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-147) PythonImport directives causing duplicate entries in sys.path.
[ https://issues.apache.org/jira/browse/MODPYTHON-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-147. -- PythonImport directives causing duplicate entries in sys.path. -- Key: MODPYTHON-147 URL: https://issues.apache.org/jira/browse/MODPYTHON-147 Project: mod_python Issue Type: Bug Affects Versions: 3.1.4, 3.2.8 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 When PythonPath is used at global scope within the Apache configuration and more than one PythonImport directive is used against the same interpreter, duplicated entries can be added to sys.path. This is because src/mod_python.c is evaluating PythonPath every time that a PythonImport directive is acted upon even if a PythonImport directive for the same interpreter has already been processed. In other words, if you have: PythonPath ['/some/path']+sys.path PythonImport module1 testing PythonImport module2 testing PythonImport module3 testing then '/some/path' will be added to sys.path within context of interpreter called 'testing' a total of three times. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-148) Additional constants for mod_python.apache module.
[
https://issues.apache.org/jira/browse/MODPYTHON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Graham Dumpleton closed MODPYTHON-148.
--
Additional constants for mod_python.apache module.
--
Key: MODPYTHON-148
URL: https://issues.apache.org/jira/browse/MODPYTHON-148
Project: mod_python
Issue Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Priority: Minor
Fix For: 3.3
Apache defines the following:
/** Magic for mod_cgi[d] */
#define CGI_MAGIC_TYPE application/x-httpd-cgi
/** Magic for mod_include */
#define INCLUDES_MAGIC_TYPE text/x-server-parsed-html
/** Magic for mod_include */
#define INCLUDES_MAGIC_TYPE3 text/x-server-parsed-html3
/** Magic for mod_dir */
#define DIR_MAGIC_TYPE httpd/unix-directory
There should be equivalents available as constants in mod_python.apache
module.
Apache defines the following:
#define PROXYREQ_NONE 0 /** No proxy */
#define PROXYREQ_PROXY 1/** Standard proxy */
#define PROXYREQ_REVERSE 2 /** Reverse proxy */
#define PROXYREQ_RESPONSE 3 /** Origin response */
The PROXYREQ_RESPONSE value is missing from mod_python.apache.
Apache defines the following:
#define HTTP_UPGRADE_REQUIRED 426
This isn't present in mod_python.apache.
Apache defines the following:
/** Send 413 error if message has any body */
#define REQUEST_NO_BODY 0
/** Send 411 error if body without Content-Length */
#define REQUEST_CHUNKED_ERROR1
/** If chunked, remove the chunks for me. */
#define REQUEST_CHUNKED_DECHUNK 2
/** @} // values_request_rec_body */
These are necessary to understand what req.read_body means. In practice,
don't think they are relevant to mod_python handlers, but for completeness
should be added.
Apache defines the following:
/**
* @brief Enumeration of connection keepalive options
*/
typedef enum {
AP_CONN_UNKNOWN,
AP_CONN_CLOSE,
AP_CONN_KEEPALIVE
} ap_conn_keepalive_e;
These are needed to understand req.connection.keepalive. Because they a enum
values, need to be populated in mod_python._apache module when module is
initialised and reference made in mod_python.apache module.
The only other thing from httpd.h which seems of interest is the DOCTYPE
macro strings. Don't do anything about them for the time being.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-149) Allow cross subdomain sessions.
[ https://issues.apache.org/jira/browse/MODPYTHON-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-149. -- Allow cross subdomain sessions. --- Key: MODPYTHON-149 URL: https://issues.apache.org/jira/browse/MODPYTHON-149 Project: mod_python Issue Type: Improvement Components: session Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 When session class creates cookie, it does not explicitly set the domain attribute. This means that the session will only apply to the specific site the request was targeted at. This precludes a single server hosting multiple virtual host subdomains under a parent domain and a session being shared across these sites. The code could perhaps be enhanced to allow an option to be set to force the inclusion of a domain attribute in the cookie for the session much like it currently allows with the path attribute. The option for the latter is ApplicationPath. As noted in MODPYTHON-127 there is an intent to properly namespace these mod_python options so maybe there should be an option: mod_python.Session.application_domain with Session code implementing following in make_cookie() method: if config.has_key(mod_python.Session.application_domain): c.domain = config[mod_python.Session.application_domain] Setting the domain though would only be required if you want cross site session cookies within an enclosing domain, it would not be required for a single site. Depending on whether multiple applications are being hosted on sites under the same domain, an application may also want to override the session cookie name and session cookie path to avoid conflicts between multiple applications when doing this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-151) PythonDebug exception error page doesn't escape special HTML characters.
[ https://issues.apache.org/jira/browse/MODPYTHON-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-151. -- PythonDebug exception error page doesn't escape special HTML characters. Key: MODPYTHON-151 URL: https://issues.apache.org/jira/browse/MODPYTHON-151 Project: mod_python Issue Type: Bug Components: core Affects Versions: 2.7.10, 3.1.4, 3.2.8 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 When an exception occurs in a handler and PythonDebug is On, an error page is generated and returned to the client. The traceback and details of the exception will be output within a pre/pre section, however the content put in the section is included as is and no escaping is performed on special HTML characters. This means that if the details of the exception include any special HTML characters, it can stuff up the formatting of the page and/or information could on face value be lost. For example the new importer will generate a specific exception where the response from a handler is not of the correct type. AssertionError: Handler has returned result or raised SERVER_RETURN exception with argument having non integer type. Type of value returned was type 'module', whereas expected type 'int'. Because this includes characters, it actuall displays in the resultant HTML page as: AssertionError: Handler has returned result or raised SERVER_RETURN exception with argument having non integer type. Type of value returned was , whereas expected . The error reporter therefore should pass content through cgi.escape(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (MODPYTHON-150) make_obcallback not thread protected
[ https://issues.apache.org/jira/browse/MODPYTHON-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Graham Dumpleton closed MODPYTHON-150. -- make_obcallback not thread protected Key: MODPYTHON-150 URL: https://issues.apache.org/jira/browse/MODPYTHON-150 Project: mod_python Issue Type: Bug Components: core Affects Versions: 3.1.4, 3.2.8 Reporter: Graham Dumpleton Assigned To: Graham Dumpleton Fix For: 3.3 In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback(). In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise. To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MODPYTHON-169) Add feature to allow mod_python to be an auth provider.
[
https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Guthrie updated MODPYTHON-169:
---
Attachment: add-authenticator.patch
This patch is intended to address the bulk of this enhancement request. It
adds mod_python as both an AuthBasicProvider and a AuthDigestProvider and the
PythonAuthBasicProvider and PythonAuthDigestProvider configuration items. I
think that the return values and apache.SERVER_RETURN values are handled as
described in the initial task description.
What is not included is what is describe in the July 26, 2006 comment. There
is no provision for allowing mod_python to use an Apache authentication
provider. I didn't implement this because I don't think I understand what that
feature does and I didn't need it for what I'm trying to accomplish now.
Add feature to allow mod_python to be an auth provider.
---
Key: MODPYTHON-169
URL: https://issues.apache.org/jira/browse/MODPYTHON-169
Project: mod_python
Issue Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assigned To: Graham Dumpleton
Attachments: add-authenticator.patch
In Apache 2.2, the implementation of authentication has been split into two
parts. The first is that which handles the specifics of negotiating with a
client for a specific authentication mechanism type, for example, Basic or
Digest authentication. The second part is that which handles the specifics of
verifying the actual users credentials, for example, by looking the user up
in a dbm database, ldap or some other type of user database.
The second part of this is referred to as the auth provider and in Apache 2.2
it is possible to hook in additional providers. This means that the any
builtin support in Apache for Basic and Digest authentication mechanism can
be used, but the verification could be done by some arbitrary user code. Such
verification could be done in Python, if mod_python allowed one to define the
necessary auth provider hooks.
To this end, proposed that mod_python be extended such that when using Apache
2.2, that it is possible to say:
AuthType Basic
AuthName Restricted Files
AuthBasicProvider mod_python
PythonAuthBasicProvider somemodule
or:
AuthType Digest
AuthName Restricted Files
AuthDigestProvider mod_python
PythonAuthDigestProvider somemodule
That is, by specifying mod_python in conjunction with AuthBasicProvider or
AuthDigestProvider directives, it triggers mod_python to be given option of
satisfying need to perform verification of user credentials. The function to
be called for each being given by the PythonAuthBasicProvider and
PythonAuthDigestProvider respectively.
The argument to these directives would be a module name, in which case a
function of the name authbasicprovider or authdigestprovider will be
expected to exist. If wanting to specify a particular module, like in handler
directives, would also be possible to say:
PythonAuthBasicProvider somemodule::check_password
PythonAuthDigestProvider somemodule::get_realm_hash
Note that the prototype of the function for each would not be like existing
handlers and is different in each case. For the Basic auth mechanism, an
example function would be:
users = { ... }
def authbasicprovider(req, user, password):
# could consult req.auth_name() to get realm
if user not in users:
return apache.AUTH_USER_NOT_FOUND
# assuming passwords are stored in clear text
if users[user] != password:
return apache.AUTH_DENIED
return apache.AUTH_GRANTED
Exceptions would be translated into apache.AUTH_GENERAL_ERROR, or function
could explicitly return it. Could also allow explicit exception of type
apache.SERVER_RETURN like in handlers but where argument is auth values.
For Digest authentication, function would be:
def authdigestprovider(req, user, realm):
# could select database based on 'realm'
if user not in users:
return None
# assuming passwords are stored in clear text
return md5.new(%s:%s:%s % (user, realm, users[user])).hexdigest()
In this later function, return None indicates apache.AUTH_USER_NOT_FOUND. An
apache.SERVER_RETURN exception could also be used with that value as
argument. Returning of an actual string would imply apache.AUTH_USER_FOUND.
Unexpected exceptions taken as apache.AUTH_GENERAL_ERROR, or could be raised
explicitly using apache.SERVER_RETURN exception.
What all this would mean is that you would never need to write an
authenhandler again using mod_python, as you could rely on any type of
authenhandler builtin to Apache or as as supported by some third party Apache
module. All you would need to do is supply the auth provider
