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