Inferring return_to

[Martin Atkins]

Brad Fitzpatrick wrote:
> 
> Look, you already fucked up:  you can't just append a "?" without checking
> for an existing "?".  So you'll say:
> 
>    $url .= ($url =~ /\?/ ? "&" : "?") . "foo=bar";

This isn't like the other cases where we're taking someone else's URL
and adding arguments to it. I'm generating the entire URL, so I know
whether it already has a query string in it.

> But at that point, why not:
> 
>    $url = URL->new($url)->param("foo", "bar");
> 
> Whoops, I just used a URL class, and I'm not sure how it's implemented.
> 
> See?
> 

Fair enough. Still seems like it'd be easier to say:
$url = "http://www.mysite.com/openid?foo=bar&sid=".$sid;
or perhaps
$url = $LJ::SITEROOT."/openid/login.bml?crazyparam=".$crazy;
(if you don't like the idea of hardcoding the full URL)

Either way I can easily recreate the exact same URL for validation later
as all of that data is still available. I'd also be pretty concerned if
a URL class didn't have exactly the same result given the same set of
operations on it; even if the ordering is crazy, it should be crazy in
the same way every time.

I'm not at all against having the return_to URL repeated back in the
response, but I'm certainly never going to use it so for me it's just a
waste of query string space. I trust my own URL forming code more than I
trust the ID server not to send back something completely off the wall,
and if the ID server's sending back incorrect reply_to URLs I'd want it
to fail horribly so that they stop doing that.