[cl-openid-devel] What happens after verification?

Maciek Pasternacki maciej at pasternacki.net
Sun Jul 20 13:40:25 UTC 2008


On Sun, 2008-07-20 at 10:34 +0200, Leslie P. Polzer wrote:
> > You need to pass the request parameters to the HANDLE-INDIRECT-REPLY
> > function. This function takes care of interpreting the parameters
> > meaning and also verifying that the reply was really from the
> > provider, by verifying digital signature.
> 
> Thanks, that was the missing piece.
> 
> I guess checkid_immediate isn't supported yet?

It is supported.

The function that you are calling, HANDLE-OPENID-REQUEST, is the entry
point for the HTTP request.  It is intended to be called by handlers,
and to be provided GET parameters (plus handler's root URI, realm URI
and request's URI postfix, which I explained earlier).  It does display
simple login form, handle the form's return (that's what you emulate
with your call) and the OP's indirect reply.

This entry point, and the login form, at the moment, calls only
checkid_setup.

The programmer's entry point for starting authorisation process is
INITIATE-AUTHORIZATION.  I think this is what you actually want to call,
and it supports the IMMEDIATE-P keyword parameter.  It returns the URI
to redirect user to.

The actual handler for indirect reply is HANDLE-INDIRECT-REPLY.  This is
the function you should call, if you wish to handle the reply from your
own handler framework.  This function analyses the authentication
response, and returns the identity object (at the moment it's an alist)
on successful authentication, returns NIL on "cancel" (authentication
failure)[1], or raises the OPENID-ASSERTION-ERROR on failure. When setup
is needed, HANDLE-INDIRECT-REPLY raises OPENID-ASSERTION-ERROR with
code :SETUP-NEEDED.  It's up to caller how to handle it.

At the moment, HANDLE-OPENID-REQUEST does not handle the assertion
errors at all.  This is because it should be treated rather as an
example, simple implementation, not as the main entry point.  This is a
plain Web 1.0 interface and endpoint at the same URI, and as such needs
no checkid_immediate support.  To properly use checkid_immediate, more
elaborate setup is needed and it needs to know more of the overall
application (it's supposed to be called from e.g. an AJAX framework,
which may take very different forms).

I may add the "immediate" checkbox to login form, and pretty display of
exceptions on result page, but I wish to leave it to the
polishing-refactoring phase, and now concentrate on having the OP
prototype faster and getting to the refactoring phase earlier.

I know it's hard to figure out all of this at the moment, as no symbols
are even exported.  It's because exporting symbols from published
package means that it's official API that I should provide later on,
and, as I wrote, current project state is nowhere near the final API.

[1] The return values should be probably reworked -- on authentication
failure, the caller may still need to know the ID object.  Probably it
will return T, NIL (or -- if the condition proves problematic
-- :SETUP-NEEDED) as first value, and the ID object as second value.

-- 
-><- Maciej 'japhy' Pasternacki -><- http://www.pasternacki.net/ -><-




More information about the cl-openid-devel mailing list