Net-OpenID-Consumer 1.10099_002 and Net-OpenID-Common 1.12
Roger Crew
> Is someone here maintaining Net::OpenID::Consumer
- Consumer->args(CODEREF)
CODEREF now needs to be able to also take zero arguments and return a list of all URL parameters in the request.
No change is needed for the other argument types (i.e., unblessed hash or CGI/Apache/etc request object)
(Enumeration is required for check_authentication in OpenID 2.0 to work properly -- if the list isn't available then we revert to OpenID 1.1 behavior of only sending the signed parameters and hope for the best, but be warned that some providers may reject this.)
- Consumer->handle_server_response()
The 'setup_required' callback is now DEPRECATED but still recognized for now for the sake of legacy code. It may be removed in a future release.
Use 'setup_needed' instead. This callback
- is invoked in ALL cases where a checkid_immediate mode request fails, including those where user_setup_url is not supplied, and
- is NOT supplied a user_setup_url parameter (you can still use Consumer->user_setup_url as needed if this is a 1.1 provider)
Note that in OpenID 2.0, the correct way to handle failure of a checkid_immediate mode request is to retry the same request again in checkid_setup mode. user_setup_url is generally not meaningful in OpenID 2.0 and therefore CANNOT be relied upon.
- Consumer->setup_needed() [new function]
Should be used to test for the failed checkid_immediate case when not using handle_server_response().
Testing for user_setup_url() having been set is DEPRECATED and will not work under OpenID 2.0 since user_setup_url is generally not meaningful in 2.0 (even if some 2.0 providers do in fact supply it).
- For 2.0 providers, if you have a cache set, we now check response_nonces and fail on duplicates, which, being a security issue, was a change worth imposing unilaterally (and you can still turn it off if you really want to, which you should if you already have a better defense against replay attacks, but if you don't then this is better than nothing). Use nonce_options to control how this works.
- We now handle all OpenID 2.0 association and association-session types. Use assoc_options to control how this works.
- We are now using a genuine HTML parser (HTML::Parser) to do HTML discovery. Also, we are *no longer* doing any HTML-parsing/<body>-removal on XRDS pages as if they were HTML pages, which was Just Wrong.
- There are new error codes, notably "provider_error" -- for openid.mode= 'error' messages in OpenID 2.0 -- and the various "nonce_*" errors for failures that happen during response_nonce checking. Also useless 'bad_mode' errors should be showing up less often.
- Consumer->args() now understands Plack::Request objects, so if you want to convert to a generic server setting, that should be a lot easier now.
Roger Crew
Paul Lockaby
Paul Lockaby
>
> There are admittedly some remaining issues with the co-maintainership bits, which are set for me for some of the modules but not others, which is why I can release an official Net-OpenID-Common but my Net-OpenID-Consumer is still "unauthorized" and is also why I can't currently close any of the bugs that that are still open on rt.cpan.org, even though nearly everything there is actually fixed now .
>
> Basically, Mart, Rob and I are waiting for Brad to wake up and read his email.
>
Would it make more sense to combine Net::OpenID::Common,Consumer,Server into just one package called Net::OpenID? Then you could release that on CPAN with no problems, and people like me wouldn't wonder if changes to one are working with changes to another and that I've got all the latest versions?
Roger Crew
will Net-OpenID-Common remain compatiable with Net-OpenID-Server?
Would it make more sense to combine Net::OpenID::Common,Consumer,Server
Paul Lockaby
> will Net-OpenID-Common remain compatiable with Net-OpenID-Server?
>
> that's the plan. Nothing has changed on -Common that should be breaking anything on -Server. (Arguably, it would make *some* sense for me to have a maintainer bit on Server as well, but not being an actual user of Server I haven't yet had occasion to go through it, so the issue is moot at the moment)
I hope that continues to be the case! I'm positive that you won't intentionally break anything in Server, but I figured I'd ask.
> Would it make more sense to combine Net::OpenID::Common,Consumer,Server
>
> no because we (or rather RobN, actually) just finished splitting it up, the general theory being that most people who want to use OpenID either need to build a provider or build a relying party -- it's rare that one needs to do both.
Well, I built a client into a web app and then decided I wanted to run a server and not use my Google ID but rather my own. :) If I may ask, what are the benefits behind splitting it up into three pieces? (I'm not questioning it, I just am curious about the benefits that are envisioned.)
Honestly, I love that updates are happening! This set of modules needs some love. I'll let you know if I experience any problems with the server part.
-Paul
Roger Crew
On Friday, November 4, 2011 9:08:18 PM UTC-7, Paul Lockaby wrote:
> no because we (or rather RobN, actually) just finished splitting it up, the general theory being that most people who want to use OpenID either need to build a provider or build a relying party -- it's rare that one needs to do both.
Well, I built a client into a web app and then decided I wanted to run a server and not use my Google ID but rather my own. :)
If I may ask, what are the benefits behind splitting it up into three pieces? (I'm not questioning it, I just am curious about the benefits that are envisioned