[OpenID] ANN: Python OpenID 2.0.0 Release Candidate 1

[Wichert Akkerman]

Previously Kevin Turner wrote:
> (Moving the code-specific discussion to the dev list.  Wichert, are you
> on this list?)

I'm not. Subscribe mail send to dev-request does not seem to result
in a reply and the signup form seems to insist on an OpenID even though
the help text says you can use a password instead of an OpenID.

> > * HTTPFetchingError is now found in openid.fetchers instead of
> >   urljr.fetchers
> 
> I'll update the documentation to mention it, but I'll also mention that
> I think we've caught HTTPFetchingError when necessary, so it should be
> an internal implementation detail you don't have to worry about.  If you
> find a public method in the Consumer or AuthRequest classes that leaks
> that exception, let me know, because that's a bug.

The example code uses that, which is why I noticed it.

> > * yadis is not available as openid.yadis instead of direct yadis
> 
> I'll go check out your code to see where you're importing the yadis
> module.  I wasn't aware of folks depending on it directly.

I use it to get to the DiscoveryFailure type. The example consumer does
the same thing.

> > * the request object has a new shouldSendRedirect method which needs to
> >   be checked before request.redirectURL can be used. If a redirect is
> >   not used a new formMarkup method must be used to generate a
> >   redirection html (?)
> 
> Shh!  I was hoping you wouldn't notice that part.  shouldSendRedirect
> will recommend that you use a form-POST if the provider supports OpenID
> v2, but redirect will still work.  Using a form-POST requires more
> changes to your code; you need to include that form on a HTML page and
> either get the user to click a button or include a javascript hack to do
> it.  The only versions of that javascript hack I've seen tend to make it
> impossible to use the browser's Back button.  So, if I didn't go out of
> my way to encourage people to start using that feature, that's why.
> 
> The only time you'll need it is if you're transferring more data in an
> OpenID extension than will fit in a GET request.  If you're upgrading an
> OpenID 1.1 application, you're not doing that.  When you are, you'll
> figure it out.

Ok. That suggests that it will be needed if we are requesting extra user
properties. And that's something I'm saving for the next version.

> So there certainly are changes that haven't been documented in the NEWS
> file.  (Although I wouldn't say there are /no/ hints; the first bullet
> point directs people using extensionResponse to look at openid.sreg and
> the upgrading section talks about passing return_to to
> Consumer.complete.)  But I have had at least one report of a smooth and
> successful upgrade without needing to know any more than that.

I'll give this a try over the weekend and let you know the result.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.