Home | Trees | Indices | Help |
|
---|
|
Consumer
instance. More on the abstract store
type and concrete implementations of it that are provided in the
documentation for the __init__
method of the Consumer
class.
This consumer library is designed with that flow in mind. The goal is to make it as easy as possible to perform the above steps securely.
At a high level, there are two important parts in the consumer
library. The first important part is this module, which contains the
interface to actually use this library. The second is the openid.store.interface
module, which describes
the interface to use if you need to create a custom method for storing
the state this library needs to maintain between requests.
In general, the second part is less important for users of the library to know about, as several implementations are provided which cover a wide variety of situations in which consumers may use the library.
This module contains a class,Consumer
, with methods corresponding to the
actions necessary in each of steps 2, 3, and 4 described in the
overview. Use of this library should be as easy as creating an
Consumer
instance and calling the methods
appropriate for the action the site wants to take.
OpenID is a protocol that works best when the consumer site is able to store some state. This is the normal mode of operation for the protocol, and is sometimes referred to as smart mode. There is also a fallback mode, known as dumb mode, which is available when the consumer site is not able to store state. This mode should be avoided when possible, as it leaves the implementation more vulnerable to replay attacks.
The mode the library works in for normal operation is determined by the store that it is given. The store is an abstraction that handles the data that the consumer needs to manage between http requests in order to operate efficiently and securely.
Several store implementation are provided, and the interface is
fully documented so that custom stores can be used as well. See the
documentation for the Consumer
class for more information on the
interface for stores. The implementations that are provided allow the
consumer site to store the necessary data in several different ways,
including several SQL databases and normal files on disk.
In the flow described above, the user may need to confirm to the identity server that it's ok to authorize his or her identity. The server may draw pages asking for information from the user before it redirects the browser back to the consumer's site. This is generally transparent to the consumer site, so it is typically ignored as an implementation detail.
There can be times, however, where the consumer site wants to get a response immediately. When this is the case, the consumer can put the library in immediate mode. In immediate mode, there is an extra response possible from the server, which is essentially the server reporting that it doesn't have enough information to answer the question yet. In addition to saying that, the identity server provides a URL to which the user can be sent to provide the needed information and let the server finish handling the original request.Integrating this library into an application is usually a relatively straightforward process. The process should basically follow this plan:
Add an OpenID login field somewhere on your site. When an OpenID is entered in that field and the form is submitted, it should make a request to the your site which includes that OpenID URL.
First, the application should instantiate the Consumer
class using the store of choice. If
the application has any sort of session framework that provides
per-client state management, a dict-like object to access the session
should be passed as the optional second parameter. The library just
expects the session object to support a dict
-like
interface, if it is provided.
Next, the application should call the 'begin' method on the Consumer
instance. This method takes the
OpenID URL. The begin
method returns an AuthRequest
object.
Next, the application should call the redirectURL
method on the AuthRequest
object. The parameter
return_to
is the URL that the OpenID server will send the
user back to after attempting to verify his or her identity. The
trust_root
parameter is the URL (or URL pattern) that
identifies your web site to the user when he or she is authorizing it.
Send a redirect to the resulting URL to the user's browser.
That's the first half of the authentication process. The second half of the process is done after the user's ID server sends the user's browser a redirect back to your site to complete their login.
When that happens, the user will contact your site at the URL given
as the return_to
URL to the redirectURL
call made above. The request will
have several query parameters added to the URL by the identity server
as the information necessary to finish the request.
Get an Consumer
instance, and call its complete
method, passing in all the received
query arguments.
|
|||
Consumer An OpenID consumer implementation that performs discovery and does session management. |
|||
AuthRequest | |||
SuccessResponse A response with a status of SUCCESS. |
|||
FailureResponse A response with a status of FAILURE. |
|||
CancelResponse A response with a status of CANCEL. |
|||
SetupNeededResponse A response with a status of SETUP_NEEDED. |
|
|||
FAILURE = 'failure' constant used as the status for FailureResponse objects. |
|||
SUCCESS = 'success' constant used as the status for SuccessResponse objects. |
|||
CANCEL = 'cancel' constant used as the status for CancelResponse objects. |
|||
SETUP_NEEDED = 'setup_needed' constant used as the status for SetupNeededResponse objects. |
|
FAILUREconstant used as the status for FailureResponse objects.
|
SUCCESSconstant used as the status for SuccessResponse objects.
|
CANCELconstant used as the status for CancelResponse objects.
|
SETUP_NEEDEDconstant used as the status for SetupNeededResponse objects.
|
Home | Trees | Indices | Help |
|
---|
Generated by Epydoc 3.0alpha3 on Fri Dec 8 13:26:20 2006 | http://epydoc.sourceforge.net |