MessageHandlers and SOAP faults

[Cantor, Scott]

On 6/12/15, 8:13 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

>I wouldn't have thought that was important in the proposed scenario where the whole Fault is supplied.  What's the reason or use case for *not* wanting to send the FaultString (much less the Detail) if that's what the Fault emitter wanted?  I guess AddSOAPFault could remove the FaultString if detailedErrors=false, but I'm not seeing why it should.

Just the general requirement to be able to mask any detailed information that might have security implications.

>Yes, that is actually the other problem I see with the AddSOAPFault approach, hence my initial comments about the generics.  The way I always envisioned SOAP fault handling to work (or any error handling pipeline where the error message type wasn't the same as the "regular" message type) was via a dedicated outbound pipeline.  That was the point behind the stuff I put into messaging-api, package org.opensaml.messaging.error.

I don't remember ever seeing any of that code.

If you want to rewrite these flows, I guess all I can say is you're welcome to do that, they're virtually all implementation classes and system flows. There's nothing inherently fixed about any of it, which is very deliberate.

For me, I got nothing useful out of specializing the PRC message types, and it was all much simpler to just use the message slots for whatever needed to be in them at the appropriate time. That didn't cause me any concern because I never wrote much code that assumed anything about the message types, or at least if I did they were downstream of other actions that had already enforced the type and would have aborted the flow.

-- Scott