Table Of Contents

Previous topic

Adding a custom login cleaner

Next topic

Adding OpenID Support

Using who.ini

Once you have disabled your quickstart configuration (see Disabling authentication and authorization), you may find yourself wanting to use the who.ini configuration mechanism referenced in most repoze.who documentation. This section describes how to create a who.ini-based configuration that looks much like the quickstart configuration you just disabled.

Since repoze.who is WSGI middleware, you will need to alter your project’s file to create your middleware from your .ini file:

from repoze.who.config import make_middleware_with_config as make_who_with_config
    # Wrap your base TurboGears 2 application with custom middleware here
    app = make_who_with_config(

and add the following to your config file’s app:main section:

who.config_file = %(here)s/who.ini
who.log_level = debug
who.log_file = stdout

at this point, you are using the standard repoze.who configuration mechanism, so should be able to follow most repoze.who documentation to complete your configurations.

Quickstart via who.ini

If you would like to start off your customizations with something similar to the repoze.who.quickstart mechanism, you can use standard mechanisms to set up most of the machinery that the quickstart provides. Here is a sample who.ini that provides much of the quickstart behaviour:

# Sample of a who.ini file from which to begin configuring
# this looks a lot like the "quickstart" application's setup,
# minus the translation capability...

# Cookie-based session identification storage
use = repoze.who.plugins.auth_tkt:make_plugin
secret = 'this secret is not really very SECRET!'

# Redirecting form which does login via a "post"
# from a regular /login form
use = repoze.who.plugins.friendlyform:FriendlyFormPlugin
login_form_url= /login
login_handler_path = /login_handler
logout_handler_path = /logout_handler
rememberer_name = auth_tkt
post_login_url =
post_logout_url =

# An SQLAlchemy authorization plugin
use = customwho.lib.auth:auth_plugin

# Now the configuration starts wiring together the pieces
request_classifier = repoze.who.classifiers:default_request_classifier
challenge_decider = repoze.who.classifiers:default_challenge_decider

# We can decide who the user is trying to identify as using either
# a fresh form-post, or the session identifier cookie
plugins =

plugins =

plugins =

# Metadata providers are the things that actually look up a user's credentials
# here we have a plugin that provides "user" information (md_plugin) and another,
# which acts as an adapter to the first, to provide group/permission information.
plugins =

Note that “customwho” is the project name here. Also note that the who.ini file references a custom Python module customwho.lib.auth which is where we set up our repoze.who plugins in the normal manner for repoze.who:

"""Example of a simplistic, importable authenticator plugin

Intended to work like a quick-started SQLAlchemy plugin"""
from import (
from repoze.what.plugins.sql import configure_sql_adapters
from repoze.what.middleware import AuthorizationMetadata

from customwho import model
auth_plugin = SQLAlchemyAuthenticatorPlugin(model.User, model.DBSession)
md_plugin = SQLAlchemyUserMDPlugin(model.User, model.DBSession )
_source_adapters = configure_sql_adapters(
md_group_plugin = AuthorizationMetadata(
    {'sqlauth': _source_adapters['group']},
    {'sqlauth': _source_adapters['permission']},

# THIS IS CRITICALLY IMPORTANT!  Without this your site will
# consider every repoze.what predicate True!
from repoze.what.plugins.pylonshq import booleanize_predicates

This module creates a number of plugins which the who.ini file references. It is also possible to configure plugins to accept parameters from the who.ini configuration file (by specifying a plugin: section and providing the parameters).


Without the booleanize_predicates() call you will find that almost all TurboGears code will fail. TurboGears calls this when the authorization stack is enabled (we have disabled it, you will recall), and most TurboGears code was written to expect the authorization stack to be enabled.

Next Steps

  • Adding OpenID Support – describes how to use a Repoze.who plugin to authenticate users via the OpenID mechanism


  • Pylons Repoze.who Cookbook – describes how the repoze.who middleware fitted into a Pylons application (TurboGears 2.1 is a Pylons application)