.. _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
|
<http://westpoint.ltd.uk/advisories/Paul_Johnston_GSEC.pdf>`_ 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/
|
