You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Graham Dumpleton (JIRA)" <ji...@apache.org> on 2006/05/05 12:13:27 UTC
[jira] Created: (MODPYTHON-169) Add feature to allow mod_python to
be an auth provider.
Add feature to allow mod_python to be an auth provider.
-------------------------------------------------------
Key: MODPYTHON-169
URL: http://issues.apache.org/jira/browse/MODPYTHON-169
Project: mod_python
Type: New Feature
Components: core
Reporter: Graham Dumpleton
Assigned to: Graham Dumpleton
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 or Basic or Digest authentication as necessary to support verification of the user.
--
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: [jira] Created: (MODPYTHON-169) Add feature to allow mod_python
to be an auth provider.
Posted by Jorey bump <li...@joreybump.com>.
+1
But I think any example functions in the documentation should return
apache.AUTH_DENIED by default, with the conditionals checking for
success, not failure:
def authbasicprovider(req, user, password):
if user in users:
if users[user] == password:
return apache.AUTH_GRANTED
else:
return apache.AUTH_USER_NOT_FOUND
return apache.AUTH_DENIED
Graham Dumpleton (JIRA) wrote:
> Add feature to allow mod_python to be an auth provider.
> -------------------------------------------------------
>
> Key: MODPYTHON-169
> URL: http://issues.apache.org/jira/browse/MODPYTHON-169
> Project: mod_python
> Type: New Feature
>
> Components: core
> Reporter: Graham Dumpleton
> Assigned to: Graham Dumpleton
>
>
> 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 or Basic or Digest authentication as necessary to support verification of the user.
>
>
>
>
>
>
>
[jira] Commented: (MODPYTHON-169) Add feature to allow mod_python
to be an auth provider.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MODPYTHON-169?page=comments#action_12423609 ]
Graham Dumpleton commented on MODPYTHON-169:
--------------------------------------------
At the same time as looking into how to allow mod_python to act as an auth provider, should also look into how mod_python can be allowed to use an auth provider. For example req.check_password() and req.get_realm_hash() methods which call through to whatever the auth provider is defined as for mod_python's use. This would probably need a new directive called AuthPythonProvider which would be used as:
AuthPythonProvider dbm
AuthDBMType SDBM
AuthDBMUserFile /www/etc/dbmpasswd
In other words, the Apache directive external to Python code specifies to what auth provider the request methods get redirected.
> Add feature to allow mod_python to be an auth provider.
> -------------------------------------------------------
>
> Key: MODPYTHON-169
> URL: http://issues.apache.org/jira/browse/MODPYTHON-169
> Project: mod_python
> Issue Type: New Feature
> Components: core
> Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
>
> 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
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-169) Add feature to allow mod_python
to be an auth provider.
Posted by "Paul Jongsma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504708 ]
Paul Jongsma commented on MODPYTHON-169:
----------------------------------------
Graham, thank you for the insight.
It would be great if mod_python could be used as an AuthProvider as currently I have some websites which use modauthmysql and this module is not available for Apache 2.2
mod_python can easily replace the modauthmysql with only a couple of lines and it would save me from maintaining an old apache 2.0 installation.
Thanks
Paul
> 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
> Assignee: 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
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.
Posted by "Jonathan Guthrie (JIRA)" <ji...@apache.org>.
[ 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-169) Add feature to allow mod_python
to be an auth provider.
Posted by "M Willson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499599 ]
M Willson commented on MODPYTHON-169:
-------------------------------------
This would indeed be very helpful - I'd like to take advantage of apache's digest auth code without having to re-implement it in Python.
Have tried the patch and seems to be working smoothly, will let you know if I have any problems. Cheers!
> 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
> Assignee: 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-169) Add feature to allow mod_python
to be an auth provider.
Posted by "Graham Dumpleton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503347 ]
Graham Dumpleton commented on MODPYTHON-169:
--------------------------------------------
The _path change is not valid.
The real problem is that the proposed patches to the Python code parts of mod_python don't appear to have been originally written for mod_python 3.3 and therefore don't take into consideration all the changes made to the module importer in mod_python 3.3. Some of the other code in there is also not up to date with how things are done in mod_python 3.3.
I haven't really looked at the code in detail, but the presence of a few things in there makes me want to question whether the way it is hooked into mod_python is necessarily the best way of doing all this. So, by all means experiment with this, but don't necessarily expect it to end up being implemented like this if ever added in.
> 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
> Assignee: 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MODPYTHON-169) Add feature to allow mod_python
to be an auth provider.
Posted by "Paul Jongsma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MODPYTHON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503329 ]
Paul Jongsma commented on MODPYTHON-169:
----------------------------------------
Using this patch with the PythonPath option in the Apache configuration seems to give a problem.
As soon as you add a PythonPath setting to the server config any request fails with:
File "/usr/local/lib/python2.4/site-packages/mod_python/apache.py", line 331, in AuthBasicDispatch\n if pathstring != _path:
NameError: global name '_path' is not defined
Adding a global _path to apache.py resolves this issue;
# Cache for values of PythonPath that have been seen already.
_path = {}
_path_cache = {}
_path_cache_lock = threading.Lock()
However I have not enough knowledge on mod_python to know if this is the correct way to resolve this issue.
Platform info: Python 2.4.4 (#2, Mar 28 2007, 20:09:38) on FreeBSD 6.2-STABLE FreeBSD 6.2-STABLE #5
Server version: Apache/2.2.4 (Unix)
> 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
> Assignee: 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 or Basic or Digest authentication as necessary to support verification of the user.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.