About `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 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 Plugin Implementations¶

repoze.who ships with a variety of default plugins that do authentication, identification, challenge and metadata provision.

class repoze.who.plugins.auth_tkt.AuthTktCookiePlugin(secret[, cookie_name='auth_tkt'[, secure=False[, include_ip=False]]])¶

An 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.

class repoze.who.plugins.basicauth.BasicAuthPlugin(realm)¶: A 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.

class repoze.who.plugins.htpasswd.HTPasswdPlugin(filename, check)¶: A 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.

class repoze.who.plugins.redirector.RedirectorPlugin(login_url, came_from_param, reason_param, reason_header)¶: A 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.

class repoze.who.plugins.sql.SQLAuthenticatorPlugin(query, conn_factory, compare_fn)¶: A 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 SQLAuthenticatorPlugin’s authenticate method will return the user id of the user unchanged to repoze.who.

class repoze.who.plugins.sql.SQLMetadataProviderPlugin(name, query, conn_factory, filter)¶: A 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 `repoze.who` Plugins¶

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. 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 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 repoze.who as the IChallenger interface. This method is called when 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 `repoze.who`¶

Plugins shipped with `repoze.who`¶

See Default Plugin Implementations.

Deprecated plugins¶

The repoze.who.deprecatedplugins distribution bundles the following plugin implementations which were shipped with repoze.who prior to version 2.0a3. These plugins are deprecated, and should only be used while migrating an existing deployment to replacement versions.

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 AuthTktCookiePlugin instead.

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 repoze.who.api.API to authenticate and remember users. To replace the challenger role, please use repoze.who.plugins.redirector.RedirectorPlugin, configured with the URL of your application’s login form.

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 repoze.who.api.API to authenticate and remember users. To replace the challenger role, please use repoze.who.plugins.redirector.RedirectorPlugin, configured with the URL of your application’s login form.

Third-party Plugins¶

repoze.who.plugins.zodb.ZODBPlugin

This class implements the repoze.who.interfaces.IAuthenticator and repoze.who.interfaces.IMetadataProvider plugin interfaces using ZODB database lookups. See http://pypi.python.org/pypi/repoze.whoplugins.zodb/

repoze.who.plugins.ldap.LDAPAuthenticatorPlugin

This class implements the repoze.who.interfaces.IAuthenticator plugin interface using the python-ldap library to query an LDAP database. See http://code.gustavonarea.net/repoze.who.plugins.ldap/

repoze.who.plugins.ldap.LDAPAttributesPlugin

This class implements the repoze.who.interfaces.IMetadataProvider plugin interface using the python-ldap library to query an LDAP database. See http://code.gustavonarea.net/repoze.who.plugins.ldap/

repoze.who.plugins.friendlyform.FriendlyFormPlugin

This class implements the repoze.who.interfaces.IIdentifier and repoze.who.interfaces.IChallenger plugin interfaces. It is similar to 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/

repoze.who.plugins.openid.identifiers.OpenIdIdentificationPlugin()

This class implements the repoze.who.interfaces.IIdentifier, repoze.who.interfaces.IAuthenticator, and repoze.who.interfaces.IChallenger plugin interfaces using OpenId. See http://quantumcore.org/docs/repoze.who.plugins.openid/

repoze.who.plugins.openid.classifiers.openid_challenge_decider()

This function provides the repoze.who.interfaces.IChallengeDecider interface using OpenId. See http://quantumcore.org/docs/repoze.who.plugins.openid/

repoze.who.plugins.use_beaker.UseBeakerPlugin

This packkage provids a repoze.who.interfaces.IIdentifier plugin using beaker.session cache. See http://pypi.python.org/pypi/repoze.who-use_beaker/

repoze.who.plugins.cas.main_plugin.CASChallengePlugin

This class implements the repoze.who.interfaces.IIdentifier repoze.who.interfaces.IAuthenticator, and repoze.who.interfaces.IChallenger plugin interfaces using CAS. See http://pypi.python.org/pypi/repoze.who.plugins.cas

repoze.who.plugins.cas.challenge_decider.my_challenge_decider

This function provides the repoze.who.interfaces.IChallengeDecider interface using CAS. See http://pypi.python.org/pypi/repoze.who.plugins.cas/

repoze.who.plugins.recaptcha.captcha.RecaptchaPlugin

This class implements the repoze.who.interfaces.IAuthenticator plugin interface, using the recaptch API. See http://pypi.python.org/pypi/repoze.who.plugins.recaptcha/

repoze.who.plugins.sa.SQLAlchemyUserChecker

User existence checker for repoze.who.plugins.auth_tkt.AuthTktCookiePlugin, based on the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/

repoze.who.plugins.sa.SQLAlchemyAuthenticatorPlugin

This class implements the repoze.who.interfaces.IAuthenticator plugin interface, using the the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/

repoze.who.plugins.sa.SQLAlchemyUserMDPlugin

This class implements the repoze.who.interfaces.IMetadataProvider plugin interface, using the the SQLAlchemy ORM. See http://pypi.python.org/pypi/repoze.who.plugins.sa/

repoze.who.plugins.formcookie.CookieRedirectingFormPlugin

This class implements the repoze.who.interfaces.IIdentifier and repoze.who.interfaces.IChallenger plugin interfaces, similar to 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/

About repoze.who Plugins¶

Plugin Types¶

Identifier Plugins¶

Authenticator Plugins¶

Metadata Provider Plugins¶

Challenger Plugins¶

Default Plugin Implementations¶

Writing repoze.who Plugins¶

Writing An Identifier Plugin¶

.identify¶

.remember¶

.forget¶

Writing an Authenticator Plugin¶

.authenticate¶

Writing a Challenger Plugin¶

.challenge¶

Writing a Metadata Provider Plugin¶

.add_metadata¶

Known Plugins for repoze.who¶

Plugins shipped with repoze.who¶

Deprecated plugins¶

Third-party Plugins¶

About `repoze.who` Plugins¶

Writing `repoze.who` Plugins¶

Known Plugins for `repoze.who`¶

Plugins shipped with `repoze.who`¶