SAML Response Destination gets "URL encoded" on IDP 2.x

[Brent Putman]

On 4/20/16 12:38 PM, Cantor, Scott wrote:
> I would imagine the only real reason to even do the conversion at all is to enforce the schemes allowed without us implementing any URL parsing, which I'm all for.

Yeah, that's apparently the only reason it's doing that, in both v2 and
v3. 


> The old code base does a pretty aggressive conversion of the original URL into a java.net.URL, then pulls all the individual pieces out one by one (including the query parameters) inside a URLBuilder custom class, and then reconstructs the whole thing. There's no chance a dangling unencoded equals sign would survive that.
>
> The V2 code was very clearly not warranted, but that's water under the bridge since it was thrown out.

Agreed, it's very gratuitous.  Looking at the history, originally v2
didn't do that with the URLBuilder.  It just worked entirely with, and
returned, String values.  When the support for checking allowed URL
schemes was added after the fact, in 2009, that's where the URLBuilder
stuff was introduced.  It's weird because the scheme check is done
right in the same method that returns the endpoint URL, so there really
wasn't any reason to change the type that was returned (which btw was a
breaking API change and shouldn't have been allowed in a patch or minor
release...).  It could have just done the parsing and scheme check
using the URLBuilder internally, but still returned the original
String. But, too late now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160420/8b14efc0/attachment.html>