Module openid.server.server
OpenID server protocol and logic.
Overview
An OpenID server must perform three tasks:
-
Examine the incoming request to determine its nature and
validity.
-
Make a decision about how to respond to this request.
-
Format the response according to the protocol.
The first and last of these tasks may performed by the decodeRequest
and encodeResponse
methods of the Server
object. Who gets to do the
intermediate task -- deciding how to respond to the request -- will
depend on what type of request it is.
If it's a request to authenticate a user (a checkid_setup
or checkid_immediate
request), you need
to decide if you will assert that this user may claim the identity in
question. Exactly how you do that is a matter of application policy,
but it generally involves making sure the user has an account with your
system and is logged in, checking to see if that identity is hers to
claim, and verifying with the user that she does consent to releasing
that information to the party making the request.
Examine the properties of the CheckIDRequest
object, optionally check
CheckIDRequest.returnToVerified
, and and
when you've come to a decision, form a response by calling CheckIDRequest.answer
.
Other types of requests relate to establishing associations between
client and server and verifying the authenticity of previous
communications. Server
contains all the logic and data
necessary to respond to such requests; just pass the request to Server.handleRequest
.
OpenID Extensions
Do you want to provide other information for your users in addition
to authentication? Version 2.0 of the OpenID protocol allows consumers
to add extensions to their requests. For example, with sites using the
Simple
Registration Extension, a user can agree to have their nickname and
e-mail address sent to a site when they sign up.
Since extensions do not change the way OpenID authentication works,
code to handle extension requests may be completely separate from the
OpenIDRequest
class here. But you'll
likely want data sent back by your extension to be signed. OpenIDResponse
provides methods with
which you can add data to it which can be signed with the other data in
the OpenID signature.
For example:
# when request is a checkid_* request
response = request.answer(True)
# this will a signed 'openid.sreg.timezone' parameter to the response
# as well as a namespace declaration for the openid.sreg namespace
response.fields.setArg('http://openid.net/sreg/1.0', 'timezone', 'America/Los_Angeles')
There are helper modules for a number of extensions, including Attribute
Exchange
, PAPE
, and Simple
Registration
in the openid.extensions
package.
Stores
The OpenID server needs to maintain state between requests in order
to function. Its mechanism for doing this is called a store. The store
interface is defined in openid.store.interface.OpenIDStore
.
Additionally, several concrete store implementations are provided, so
that most sites won't need to implement a custom store. For a store
backed by flat files on disk, see openid.store.filestore.FileOpenIDStore
.
For stores based on MySQL or SQLite, see the openid.store.sqlstore
module.
Upgrading
From 1.0 to 1.1
The keys by which a server looks up associations in its store have
changed in version 1.2 of this library. If your store has entries
created from version 1.0 code, you should empty it.
From 1.1 to 2.0
One of the additions to the OpenID protocol was a specified nonce
format for one-way nonces. As a result, the nonce table in the store
has changed. You'll need to run contrib/upgrade-store-1.1-to-2.0 to
upgrade your store, or you'll encounter errors about the wrong number
of columns in the oid_nonces table.
If you've written your own custom store or code that interacts
directly with it, you'll need to review the change notes in openid.store.interface
.