Reviving an old thread...
On 12/14/06, Johnny Bufu <[EMAIL PROTECTED]> wrote:
> On 14-Dec-06, at 12:13 AM, Josh Hoyt wrote:
> > On 12/13/06, Martin Atkins <[EMAIL PROTECTED]> wrote:
> >> Josh Hoyt wrote:
> >>> It's confusing to me make the failure response to an immediate mode
> >>> request be "id_res", especially if that is not the failure response
> >>> for setup mode. I can't see a reason that they can't both use the
> >>> "cancel" response to indicate that the OP or end user do not wish to
> >>> complete the transaction.
> >>>
> >>> This is a very minor change, but it will make the spec simpler.
> >>
> >> I think the RP will want to do something different in these two
> >> cases.
> >
> > That's true, but the RP will probably need to handle the success case
> > differently for immediate mode anyway (e.g. it will have to do AJAX to
> > update the page) so I expect it to have a specific return_to URL for
> > immediate requests. Since using a different return_to is trivial, I
> > prefer the consistency of negative responses.
>
> The current / v1 modes will need to be mentioned in the compatibility
> section, and also implemented. Not sure if this simplification will
> then still be worth.
Since the user_setup_url parameter is now gone, there is no way to
differentiate between a broken/truncated response and a cancel
response to an immediate mode request.
I think that there needs to be *some* positive way to identify
cancellation of immediate mode requests, rather than depending on lack
of other parameters. I'd be happy with any of these ways to positively
identify a cancel response to checkid_immediate:
1. re-using "cancel" as I suggested above
2. introducing a new mode (e.g. "setup_needed" )
3. adding a parameter that the id_res response is an immediate
cancellation (e.g. openid.setup_needed=true)
I no longer buy the argument about having to support the OpenID 1
mechanism in the library, since cancellation of an immediate mode
response is already indicated differently between OpenID 1 and 2, so
it's really just a matter of what goes into the OpenID 2 code path
rather than whether the two code paths exist.
Pseudo-code for the current approach:
def isSetupNeeded():
if this is OpenID 1:
return whether there is a user_setup_url parameter
if this is OpenID 2:
# This is the branch that I want to change
return whether there are any other OpenID parameters passed at all
Thoughts?
Josh
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
