Hi Scott,
On Tue, Oct 1, 2013 at 9:39 PM, Scott Came <[email protected]> wrote: > Hi Asela.**** > > ** ** > > Well… Yes, if you read an entire Response message with a namespace-aware > parser, and you have a default namespace declaration on the root Response > element, then yes, the child elements will be assumed to be in that default > namespace.**** > > ** ** > > But it is entirely possible for someone to access a Result element out of > its Response context, isn’t it? As long as the API allows this (e.g., via > ResponseCtx.getResults()) I think Balana would need to support it. > Otherwise, you risk allowing client code to get invalid XACML fragments.** > ** > > ** ** > > After a little more looking around, I see that this same issue applies to > Status, Obligation…anything with an encode() method. > There is some point.... Yes,.. it means all element seems to have a namespace declaration. But most of the XACML PDP implementations that uses Balana, would try to get the full XACML response from Balana and send it back to the PEP. As PEP and PDP are separated, XACML response would be passed using web service (REST, SOAP) call. Actually It is hard to find places where PEP and Balana have been tightly coupled. But we could look in to this further. > **** > > ** ** > > I suppose another option is to change the encode() methods on all classes > except ResponseCtx to be package-visible so that they can’t be called > externally, but I don’t think that’s the right approach. There could be > perfectly valid reasons for wanting to get the XML content of sub-elements… > **** > > ** ** > > You wouldn’t necessarily need to implement this with the core Java DOM > API, but it would be somewhat easier, IMHO. As for complexity…I don’t > believe you’d find the code to be significantly more complex than what you > have now. It would use an API that’s been native to Java for years, so > there would be no new (external) dependencies. Finally, for the kind of > XML documents we’re talking about here, I wouldn’t expect a DOM approach to > be faster, but I also wouldn’t expect it to be significantly slower. Also, > it will use a little more memory, but not significantly more than the > equivalent String.**** > > ** ** > > I would be happy to help implement this if you’re amenable. > +1. Great.. I guess, we only need to think about the performance here... Also there would be lot places to be changed as encode() is used in every element. Thanks, Asela. > **** > > ** ** > > Thanks.**** > > --Scott**** > > ** ** > > *From:* Asela Pathberiya [mailto:[email protected]] > *Sent:* Monday, September 30, 2013 10:38 PM > *To:* Scott Came > *Cc:* [email protected] > *Subject:* Re: [Dev] Balana response message namespaces**** > > ** ** > > ** ** > > Hi Scott,**** > > On Tue, Oct 1, 2013 at 3:55 AM, Scott Came <[email protected]> wrote:* > *** > > I have noticed that the Result message (i.e., the String produced by > org.wso2.balana.ctx.AbstractResult.encode()) does not appear to qualify > names with namespaces, as required by the XACML 3.0 spec.**** > > ** ** > > AFAIK, Result element is not needed to be qualify with namespace, if > Response element has been already qualified. If i have missed any thing, > Please let us know....**** > > **** > > I was looking at class org.wso2.balana.ctx.xacml3.Result.encode() and was > curious why the output XML is built up as a String, rather than using the > native DOM capabilities, or similar capabilities in XML open source > libraries?**** > > ** ** > > We do not think to add more complexity here. It is returned the String > value.... then it is needed to build a DOM and convert to String... Do you > think, using DOM is faster than string manipulation? **** > > **** > > I notice the same issue applies to > org.wso2.balana.ctx.ResponseCtx.encode(), which actually has some > commented-out code that would add the namespace declaration…**** > > ** ** > > Yes actually it has been commented which is wrong... this is fixed now. * > *** > > **** > > Was there a decision made at some point not to have the response message > conform to the spec?**** > > ** ** > > No. i guess, this is a mistake. namespace was there in earlier trunk > revisions. Thanks for pointing this out. **** > > **** > > Thanks, > Asela.**** > > **** > > Thanks.**** > > --Scott **** > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev**** > > > > > -- **** > > Thanks & Regards,**** > > Asela**** > > ** ** > > ATL**** > > Mobile : +94 777 625 933**** > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Thanks & Regards, Asela ATL Mobile : +94 777 625 933
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
