1What's New in Python OpenID 2.1.0
2=================================
3
4This implementation of OpenID has been upgraded to support version 2.0
5of the OpenID Authentication specification.
6
7New in this version is:
8
9 * Verification of relying party return_to addresses, to screen out RPs
10   hiding behind open redirect relays.  Server code can invoke this with
11   the returnToVerified method on CheckIDRequest.
12
13 * Helper module for the Provider Authentication Policy Extension (PAPE) in
14   openid.extensions.pape.
15
16 * Helper module for Attribute Exchange in openid.extensions.ax.
17
18Bugfixes:
19
20 * Allow the use of lxml as an ElementTree implemenation.
21
22 * Provide compatability with a wider range of versions for SQL stores.
23
24
25Upgrading from 2.0.1
26--------------------
27
28The third argument to Consumer.complete() is required.
29
30The sreg module should be imported from openid.extensions.sreg instead of
31openid.sreg.
32
33The ax module should likewise be imported from openid.extensions.ax
34instead of openid.ax
35
36The openid.extensions.ax.FetchRequest.fromOpenIDRequest method now
37takes a CheckIDRequest object instead of a Message object
38
39The OpenID response (the result of Consumer.complete()) now has a
40getDisplayIdentifier() method which should be called instead of
41accessing response.identity_url.  The value of getDisplayIdentifier()
42will be the XRI i-name if XRI is used.  The value of
43response.identity_url SHOULD, however, be used as the application's
44database key for storing account information.
45
46What's New in Python OpenID 2.0
47===============================
48
49The big news here is compatibility with svn revision 313 of the OpenID 2.0
50draft specification.
51
52Highlights include:
53
54 * Simple Registration support in a new module openid.sreg.  (Those
55   previously using SuccessResponse.extensionResponse are advised to
56   look here.)
57 * OpenID provider-driven identifier selection.
58 * "Negotiators" allow you to define which association types to use.
59 * Examples for Django.
60
61Dependencies
62------------
63
64Python 2.5 is now supported.  Support for Python 2.2 discontinued.
65Seperate installation of yadis and urljr packages is no longer
66required; they have been included in this package.
67
68
69Upgrading from 1.1 or 1.2
70-------------------------
71
72One of the additions to the OpenID protocol was a specified nonce
73format for one-way nonces.  As a result, the nonce table in the store
74has changed.  You'll need to run contrib/upgrade-store-1.1-to-2.0 to
75upgrade your store, or you'll encounter errors about the wrong number
76of columns in the oid_nonces table.
77
78If you've written your own custom store or code that interacts directly with it,
79you'll need to review the change notes in openid.store.interface.
80
81Consumers should now pass an additional parameter to Consumer.complete()
82to defend against return_to tampering.
83
84
85What's New in Python OpenID 1.1.2
86=================================
87
88i-name Support
89--------------
90
91This version of the library allows the use of XRI as OpenID identifiers,
92allowing users to log in with their i-names.  For full XRI compatibility,
93relying parties integrating this library should take note of the user's
94CanonicalID, as described in the "Identifying the End User" section of the
95OpenID 2.0 specification.
96
97Bug Fixes
98---------
99
100A variety of bug fixes were included in this release, mostly relating to
101international issues such as dealing with other character sets, Unicode,
102incorrectly flagging certain Norwegian trust roots as suspect, and operation
103of the filesystem-backed store on exotic platforms.
104
105Dependencies
106------------
107
108 * urljr 1.0.1
109 * yadis 1.1.0
110
111
112What's New in Python OpenID 1.1.0
113=================================
114
115Version 1.1 of the Python OpenID library implements recent changes to
116the OpenID specification as well as making API changes that should
117make integration with applications easier.
118
119Yadis Support
120-------------
121
122One of the major changes to OpenID since the last release has been the
123approval of Yadis discovery as the preferred way to specify the OpenID
124metadata for an identity URL instead of using <link> tags in
125HTML. This library does Yadis discovery, and if that fails, it falls
126back to old-style discovery.
127
128Some advantages of Yadis support are:
129
130 * Support for fallback if your primary OpenID provider is not available
131
132 * Support for load-balancing between OpenID servers
133
134 * Easy interoperability for different identity services
135
136For more information about Yadis, see http://yadis.org/
137
138Extension Support
139-----------------
140
141OpenID also has formalized support for extensions. Extensions are a
142mechanism for transferring information from the consumer to the server
143and from the server to the consumer in the process of performing
144OpenID authentication. Extensions are implemented as additional
145namespaced query arguments that go along with standard OpenID requests
146and responses. This library provides a simple API for adding extension
147arguments to requests and extracting extension responses from replies.
148
149Dependencies
150------------
151
152These dependencies should be available from wherever you acquired the
153OpenID library.
154
155 * urljr - The fetcher abstraction from the previous OpenID library
156   has been extended and is also used for the Yadis library. Because
157   the Yadis library is useful without the OpenID library, the HTTP
158   fetching code has been rolled into its own package. Additionally,
159   the library now has the concept of a default fetcher to make APIs
160   simpler.
161
162 * yadis - The Yadis library provides a general discovery layer that
163   has been adopted by OpenID as well as other identity-related
164   protocols. Most OpenID identity URLs will work without the Yadis
165   library, but as time goes on, this library will be more and more
166   important.
167
168Consumer API
169------------
170
171The consumer API has been changed for more natural use as well as to
172support extension arguments.
173
174 * OpenIDConsumer(store, [fetcher], [immediate]) is now
175   Consumer(session, store)
176
177  - The session object is a dictionary-like object that should be
178    tied to the requesting HTTP agent, for example, using a session
179    ID cookie. It is used for Yadis fallback and holding the state
180    of the OpenID transaction between the redirect to the server
181    and the response. The values that are placed in the session are
182    namespaced, so there should not be a conflict with other uses
183    of the same session. The session namespace is an attribute of
184    the Consumer object.
185
186  - Because the consumer object now does session management, it is
187    necessary to construct a new consumer object for every
188    request. Creating consumer objects is light-weight.
189
190 * OpenIDConsumer.beginAuth(user_url) is now Consumer.begin(user_url)
191   and either returns an AuthRequest object or raises an
192   exception. There is no more tuple unpacking or status codes.
193
194 * OpenIDConsumer.constructRedirect(authreq, return_to, trust_root) is
195   now AuthRequest.redirectURL(trust_root, return_to, [immediate]).
196
197 * OpenIDConsumer.completeAuth(token, query) is now
198   Consumer.complete(query). It no longer returns a tuple. Instead it
199   returns an object that has a status code and additional information
200   about the response. See the API documentation for more information.
201
202Server API
203----------
204
205The server API has been changed for greater extensibility.  Instead
206of taking an "is_authorized" callback, processing happens in several
207stages, allowing you to insert extension data into the response
208before it is signed and returned.  See the documentation for the
209openid.server.server module.
210
211Fetcher API
212-----------
213
214 * fetcher was openid.consumer.fetchers.OpenIDHTTPFetcher, is now
215   urljr.fetchers.HTTPFetcher.  get() and post() have been replaced by
216   fetch(), see urljr.fetchers for details.
217
218Upgrading from 1.0
219------------------
220
221The server changed the way it indexes associations in the store, so if
222you're upgrading a server installation, we recommend you clear the old
223records from your store when you do so.  As a consequence, consumers
224will re-establish associations with your server a little sooner than
225they would have otherwise.
226