Do you have a question? Post it now! No Registration Necessary. Now with pictures!
September 24, 2011, 7:56 pm
rate this thread
(*) take a user-provided identifier (be it a username, email address,
literal openID, or ID provider domain name,...),
(*) launch into whatever ID-discovery or provider conversation is
necessary to authenticate via *one* of the OpenIDs or OpenID-like
mechanisms that user has *previously* registered,
(*) invoke a local password-authentication if no providers are
actually registered with the account in question.
(*) redirect back to some predetermined place once *some*
corresponding ID is established.
The point is to be able to easily put up
(*) a sign-in form with ONE field in it, the user types something, and
we just Do The Right Thing to get them signed in, via whichever
provider(s) they've previously specified for their account is
available at the moment.
(*) a form for registering new OpenIDs with one's account, to be used
by already-signed-in users, which goes through the authentication
to ensure that said IDs actually belong to them.
This is NOT about accepting arbitrary OpenID signins but rather giving
an existing userbase the option of authenticating with OpenID instead
of via password.
It is mostly a front-end to Net::OpenID::Consumer, except it also
allows for having fake back-ends for "providers" like Facebook or
Microsoft that use their own protocol, so long as they can be
shoehorned into into the general check-immediate->check-direct
->verify template that OpenID uses.
I was originally waffling between
but even though it's OpenID-inspired and going to be used with OpenID
providers *most* of the time, I'm not certain it belongs in the
Net::OpenID hierarchy (perhaps it does,... never mind that the modules
page discourages this kind of use of the Net:: heirarchy at all,
though Net::OpenID::Server/Consumer was allowed, so I don't know...).
And since the module is intended to be agnostic about CGI.pm
vs. Apache2/mod_perl (current agenda is to adapt it for FastCGI as it
happens, but never mind that) -- we just need a request object of
*some* sort -- it clearly doesn't belong under Apache:: or CGI::
Meanwhile my understanding is that
is more for high-level applications,
is more for implementation of the HTTP protocol/extensions
would imply that this makes sense in a
non-browser/HTTP context, which it mostly doesn't
So, ... thoughts?