MessageHandlers and SOAP faults

[Brent Putman]

On 6/11/15 9:24 PM, Cantor, Scott wrote:
> I guess my take is that if it's ultimately a profile flow running your handler here, just have the MessageHandler throw an exception that will get mapped to an Event in the surrounding profile flow and then AddSOAPFault could be used in the "outer" flow that's actually invoking the handler. That's basically how the ECP stuff works I think.

It could certainly.  I was focused on the fact that the Event mapping
isn't very rich in detail.  All you basically get to do is map an Event
to a QName code.  That may or may not be enough.

But that is close to what I had in mind:  1) the emitter sets the Fault
in the context tree somewhere 2) it then throws 3) (IIUC) something up
above in SWF is catching that exception, and mapping it to an action to
run (e.g. AddSOAPFault) 4) that action, as one possible strategy, can
pull the previously-set fault out and use it directly.

>
> Isn't the problem that you don't have a ProfileRequestContext at all? 
In MessageHandler, right, no PRC.

> If you have one, you can just move the FaultCodeMappingFunction out of the MessageHandler 

Oh, no, it wouldn't be in the MessageHandler. I'm talking strictly
about what the AddSOAPFault action does.  Adding another strategy there.

> into some place that's not "disallowed" from knowing about the EventContext and inject it with Spring when the time comes. The default function could be something more neutral.

The MessageHandler does have the MessageContext which is part of the
PRC.  So the proposed strategy function injected to AddSOAPFault could
pull it out of the inbound PRC MessageContext.

I'm just proposing an additional strategy to pull a Fault directly out
of the PRC, in addition tho the current one that pulls the Event out
and maps to QName.

>
>> The way I did it in the delegation extension was to have the fault-emitting code store an actual Fault object in a message subcontext, and then something later pulls it out.  Can you see any reason not to augment the AddSOAPFault action with an additional Function<ProfileRequestContext,Fault>,
>> which if non-null and it produces anything, bypasses the rest?  Or is there a better way?
> That sounds fine too, or just create a different action that suits your needs. But more to the point, I wouldn't really want to not be reusing the same fault-mapping logic in the IdP that's already there.

If by that, you mean having SWF catch thrown Exceptions in the
appropriate places and transitioning to the AddSOAPFault action, I agree.




> The actual use of generics in the PRC is basically unworkable because
> in any given case, you may get an invalid message in there 

I guess I'm not clear how that could happen. If everything were
generic-ed, I don't think you could. 

>
>> Wondering whether all our actions are like that.
> They are, because a lot of stuff crashes if it's actually nailed down. Basically if the generic type is made non-generic, that introduces assumptions that the actual code does not need to impose.

I'll think about it more, but hmmm.  Not what I expected.


>
>>  Anyway, with careful wiring it doesn't actually break I guess, it's just perhaps unsettling...
> I considered at one point just removing the generics entirely because it just doesn't work to use it in many places without turning controllable error checking into runtime exceptions needlessly.
>
> Basically, when you're using generics to avoid casts, you'd better be damn sure that the objects can't ever be anything else,

Which I think can only happen if you have non-generic code operating on
the generic types.  Which I guess I'm saying I didn't think we'd have. 
I'm sure the big picture is complicated though.



>  and these flows are never really sure of that because that's just what getting bad input means.

I'm not seeing how the input would be bad, if everything were properly
generic-ed.  If not, then yes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150611/1d0cdc00/attachment.html>