Inferring return_to

[Brad Fitzpatrick]

On Tue, 14 Jun 2005, Martin Atkins wrote:

> Brad Fitzpatrick wrote:
> >
> > It's a royal pain in the ass to reliably infer it, especially generically
> > from a library, which is criticial to adoption.  Plus it imposes
> > additional restrictions on server implementators about how they append URL
> > arguments (which they may have no control over, if they're using a URL
> > object).  People aren't going to hand-code implementations of OpenID like
> > mart and us.  It's so much easier to just get the return_to URL back,
> > parse it, and do checks on the hostname.  Same security, but more
> > flexibility of implementation.
> >
> > I'm going to have to pull rank here and say it's more of a protocol and
> > implementation issue and less a security issue and request it stay in.
> >
>
> I'm not quite sure why anyone would use a "URL class" to do something as
> simple as concatenating ?sid=23534 onto their script URL, but if you say so.

Look, you already fucked up:  you can't just append a "?" without checking
for an existing "?".  So you'll say:

   $url .= ($url =~ /\?/ ? "&" : "?") . "foo=bar";

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?

> I would actually class parsing a URL as more painful than forming one.
>
> > P.S. emailing this from +0100... what up WEST?
>
> Get out of my timezone! (or there abouts) ;)

Stay on your little island!

- Brad