module name query -- openID/facebook/etc dispatcher

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

The module provides CGI/Apache::Request -style handlers that

(*) 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
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[2]:: 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?

Site Timeline