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

[Maciek Pasternacki]

On Sun, 2008-07-20 at 17:27 +0200, Leslie P. Polzer wrote:
> Thanks for the elaborate reply. I understood everything pretty
> well, but...
> 
> > 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).
> 
> That's what I'm interested in.
> 
> I see that using IMMEDIATE-P causes my identity provider to redirect
> immediately to my site; but not completely;
> 
> when I say:
> 
>   (initiate-authorization "http://skypher.myopenid.com/"
>       "http://handler.tld/path"
>       "http://realm.tld/"
>    :immediate-p t)
> 
> the redirect will return to http://handler.tld/IDx. How am I
> supposed to catch this? I'd rather be redirected to the full
> URI I specified and then pick up GET parameters or something.


Use trailing slash:
(initiate-authorization "http://skypher.myopenid.com/"
      "http://handler.tld/path/"
      "http://realm.tld/"
   :immediate-p t)

This way, you'll get redirected to http://handler.tld/path/IDx -- that's
how PURI:MERGE-URIS work.   You are supposed to handle whole hierarchy
under http://handler.tld/path/, and to pass IDx as POSTFIX parameter to
HANDLE-OPENID-REQUEST, or get the ID by postfix as this function does:

(handle-indirect-reply parameters (gethash (intern postfix :cl-openid.ids) *ids*))

The GETHASH part will be eventually its own, exported function.

A handler for Hunchentoot with usage example is included after the
"Hunchentoot specific part" comment in relying-party.lisp.  The
INITIATE-AUTHORIZATION function expects the trailing slash -- the
top-level OPENID-HT-DISPATCHER function adds them if necessary.

At the moment (and the prototype will stay this way), the final result
page for all authentication requests is the HTML page with reply
details, no further redirections.  If you wish to hack the possibility
of integration into real site (I wouldn't recommend this), you can add
keyword parameter CALLBACK and/or IMMEDIATE-CALLBACK to
INITIATE-AUTHORIZATION (or just check if the IMMEDIATE-P is a function),
push (cons :CALLBACK CALLBACK) to ID alist, and call appropriate element
from the ID alist in either handler that calls HANDLE-INDIRECT-REPLY, or
make HANDLE-OPENID-REQUEST call the callback if present.  Before the
refactoring, however, you are on your own and I don't recommend actually
using this code as it is now.  I may incorporate your patch into the
prototype, but I will focus now on having the provider, refactoring and
providing proper API.

The GSoC project ends with end of August and that's when I think I will
have the 1.0 with documentation and tests; I think the proper API for
relying party will start to emerge near the end of July.

> And how am I suppose to use this stuff with AJAX, since I
> don't want to do a full page redirect in this case?

At the moment, you are not supposed to use this stuff at all ;) the
internal functions are working, but there is no real API, as I already
wrote -- it's available for testing, as a prototype.  I outlined above,
how I would hack the callback support into current code base -- you're
free to put it there, my focus is on getting to final API.

Regards,
Maciej.

P.S. The change that I wrote about in earlier post (adding "immediate"
checkbox to login form and pretty display of assertion errors on result
page) is already in repo -- it was just a few lines anyway, and pretty
display of exceptions helps in debugging.

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