.. _about_plugins: About :mod:`repoze.who` Plugins =============================== Plugin Types ------------ Identifier Plugins ++++++++++++++++++ You can register a plugin as willing to act as an "identifier". An identifier examines the WSGI environment and attempts to extract credentials from the environment. These credentials are used by authenticator plugins to perform authentication. Authenticator Plugins +++++++++++++++++++++ You may register a plugin as willing to act as an "authenticator". Authenticator plugins are responsible for resolving a set of credentials provided by an identifier plugin into a user id. Typically, authenticator plugins will perform a lookup into a database or some other persistent store, check the provided credentials against the stored data, and return a user id if the credentials can be validated. The user id provided by an authenticator is eventually passed to downstream WSGI applications in the "REMOTE_USER' environment variable. Additionally, the "identity" of the user (as provided by the identifier from whence the identity came) is passed along to downstream application in the ``repoze.who.identity`` environment variable. Metadata Provider Plugins +++++++++++++++++++++++++ You may register a plugin as willing to act as a "metadata provider" (aka mdprovider). Metadata provider plugins are responsible for adding arbitrary information to the identity dictionary for consumption by downstream applications. For instance, a metadata provider plugin may add "group" information to the the identity. Challenger Plugins ++++++++++++++++++ You may register a plugin as willing to act as a "challenger". Challenger plugins are responsible for initiating a challenge to the requesting user. Challenger plugins are invoked by :mod:`repoze.who` when it decides a challenge is necessary. A challenge might consist of displaying a form or presenting the user with a basic or digest authentication dialog. .. _default_plugins: Default Plugin Implementations ------------------------------ :mod:`repoze.who` ships with a variety of default plugins that do authentication, identification, challenge and metadata provision. .. module:: repoze.who.plugins.auth_tkt .. class:: AuthTktCookiePlugin(secret [, cookie_name='auth_tkt' [, secure=False [, include_ip=False]]]) An :class:`AuthTktCookiePlugin` is an ``IIdentifier`` and ``IAuthenticator`` plugin which remembers its identity state in a client-side cookie. This plugin uses the ``paste.auth.auth_tkt``"auth ticket" protocol and is compatible with Apache's mod_auth_tkt. It should be instantiated passing a *secret*, which is used to encrypt the cookie on the client side and decrypt the cookie on the server side. The cookie name used to store the cookie value can be specified using the *cookie_name* parameter. If *secure* is False, the cookie will be sent across any HTTP or HTTPS connection; if it is True, the cookie will be sent only across an HTTPS connection. If *include_ip* is True, the ``REMOTE_ADDR`` of the WSGI environment will be placed in the cookie. Normally, using the plugin as an identifier requires also using it as an authenticator. .. note:: Using the *include_ip* setting for public-facing applications may cause problems for some users. `One study `_ reports that as many as 3% of users change their IP addresses legitimately during a session. .. note:: Plugin supports remembering user data in the cookie by saving user dict into ``identity['userdata']`` parameter of ``remember`` method. They are sent unencrypted and protected by checksum. Data will then be returned every time by ``identify``. This dict must be compatible with ``urllib.urlencode`` function (``urllib.urlparse.urlencode`` in python 3). Saving keys/values with unicode characters is supported only under python 3. .. note:: Plugin supports multiple digest algorithms. It defaults to md5 to match the default for mod_auth_tkt and paste.auth.auth_tkt. However md5 is not recommended as there are viable attacks against the hash. Any algorithm from the hashlib library can be specified, currently only sha256 and sha512 are supported by mod_auth_tkt. .. module:: repoze.who.plugins.basicauth .. class:: BasicAuthPlugin(realm) A :class:`BasicAuthPlugin` plugin is both an ``IIdentifier`` and ``IChallenger`` plugin that implements the Basic Access Authentication scheme described in :rfc:`2617`. It looks for credentials within the ``HTTP-Authorization`` header sent by browsers. It challenges by sending an ``WWW-Authenticate`` header to the browser. The single argument *realm* indicates the basic auth realm that should be sent in the ``WWW-Authenticate`` header. .. module:: repoze.who.plugins.htpasswd .. class:: HTPasswdPlugin(filename, check) A :class:`HTPasswdPlugin` is an ``IAuthenticator`` implementation which compares identity information against an Apache-style htpasswd file. The *filename* argument should be an absolute path to the htpasswd file' the *check* argument is a callable which takes two arguments: "password" and "hashed", where the "password" argument is the unencrypted password provided by the identifier plugin, and the hashed value is the value stored in the htpasswd file. If the hashed value of the password matches the hash, this callable should return True. A default implementation named ``crypt_check`` is available for use as a check function (on UNIX) as ``repoze.who.plugins.htpasswd:crypt_check``; it assumes the values in the htpasswd file are encrypted with the UNIX ``crypt`` function. .. module:: repoze.who.plugins.redirector .. class:: RedirectorPlugin(login_url, came_from_param, reason_param, reason_header) A :class:`RedirectorPlugin` is an ``IChallenger`` plugin. It redirects to a configured login URL at egress if a challenge is required . *login_url* is the URL that should be redirected to when a challenge is required. *came_from_param* is the name of an optional query string parameter: if configured, the plugin provides the current request URL in the redirected URL's query string, using the supplied parameter name. *reason_param* is the name of an optional query string parameter: if configured, and the application supplies a header matching *reason_header* (defaulting to ``X-Authorization-Failure-Reason``), the plugin includes that reason in the query string of the redirected URL, using the supplied parameter name. *reason_header* is an optional parameter overriding the default response header name (``X-Authorization-Failure-Reason``) which the plugin checks to find the application-supplied reason for the challenge. *reason_header* cannot be set unless *reason_param* is also set. .. module:: repoze.who.plugins.sql .. class:: SQLAuthenticatorPlugin(query, conn_factory, compare_fn) A :class:`SQLAuthenticatorPlugin` is an ``IAuthenticator`` implementation which compares login-password identity information against data in an arbitrary SQL database. The *query* argument should be a SQL query that returns two columns in a single row considered to be the user id and the password respectively. The SQL query should contain Python-DBAPI style substitution values for ``%(login)``, e.g. ``SELECT user_id, password FROM users WHERE login = %(login)``. The *conn_factory* argument should be a callable that returns a DBAPI database connection. The *compare_fn* argument should be a callable that accepts two arguments: ``cleartext`` and ``stored_password_hash``. It should compare the hashed version of cleartext and return True if it matches the stored password hash, otherwise it should return False. A comparison function named ``default_password_compare`` exists in the ``repoze.who.plugins.sql`` module demonstrating this. The :class:`SQLAuthenticatorPlugin`\'s ``authenticate`` method will return the user id of the user unchanged to :mod:`repoze.who`. .. class:: SQLMetadataProviderPlugin(name, query, conn_factory, filter) A :class:`SQLMetatadaProviderPlugin` is an ``IMetadataProvider`` implementation which adds arbitrary metadata to the identity on ingress using data from an arbitrary SQL database. The *name* argument should be a string. It will be used as a key in the identity dictionary. The *query* argument should be a SQL query that returns arbitrary data from the database in a form that accepts Python-binding style DBAPI arguments. It should expect that a ``__userid`` value will exist in the dictionary that is bound. The SQL query should contain Python-DBAPI style substitution values for (at least) ``%(__userid)``, e.g. ``SELECT group FROM groups WHERE user_id = %(__userid)``. The *conn_factory* argument should be a callable that returns a DBAPI database connection. The *filter* argument should be a callable that accepts the result of the DBAPI ``fetchall`` based on the SQL query. It should massage the data into something that will be set in the environment under the *name* key. Writing :mod:`repoze.who` Plugins --------------------------------- :mod:`repoze.who` can be extended arbitrarily through the creation of plugins. Plugins are of one of four types: identifier plugins, authenticator plugins, metadata provider plugins, and challenge plugins. Writing An Identifier Plugin ++++++++++++++++++++++++++++ An identifier plugin (aka an ``IIdentifier`` plugin) must do three things: extract credentials from the request and turn them into an "identity", "remember" credentials, and "forget" credentials. Here's a simple cookie identification plugin that does these three things :: class InsecureCookiePlugin(object): def __init__(self, cookie_name): self.cookie_name = cookie_name def identify(self, environ): from paste.request import get_cookies cookies = get_cookies(environ) cookie = cookies.get(self.cookie_name) if cookie is None: return None import binascii try: auth = cookie.value.decode('base64') except binascii.Error: # can't decode return None try: login, password = auth.split(':', 1) return {'login':login, 'password':password} except ValueError: # not enough values to unpack return None def remember(self, environ, identity): cookie_value = '%(login)s:%(password)s' % identity cookie_value = cookie_value.encode('base64').rstrip() from paste.request import get_cookies cookies = get_cookies(environ) existing = cookies.get(self.cookie_name) value = getattr(existing, 'value', None) if value != cookie_value: # return a Set-Cookie header set_cookie = '%s=%s; Path=/;' % (self.cookie_name, cookie_value) return [('Set-Cookie', set_cookie)] def forget(self, environ, identity): # return a expires Set-Cookie header expired = ('%s=""; Path=/; Expires=Sun, 10-May-1971 11:59:00 GMT' % self.cookie_name) return [('Set-Cookie', expired)] def __repr__(self): return '<%s %s>' % (self.__class__.__name__, id(self)) .identify ~~~~~~~~~ The ``identify`` method of our InsecureCookiePlugin accepts a single argument "environ". This will be the WSGI environment dictionary. Our plugin attempts to grub through the cookies sent by the client, trying to find one that matches our cookie name. If it finds one that matches, it attempts to decode it and turn it into a login and a password, which it returns as values in a dictionary. This dictionary is thereafter known as an "identity". If it finds no credentials in cookies, it returns None (which is not considered an identity). More generally, the ``identify`` method of an ``IIdentifier`` plugin is called once on WSGI request "ingress", and it is expected to grub arbitrarily through the WSGI environment looking for credential information. In our above plugin, the credential information is expected to be in a cookie but credential information could be in a cookie, a form field, basic/digest auth information, a header, a WSGI environment variable set by some upstream middleware or whatever else someone might use to stash authentication information. If the plugin finds credentials in the request, it's expected to return an "identity": this must be a dictionary. The dictionary is not required to have any particular keys or value composition, although it's wise if the identification plugin looks for both a login name and a password information to return at least {'login':login_name, 'password':password}, as some authenticator plugins may depend on presence of the names "login" and "password" (e.g. the htpasswd and sql ``IAuthenticator`` plugins). If an ``IIdentifier`` plugin finds no credentials, it is expected to return None. .remember ~~~~~~~~~ If we've passed a REMOTE_USER to the WSGI application during ingress (as a result of providing an identity that could be authenticated), and the downstream application doesn't kick back with an unauthorized response, on egress we want the requesting client to "remember" the identity we provided if there's some way to do that and if he hasn't already, in order to ensure he will pass it back to us on subsequent requests without requiring another login. The remember method of an ``IIdentifier`` plugin is called for each non-unauthenticated response. It is the responsibility of the ``IIdentifier`` plugin to conditionally return HTTP headers that will cause the client to remember the credentials implied by "identity". Our InsecureCookiePlugin implements the "remember" method by returning headers which set a cookie if and only if one is not already set with the same name and value in the WSGI environment. These headers will be tacked on to the response headers provided by the downstream application during the response. When you write a remember method, most of the work involved is determining *whether or not* you need to return headers. It's typical to see remember methods that compute an "old state" and a "new state" and compare the two against each other in order to determine if headers need to be returned. In our example InsecureCookiePlugin, the "old state" is ``cookie_value`` and the "new state" is ``value``. .forget ~~~~~~~ Eventually the WSGI application we're serving will issue a "401 Unauthorized" or another status signifying that the request could not be authorized. :mod:`repoze.who` intercepts this status and calls ``IIdentifier`` plugins asking them to "forget" the credentials implied by the identity. It is the "forget" method's job at this point to return HTTP headers that will effectively clear any credentials on the requesting client implied by the "identity" argument. Our InsecureCookiePlugin implements the "forget" method by returning a header which resets the cookie that was set earlier by the remember method to one that expires in the past (on my birthday, in fact). This header will be tacked onto the response headers provided by the downstream application. Writing an Authenticator Plugin +++++++++++++++++++++++++++++++ An authenticator plugin (aka an ``IAuthenticator`` plugin) must do only one thing (on "ingress"): accept an identity and check if the identity is "good". If the identity is good, it should return a "user id". This user id may or may not be the same as the "login" provided by the user. An ``IAuthenticator`` plugin will be called for each identity found during the identification phase (there may be multiple identities for a single request, as there may be multiple ``IIdentifier`` plugins active at any given time), so it may be called multiple times in the same request. Here's a simple authenticator plugin that attempts to match an identity against ones defined in an "htpasswd" file that does just that:: class SimpleHTPasswdPlugin(object): def __init__(self, filename): self.filename = filename # IAuthenticatorPlugin def authenticate(self, environ, identity): try: login = identity['login'] password = identity['password'] except KeyError: return None f = open(self.filename, 'r') for line in f: try: username, hashed = line.rstrip().split(':', 1) except ValueError: continue if username == login: if crypt_check(password, hashed): return username return None def crypt_check(password, hashed): from crypt import crypt salt = hashed[:2] return hashed == crypt(password, salt) An ``IAuthenticator`` plugin implements one "interface" method: "authentictate". The formal specification for the arguments and return values expected from these methods are available in the ``interfaces.py`` file in :mod:`repoze.who` as the ``IAuthenticator`` interface, but let's examine this method here less formally. .authenticate ~~~~~~~~~~~~~ The ``authenticate`` method accepts two arguments: the WSGI environment and an identity. Our SimpleHTPasswdPlugin ``authenticate`` implementation grabs the login and password out of the identity and attempts to find the login in the htpasswd file. If it finds it, it compares the crypted version of the password provided by the user to the crypted version stored in the htpasswd file, and finally, if they match, it returns the login. If they do not match, it returns None. .. note:: Our plugin's ``authenticate`` method does not assume that the keys ``login`` or ``password`` exist in the identity; although it requires them to do "real work" it returns None if they are not present instead of raising an exception. This is required by the ``IAuthenticator`` interface specification. Writing a Challenger Plugin +++++++++++++++++++++++++++ A challenger plugin (aka an ``IChallenger`` plugin) must do only one thing on "egress": return a WSGI application which performs a "challenge". A WSGI application is a callable that accepts an "environ" and a "start_response" as its parameters; see "PEP 333" for further definition of what a WSGI application is. A challenge asks the user for credentials. Here's an example of a simple challenger plugin:: from paste.httpheaders import WWW_AUTHENTICATE from paste.httpexceptions import HTTPUnauthorized class BasicAuthChallengerPlugin(object): def __init__(self, realm): self.realm = realm # IChallenger def challenge(self, environ, status, app_headers, forget_headers): head = WWW_AUTHENTICATE.tuples('Basic realm="%s"' % self.realm) if head[0] not in forget_headers: head = head + forget_headers return HTTPUnauthorized(headers=head) Note that the plugin implements a single "interface" method: "challenge". The formal specification for the arguments and return values expected from this method is available in the "interfaces.py" file in :mod:`repoze.who` as the ``IChallenger`` interface. This method is called when :mod:`repoze.who` determines that the application has returned an "unauthorized" response (e.g. a 401). Only one challenger will be consulted during "egress" as necessary (the first one to return a non-None response). .challenge ~~~~~~~~~~ The challenge method takes environ (the WSGI environment), 'status' (the status as set by the downstream application), the "app_headers" (headers returned by the application), and the "forget_headers" (headers returned by all participating ``IIdentifier`` plugins whom were asked to "forget" this user). Our BasicAuthChallengerPlugin takes advantage of the fact that the HTTPUnauthorized exception imported from paste.httpexceptions can be used as a WSGI application. It first makes sure that we don't repeat headers if an identification plugin has already set a "WWW-Authenticate" header like ours, then it returns an instance of HTTPUnauthorized, passing in merged headers. This will cause a basic authentication dialog to be presented to the user. Writing a Metadata Provider Plugin ++++++++++++++++++++++++++++++++++ A metadata provider plugin (aka an ``IMetadataProvider`` plugin) must do only one thing (on "ingress"): "scribble" on the identity dictionary provided to it when it is called. An ``IMetadataProvider`` plugin will be called with the final "best" identity found during the authentication phase, or not at all if no "best" identity could be authenticated. Thus, each ``IMetadataProvider`` plugin will be called exactly zero or one times during a request. Here's a simple metadata provider plugin that provides "property" information from a dictionary:: _DATA = { 'chris': {'first_name':'Chris', 'last_name':'McDonough'} , 'whit': {'first_name':'Whit', 'last_name':'Morriss'} } class SimpleMetadataProvider(object): def add_metadata(self, environ, identity): userid = identity.get('repoze.who.userid') info = _DATA.get(userid) if info is not None: identity.update(info) .add_metadata ~~~~~~~~~~~~~ Arbitrarily add information to the identity dict based in other data in the environment or identity. Our plugin adds ``first_name`` and ``last_name`` values to the identity if the userid matches ``chris`` or ``whit``. Known Plugins for :mod:`repoze.who` =================================== Plugins shipped with :mod:`repoze.who` -------------------------------------- See :ref:`default_plugins`. Deprecated plugins ------------------ The :mod:`repoze.who.deprecatedplugins` distribution bundles the following plugin implementations which were shipped with :mod:`repoze.who` prior to version 2.0a3. These plugins are deprecated, and should only be used while migrating an existing deployment to replacement versions. :class:`repoze.who.plugins.cookie.InsecureCookiePlugin` An ``IIdentifier`` plugin which stores identification information in an insecure form (the base64 value of the username and password separated by a colon) in a client-side cookie. Please use the :class:`AuthTktCookiePlugin` instead. :class:`repoze.who.plugins.form.FormPlugin` An ``IIdentifier`` and ``IChallenger`` plugin, which intercepts form POSTs to gather identification at ingress and conditionally displays a login form at egress if challenge is required. Applications should supply their own login form, and use :class:`repoze.who.api.API` to authenticate and remember users. To replace the challenger role, please use :class:`repoze.who.plugins.redirector.RedirectorPlugin`, configured with the URL of your application's login form. :class:`repoze.who.plugins.form.RedirectingFormPlugin` An ``IIdentifier`` and ``IChallenger`` plugin, which intercepts form POSTs to gather identification at ingress and conditionally redirects a login form at egress if challenge is required. Applications should supply their own login form, and use :class:`repoze.who.api.API` to authenticate and remember users. To replace the challenger role, please use :class:`repoze.who.plugins.redirector.RedirectorPlugin`, configured with the URL of your application's login form. Third-party Plugins ------------------- :class:`repoze.who.plugins.zodb.ZODBPlugin` This class implements the :class:`repoze.who.interfaces.IAuthenticator` and :class:`repoze.who.interfaces.IMetadataProvider` plugin interfaces using ZODB database lookups. See http://pypi.python.org/pypi/repoze.whoplugins.zodb/ :class:`repoze.who.plugins.ldap.LDAPAuthenticatorPlugin` This class implements the :class:`repoze.who.interfaces.IAuthenticator` plugin interface using the :mod:`python-ldap` library to query an LDAP database. See http://code.gustavonarea.net/repoze.who.plugins.ldap/ :class:`repoze.who.plugins.ldap.LDAPAttributesPlugin` This class implements the :class:`repoze.who.interfaces.IMetadataProvider` plugin interface using the :mod:`python-ldap` library to query an LDAP database. See http://code.gustavonarea.net/repoze.who.plugins.ldap/ :class:`repoze.who.plugins.friendlyform.FriendlyFormPlugin` This class implements the :class:`repoze.who.interfaces.IIdentifier` and :class:`repoze.who.interfaces.IChallenger` plugin interfaces. It is similar to :class:`repoze.who.plugins.form.RedirectingFormPlugin`, bt with with additional features: - Users are not challenged on logout, unless the referrer URL is a private one (but that’s up to the application). - Developers may define post-login and/or post-logout pages. - In the login URL, the amount of failed logins is available in the environ. It’s also increased by one on every login try. This counter will allow developers not using a post-login page to handle logins that fail/succeed. See http://code.gustavonarea.net/repoze.who-friendlyform/ :func:`repoze.who.plugins.openid.identifiers.OpenIdIdentificationPlugin` This class implements the :class:`repoze.who.interfaces.IIdentifier`, :class:`repoze.who.interfaces.IAuthenticator`, and :class:`repoze.who.interfaces.IChallenger` plugin interfaces using OpenId. See http://quantumcore.org/docs/repoze.who.plugins.openid/ :func:`repoze.who.plugins.openid.classifiers.openid_challenge_decider` This function provides the :class:`repoze.who.interfaces.IChallengeDecider` interface using OpenId. See http://quantumcore.org/docs/repoze.who.plugins.openid/ :class:`repoze.who.plugins.use_beaker.UseBeakerPlugin` This packkage provids a :class:`repoze.who.interfaces.IIdentifier` plugin using :mod:`beaker.session` cache. See http://pypi.python.org/pypi/repoze.who-use_beaker/ :class:`repoze.who.plugins.cas.main_plugin.CASChallengePlugin` This class implements the :class:`repoze.who.interfaces.IIdentifier` :class:`repoze.who.interfaces.IAuthenticator`, and :class:`repoze.who.interfaces.IChallenger` plugin interfaces using CAS. See http://pypi.python.org/pypi/repoze.who.plugins.cas :class:`repoze.who.plugins.cas.challenge_decider.my_challenge_decider` This function provides the :class:`repoze.who.interfaces.IChallengeDecider` interface using CAS. See http://pypi.python.org/pypi/repoze.who.plugins.cas/ :class:`repoze.who.plugins.recaptcha.captcha.RecaptchaPlugin` This class implements the :class:`repoze.who.interfaces.IAuthenticator` plugin interface, using the recaptch API. See http://pypi.python.org/pypi/repoze.who.plugins.recaptcha/ :class:`repoze.who.plugins.sa.SQLAlchemyUserChecker` User existence checker for :class:`repoze.who.plugins.auth_tkt.AuthTktCookiePlugin`, based on the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/ :class:`repoze.who.plugins.sa.SQLAlchemyAuthenticatorPlugin` This class implements the :class:`repoze.who.interfaces.IAuthenticator` plugin interface, using the the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/ :class:`repoze.who.plugins.sa.SQLAlchemyUserMDPlugin` This class implements the :class:`repoze.who.interfaces.IMetadataProvider` plugin interface, using the the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/ :class:`repoze.who.plugins.formcookie.CookieRedirectingFormPlugin` This class implements the :class:`repoze.who.interfaces.IIdentifier` and :class:`repoze.who.interfaces.IChallenger` plugin interfaces, similar to :class:`repoze.who.plugins.form.RedirectingFormPlugin`. The plugin tracks the ``came_from`` URL via a cookie, rather than the query string. See http://pypi.python.org/pypi/repoze.who.plugins.formcookie/