Customize the POST encoding format?

[Mohamed Lrhazi]

Thanks a lot guys,

If I were to try and modify the enctype value, in the HTML form.. can that
be done on per SP ?

Thanks,
Mohamed.

On Sun, Mar 26, 2017 at 9:59 AM, Tom Scavo <trscavo at gmail.com> wrote:

> On Sat, Mar 25, 2017 at 8:10 PM, Mohamed Lrhazi <lrhazi at cua.edu> wrote:
> >
> > I can see that the Post is indeed URL encoded :
> >
> > Content-Type: application/x-www-form-urlencoded
>
> On the wire, does the <form> element have an @enctype HTML attribute?
> If not, it's default value is "application/x-www-form-urlencoded" by
> definition (of the HTML spec, not the SAML spec).
>
> > I think this is what this SP is complaining about... but is this not
> > expected behavior?
>
> Yes, this is expected behavior. The SAML spec is silent about the
> form/@enctype attribute. The browser may use any value it wants. For
> POST, the default is "application/x-www-form-urlencoded" so that's
> what you'll get unless the @enctype HTML attribute is present on the
> <form> element.
>
> Tom
>
> > On Sat, Mar 25, 2017 at 7:12 PM, Brent Putman <putmanb at georgetown.edu>
> > wrote:
> >>
> >> Hi Mohamed!
> >>
> >>
> >> an SP tells me that I ought to be able to POST the SAMLResposne, without
> >> URLEncoding it...
> >>
> >> Googling around I can't see how I can influence how the browser performs
> >> the POST.. Is there a way to do this in shibboleth 3.3.1.
> >>
> >>
> >> I don't think the Shib IdP is actually encoding (neither URL encoding
> nor
> >> HTML form encoding) the SAMLRequest/SAMLResponse parameter in the POST
> >> binding implementation.  Why do they think we are?  Do you have a sample
> >> message or something from them that demonstrates?   I just looked both
> at
> >> the binding impl code + Velocity template, as well as an actual test
> message
> >> exchange flowing through my browser, and I don't see it.
> >>
> >> Maybe I'm missing something here, and Scott will remind me.
> >>
> >>
> >> Quoting the SP:
> >>
> >> > It doesn't make any sense to post FORM data which is also base64
> encoded
> >> > with URL encoding on top of it. All SSO providers sends pure base64
> encoded
> >> > SAMLResponse and I'm sure the one you are using do have this
> capability.
> >>
> >>
> >> Well, in general, what "makes sense" (or not) to the SP vendor is kind
> of
> >> irrelevant.  What matters is what the spec says:
> >>
> >> Note that any form control values included MUST be transformed so as to
> be
> >> safe to include in the
> >> XHTML document. This includes transforming characters such as quotes
> into
> >> HTML entities, etc.
> >>
> >>
> >>
> >> We clearly are obligated to make sure the HTML is safe against XSS, etc,
> >> and so we do currently HTML form encode the form's action URI and
> RelayState
> >> parameter in the POST binding.  But we don't do anything that I can see
> to
> >> the SAMLRequest/SAMLResponse param.  Since it's Base64-encoded, it's
> already
> >> "safe" - the only possible non-alphanumerics would be '+', '/' and
> '='.  So
> >> I think we're already conceptually in agreement with what the SP is
> saying,
> >> at least via-a-vis the response message param.
> >>
> >> So I just don't know what they are seeing here.  We'd need more specific
> >> details from them.
> >>
> >>
> >> --
> >> To unsubscribe from this list send an email to
> >> users-unsubscribe at shibboleth.net
> >
> >
> >
> > --
> > To unsubscribe from this list send an email to
> > users-unsubscribe at shibboleth.net
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170326/7a682ea4/attachment.html>