Non-recoverable auth failure?
Carl Howells
chowells at janrain.com
Tue Jun 28 16:26:01 PDT 2005
Brad Fitzpatrick wrote:
> Changing post_grant I'm still debating: perhaps it just needs to be
> documented that post_grant=return is implied in checkid_setup mode,
> which just leaves post_grant=close for closing new windows. And it
> seems a little silly to redirect the UA to another URL whose sole
> responsibliity is doing "window.close()" when that'll be such a common
> request from consumers. HOWEVER-- I like the possibility of a
> post_grant_url being able to complete the final click of an AJAX-style
> login box without the login box having to do checkid_immediate
> polling. But I think you can do that with postgrant=return anyway, so
> I have to think about this more.
This is the one part of this still worth debating, and I'm more sure
that the current approach is wrong than ever.
As for the silliness you mention, having the consumer serve a page just
for window.close(), isn't really an accurate description of what
happens. First, there's a full id_res response in the returned value.
That means that the consumer can finish logging in the user before
returning any page, and without any extra redirects or requests.
Second, since the login has completed, the page served can include
javascript to inform window.opener that the login has *already*
completed, and to move on, as well as closing the new window. That
seems like a great deal more than just serving a page containing a
window.close() command.
Furthermore, there are huge code complexity issues involved with
supporting the post_grant parameter. It's trivial for the server to
craft a user_setup_url that is exactly the same as the checkid_setup
request url would be. Doing so leads to maximal code-reuse in the
implementation of the server... No special cases need to be for
handling the user_setup_url, and everything stays nice and generic.
Unfortunately, it isn't that simple. The behavior of constructing such
a URL is only correct if your openid server deviates mildly from the
spec, and allows the post_grant field to be set on any checkid_setup
request. That's plainly silly, though it still seems a better approach
than duplicating a lot of code just for the user_setup_url.
Get rid of the post_grant parameter. Please. It adds complexity to the
spec. (In fact, it might currently be the least well defined part of
the spec.) It adds complexity to implementations. It encourages bad UI
design. It just doesn't make sense to have it around.
Carl Howells
(begging on this issue)
More information about the yadis
mailing list