Troubleshooting the "Unable to decode" (IdP 3.3)

[O'Dowd, Josh]

?  That is pretty consistent with Scott's comments then.  Quite possibly some automated thingy/widget/bot/whatever at Facebook is issuing a request to a resource protected by that SP.  The Facebook thingy is getting back the  redirect from the SP, and in trying to play the role of the browser-compliant HTTP user agent, it's corrupting the request somehow and issuing it to the IdP.   That or something similar is probably what's going on.

?  As Scott says, the User Agent from the Apache log would be very interesting.

I did get the sysadmins to adjust the access logging to include User-Agent, and it looks like you guys were on the right track:
Mozilla/5.0 (compatible; Facebot 1.0; https://developers.facebook.com/docs/sharing/webmasters/crawler)

Now that I know where it is coming from and why, are there any constraints I can put in place at the IdP to reject these requests, or should I make those restrictions at the web server?

Josh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170831/2d5d5ce3/attachment.html>