Srinath Perera wrote:
Well, IMO the idea of the infault flow is as high level as the inflow
.. I belive the wsdl makes it so. One can have a dispatcher to do the
check for a fault .. (he should not/ can not do the service disptah if
it is a fault. ) Then it is we calling the infualt flow with in the
in-flow.
But we are running in to this chicken and egg problem too often
.somehting is encrypted ...ect ..ect ... may be the pre diapatch
pahses are common to all in* flows ..and we should redefine them so.
Just thinking aloud .. what you guys think?
IMHO decryption and signature verification should happen in an early
inflow handlers (as early as possible) and encryption and signing in one
of the last outflow handlers (if not the last one) - if not then there
is plenty of problems to preserve infoset through handlers.
addressing handler should be after decryption in-flow and definitely
before encryption out-flow (ws-rx/rm may sit between ws-addressign and
WSS handlers).
if there is fault before decryption then there are only limited options
how to handle this - you may not even know whhich target service was
called ...
if there is fault it may still need be encrypted -right?
so what really is the problem? if there is in-flow fault before
addressing handler is reached then no addressing should be used to send
fault as it was not yet reached and problem is in a layer that is
possibly below (like transport or security ...) - right?
if you use addressing FaultTo for invalid message to send fault (such as
wrong signature) you expose a possible denial-of-service (DoS) attack
capability for any axis2 enabled service (send invalid messages to axis2
service that acts as a "zombie" and sends fault message to DoS target
host ...) - there is no easy solution for it AFAIK if no security or
policy is used.
using Basic Authorization / WSS and/or policy on allowed values
FaultTo/ReplyTo should help but it would be no good if security can be
overridden and DoS executed even when service is supposedly using WSS
encryption and signature verification ...
i think maybe there is need for some use cases ...
best,
alek
On 8/17/05, Ajith Ranabahu <[EMAIL PROTECTED]> wrote:
Ahum..
In my personal opinion I see the invokeFault(..) [or whatever it will be
called] as an elegant way of handling the error.So I don't think it's
complicating things. it's actually a better way of dealing with the
complication :)
The very reason why we need a fault flow is to avoid such fall through code
in the handlers :)
On 8/17/05, Eran Chinthaka < [EMAIL PROTECTED]> wrote:
Ok, can I know the things you are thinking of doing in the IN fault
flow, which you don't wanna do in the normal in flow (of course
something other than logging :) )
Hi dims;
Lets say that we have the fault information in the soap header
(addressing)
. In the current implementation what it does is when a message is
received ,
takes the inflow (inflow handles ) and give it to the engine and call
engine.receive(msgContx) ,
addressing handler is in that chain , so we do need to go throgh the
inflow
upto addressing handler to read the addressing headers to know the fault
,
and then we can call engine.receiveFault();
so we have to start the in-fault-flow invocation in the middle of
in-flow;
is that ok?
Isn't this complicating the things ???
Without doing the way you propose, you can achieve the samething like
this.
1. Handler which handlers everything
invoke (msgctx){
if( env.getBody().hasFault()){
// do your fault stuff
}else{
// do normal stuff
}
}
2. Fault Handler (any use cases ??)
invoke (msgctx){
if(env.getBody().hasFault()){
// do your fault stuff
}
}
3. No Difference on faults handler
invoke (msgctx){
// act on msgctx. No difference
}
See my point ??
-- Chinthaka
--
Ajith Ranabahu
--
The best way to predict the future is to invent it - Alan Kay
