Hi Does this involve any AIP changes in handler interface ? , it is ok to change the handler abstract class not the interface.
Thanks Deepal > Hi David: > >> I'm sympathetic to the argument of getting into the habit of doing the >> right thing, but what you're suggesting means we'll repeatedly do role >> processing for all headers in every handler which doesn't seem >> optimal. > > I think it works out to pretty much a wash. The way we do it now, > which is each handler scanning the headers for what it's interested in > (by namespace) and then checking that subset for roles (which only > happens for addressing right now, ugh) ends up being almost the exact > same work, just done in a slightly different order. If there are a > LOT of headers targeted at us which don't match - or a lot of headers > in our namespace which aren't targeted at us, we could end up wasting > a little time, which is why a getHeadersToProcess(rolePlayer, > namespace) might be good as it would cycle through only once. But > I'm guessing the difference isn't that critical in most cases. > >> So... we could* add a useRolePlayer(RolePlayer rp) to the SOAPHeader >> which would cause all the existing methods to use a once-computed >> subset of the headers until useRolePlayer() is called again (possibly >> with null). Axis2 would set it by default before the handler chain. > > Yep, I'd had that exact same thought while doing the role processing > stuff in Axiom. :) The only issue I had was whether it was right to > make the SOAPHeader that "stateful"... but in thinking about it a > little more I think it's fine, since we're never really going to be > passing it around outside one node. (speaking of node, we should also > be supporting the SOAP 1.2 node attribute....) > > Plus to this approach - all accessors automatically respect roles. > Minus - we have to do the subsetting/filtering each time we have a > role change... so for instance if a Module wanted to use its own role, > we'd need to add that one somehow. > > I dunno, I think we might want to go for it. > >> The only problem I forsee with that I don't know how it would work >> with ws-sec (where presumably the role could be encrypted to begin >> with?) > > If Rampart decrypts a header, it needs to start the processing model > again, at least for that header. See section 9.4.5 of [1]. So for > this, we'd either rebuild or just add to the stored subset as necessary. > > --Glen > > [1] > http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
