OpenSAMLv3 HTTPPostEncoder sending OPTIONS request instead of POST

Mark Watson mjw4tson at gmail.com
Fri Mar 15 20:50:17 EDT 2019


Thanks for the quick response Brent. Confirming that I was using the latest
Chrome to test it.

Unfortunately I just left the office and our VPN connection is down at the
moment. I'll have to give it a shot on other browsers and also try
disabling JS in chrome on Monday.

-Mark

On Fri, Mar 15, 2019 at 5:44 PM Brent Putman <putmanb at georgetown.edu> wrote:

>
> On 3/15/19 8:21 PM, Mark Watson wrote:
>
>
>
> I've built a LogoutRequest and wrapped it in a MessageContext, but when I
> call the encode method the subsequent SAML request is sent using an OPTIONS
> request. My understanding of OPTIONS is that it's used for CORS to
> determine if the destination server will accept the subsequent requests,
> but when I use a SAML trace tool my LogoutRequest is being sent in the
> OPTIONS request body. Any idea where I could be going wrong? Here's my code:
>
> Yeah, that's very odd.  As you probably know, in this binding the actual
> HTTP request to the SAML protocol recipient is being sent by the user's
> browser, based on the HTML form returned by the SAML protocol sender.  I
> don't know of any reason off-hand why the browser would do that.  Maybe
> Scott has heard of something like this.   I've heard mention of Chrome
> doing weird things...  What browser is this?  Do you see the same with a
> different browser?
>
> In terms of confirming what is going on, it would be useful for you to
> confirm exactly what the page/form returned by the encoder looks like.
> Either use browser debugging tools to see the HTTP response body from the
> SAML sender, or turn off Javascript in the browser just prior to invoking
> this so the form doesn't auto-post and then do a view source in the browser.
>
> I'm 99.99% certain that will show the form having method="post", since
> that's pretty much all OpenSAML will do.  If that's the case, then the
> OPTIONS request is due to something that the browser is doing, and we'll
> just have to go from there.  That is out of our control, and very troubling
> if browsers are starting to misbehave like that.
>
> Thanks,
> Brent
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190315/3f2a0261/attachment.html>


More information about the dev mailing list