XPath support completed

[Angel Todorov <at...@gmail.com>]

Hi Ruchith & All,

You can find the xpath support diffs here:

https://issues.apache.org/jira/browse/RAMPART-40

Currently the default strategy with respect to namespace prefixes is
to get and register all defined namespaces in the message, so that the
user can use *any* namespace prefix in the XPath expressions.

An alternative which I have also developed is to use the method
"findDefaultPrefixNamespaces" , which uses a predefined list of
namespaces.

I hope the changes will be committed to rampart-1.2 and will benefit
everyone -:) Thanks.

Best Regards,
Angel

Re: XPath support completed

[Davanum Srinivas <da...@gmail.com>]

How about we have a set of prefixes instead of just 1 prefix. we can
add "wsse, s" which means looks for wsse first and if you can't find
it then fall back to s. yes, it will slow things down. but folks can
always use just one.

-- dims

On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> Hi Angel,
>
> Looks good !
>
> I'm a little concerned with the default namespace strategy since I'm
> not sure how it works in the following example:
>
> - Our client (Rampart) generates a request with standard prefixes such
> as wsse, wst wsc etc.
> - We define the xpath expression in the policy using those.
> - Rampart client talks to a different service where it uses prefixes
> s, t, and sc in the response.
> - Now since those prefixes are not found in the message the xpath will
> not select signed elements for validation.
>
> Thoughts?
>
> Thanks,
> Ruchith
>
> On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > Hi Ruchith & All,
> >
> > You can find the xpath support diffs here:
> >
> > https://issues.apache.org/jira/browse/RAMPART-40
> >
> > Currently the default strategy with respect to namespace prefixes is
> > to get and register all defined namespaces in the message, so that the
> > user can use *any* namespace prefix in the XPath expressions.
> >
> > An alternative which I have also developed is to use the method
> > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > namespaces.
> >
> > I hope the changes will be committed to rampart-1.2 and will benefit
> > everyone -:) Thanks.
> >
> > Best Regards,
> > Angel
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>


-- 
Davanum Srinivas :: http://davanum.wordpress.com

Re: XPath support completed

[Ruchith Fernando <ru...@gmail.com>]

On 5/15/07, Angel Todorov <at...@gmail.com> wrote:
> Hi Ruchith,
>
> Why not combine the two solutions in some way - 1) using a predefined
> and hardcoded, visible to both sender and receiver, namespaces list
> and 2) retrieving all declared namespaces in the SOAP request ? What
> do you think ?

Hmm ... sounds good ... in the case of a duplication I propose we give
preference to those hardcoded values.

Thanks,
Ruchith

>
> Regards,
> Angel
>
> On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> > On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > > Hi Ruchith,
> > >
> > > This is normally done by defining the Signed/Encrypted Elements on the
> > > message level granularity. At least that's what many WS frameworks do,
> > > such as WSIT. Then you can define different signed and encrypted
> > > elements with different XPath expressions for the request and response
> > > messages. I hope this is currently possible with rampart? At least I
> > > have seen that one can apply different policies for each operation ,
> > > and even message, in services.xml.
> >
> > hmm ... true rampart with axis2 can handle message level policies but
> > this doesn't help in the case when a service protected by rampart
> > receives requests form multiple clients.
> >
> > Thanks,
> > Ruchith
> >
> > >
> > > Regards,
> > > Angel
> > >
> > > On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> > > > Hi Angel,
> > > >
> > > > Looks good !
> > > >
> > > > I'm a little concerned with the default namespace strategy since I'm
> > > > not sure how it works in the following example:
> > > >
> > > > - Our client (Rampart) generates a request with standard prefixes such
> > > > as wsse, wst wsc etc.
> > > > - We define the xpath expression in the policy using those.
> > > > - Rampart client talks to a different service where it uses prefixes
> > > > s, t, and sc in the response.
> > > > - Now since those prefixes are not found in the message the xpath will
> > > > not select signed elements for validation.
> > > >
> > > > Thoughts?
> > > >
> > > > Thanks,
> > > > Ruchith
> > > >
> > > > On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > > > > Hi Ruchith & All,
> > > > >
> > > > > You can find the xpath support diffs here:
> > > > >
> > > > > https://issues.apache.org/jira/browse/RAMPART-40
> > > > >
> > > > > Currently the default strategy with respect to namespace prefixes is
> > > > > to get and register all defined namespaces in the message, so that the
> > > > > user can use *any* namespace prefix in the XPath expressions.
> > > > >
> > > > > An alternative which I have also developed is to use the method
> > > > > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > > > > namespaces.
> > > > >
> > > > > I hope the changes will be committed to rampart-1.2 and will benefit
> > > > > everyone -:) Thanks.
> > > > >
> > > > > Best Regards,
> > > > > Angel
> > > > >
> > > >
> > > >
> > > > --
> > > > www.ruchith.org
> > > > www.wso2.org
> > > >
> > >
> >
> >
> > --
> > www.ruchith.org
> > www.wso2.org
> >
>


-- 
www.ruchith.org
www.wso2.org

Re: XPath support completed

[Angel Todorov <at...@gmail.com>]

Hi Ruchith,

Why not combine the two solutions in some way - 1) using a predefined
and hardcoded, visible to both sender and receiver, namespaces list
and 2) retrieving all declared namespaces in the SOAP request ? What
do you think ?

Regards,
Angel

On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > Hi Ruchith,
> >
> > This is normally done by defining the Signed/Encrypted Elements on the
> > message level granularity. At least that's what many WS frameworks do,
> > such as WSIT. Then you can define different signed and encrypted
> > elements with different XPath expressions for the request and response
> > messages. I hope this is currently possible with rampart? At least I
> > have seen that one can apply different policies for each operation ,
> > and even message, in services.xml.
>
> hmm ... true rampart with axis2 can handle message level policies but
> this doesn't help in the case when a service protected by rampart
> receives requests form multiple clients.
>
> Thanks,
> Ruchith
>
> >
> > Regards,
> > Angel
> >
> > On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> > > Hi Angel,
> > >
> > > Looks good !
> > >
> > > I'm a little concerned with the default namespace strategy since I'm
> > > not sure how it works in the following example:
> > >
> > > - Our client (Rampart) generates a request with standard prefixes such
> > > as wsse, wst wsc etc.
> > > - We define the xpath expression in the policy using those.
> > > - Rampart client talks to a different service where it uses prefixes
> > > s, t, and sc in the response.
> > > - Now since those prefixes are not found in the message the xpath will
> > > not select signed elements for validation.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > > > Hi Ruchith & All,
> > > >
> > > > You can find the xpath support diffs here:
> > > >
> > > > https://issues.apache.org/jira/browse/RAMPART-40
> > > >
> > > > Currently the default strategy with respect to namespace prefixes is
> > > > to get and register all defined namespaces in the message, so that the
> > > > user can use *any* namespace prefix in the XPath expressions.
> > > >
> > > > An alternative which I have also developed is to use the method
> > > > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > > > namespaces.
> > > >
> > > > I hope the changes will be committed to rampart-1.2 and will benefit
> > > > everyone -:) Thanks.
> > > >
> > > > Best Regards,
> > > > Angel
> > > >
> > >
> > >
> > > --
> > > www.ruchith.org
> > > www.wso2.org
> > >
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>

Re: XPath support completed

[Ruchith Fernando <ru...@gmail.com>]

On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> Hi Ruchith,
>
> This is normally done by defining the Signed/Encrypted Elements on the
> message level granularity. At least that's what many WS frameworks do,
> such as WSIT. Then you can define different signed and encrypted
> elements with different XPath expressions for the request and response
> messages. I hope this is currently possible with rampart? At least I
> have seen that one can apply different policies for each operation ,
> and even message, in services.xml.

hmm ... true rampart with axis2 can handle message level policies but
this doesn't help in the case when a service protected by rampart
receives requests form multiple clients.

Thanks,
Ruchith

>
> Regards,
> Angel
>
> On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> > Hi Angel,
> >
> > Looks good !
> >
> > I'm a little concerned with the default namespace strategy since I'm
> > not sure how it works in the following example:
> >
> > - Our client (Rampart) generates a request with standard prefixes such
> > as wsse, wst wsc etc.
> > - We define the xpath expression in the policy using those.
> > - Rampart client talks to a different service where it uses prefixes
> > s, t, and sc in the response.
> > - Now since those prefixes are not found in the message the xpath will
> > not select signed elements for validation.
> >
> > Thoughts?
> >
> > Thanks,
> > Ruchith
> >
> > On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > > Hi Ruchith & All,
> > >
> > > You can find the xpath support diffs here:
> > >
> > > https://issues.apache.org/jira/browse/RAMPART-40
> > >
> > > Currently the default strategy with respect to namespace prefixes is
> > > to get and register all defined namespaces in the message, so that the
> > > user can use *any* namespace prefix in the XPath expressions.
> > >
> > > An alternative which I have also developed is to use the method
> > > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > > namespaces.
> > >
> > > I hope the changes will be committed to rampart-1.2 and will benefit
> > > everyone -:) Thanks.
> > >
> > > Best Regards,
> > > Angel
> > >
> >
> >
> > --
> > www.ruchith.org
> > www.wso2.org
> >
>


-- 
www.ruchith.org
www.wso2.org

Re: XPath support completed

[Angel Todorov <at...@gmail.com>]

Hi Ruchith,

This is normally done by defining the Signed/Encrypted Elements on the
message level granularity. At least that's what many WS frameworks do,
such as WSIT. Then you can define different signed and encrypted
elements with different XPath expressions for the request and response
messages. I hope this is currently possible with rampart? At least I
have seen that one can apply different policies for each operation ,
and even message, in services.xml.

Regards,
Angel

On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> Hi Angel,
>
> Looks good !
>
> I'm a little concerned with the default namespace strategy since I'm
> not sure how it works in the following example:
>
> - Our client (Rampart) generates a request with standard prefixes such
> as wsse, wst wsc etc.
> - We define the xpath expression in the policy using those.
> - Rampart client talks to a different service where it uses prefixes
> s, t, and sc in the response.
> - Now since those prefixes are not found in the message the xpath will
> not select signed elements for validation.
>
> Thoughts?
>
> Thanks,
> Ruchith
>
> On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > Hi Ruchith & All,
> >
> > You can find the xpath support diffs here:
> >
> > https://issues.apache.org/jira/browse/RAMPART-40
> >
> > Currently the default strategy with respect to namespace prefixes is
> > to get and register all defined namespaces in the message, so that the
> > user can use *any* namespace prefix in the XPath expressions.
> >
> > An alternative which I have also developed is to use the method
> > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > namespaces.
> >
> > I hope the changes will be committed to rampart-1.2 and will benefit
> > everyone -:) Thanks.
> >
> > Best Regards,
> > Angel
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>

Re: XPath support completed

[Angel Todorov <at...@gmail.com>]

Hi again,

On the other hand, if you really don't know what namespaces and
prefixes you can expect from the other side, it is indeed hard to know
in advance and define this as an XPath expression. Maybe the two
parties could mutually agree in some way on the namespace prefixes
usage, otherwise, I see no other easy and standard way to do it.

Regards,
Angel

On 5/14/07, Ruchith Fernando <ru...@gmail.com> wrote:
> Hi Angel,
>
> Looks good !
>
> I'm a little concerned with the default namespace strategy since I'm
> not sure how it works in the following example:
>
> - Our client (Rampart) generates a request with standard prefixes such
> as wsse, wst wsc etc.
> - We define the xpath expression in the policy using those.
> - Rampart client talks to a different service where it uses prefixes
> s, t, and sc in the response.
> - Now since those prefixes are not found in the message the xpath will
> not select signed elements for validation.
>
> Thoughts?
>
> Thanks,
> Ruchith
>
> On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> > Hi Ruchith & All,
> >
> > You can find the xpath support diffs here:
> >
> > https://issues.apache.org/jira/browse/RAMPART-40
> >
> > Currently the default strategy with respect to namespace prefixes is
> > to get and register all defined namespaces in the message, so that the
> > user can use *any* namespace prefix in the XPath expressions.
> >
> > An alternative which I have also developed is to use the method
> > "findDefaultPrefixNamespaces" , which uses a predefined list of
> > namespaces.
> >
> > I hope the changes will be committed to rampart-1.2 and will benefit
> > everyone -:) Thanks.
> >
> > Best Regards,
> > Angel
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>

Re: XPath support completed

[Ruchith Fernando <ru...@gmail.com>]

Hi Angel,

Looks good !

I'm a little concerned with the default namespace strategy since I'm
not sure how it works in the following example:

- Our client (Rampart) generates a request with standard prefixes such
as wsse, wst wsc etc.
- We define the xpath expression in the policy using those.
- Rampart client talks to a different service where it uses prefixes
s, t, and sc in the response.
- Now since those prefixes are not found in the message the xpath will
not select signed elements for validation.

Thoughts?

Thanks,
Ruchith

On 5/14/07, Angel Todorov <at...@gmail.com> wrote:
> Hi Ruchith & All,
>
> You can find the xpath support diffs here:
>
> https://issues.apache.org/jira/browse/RAMPART-40
>
> Currently the default strategy with respect to namespace prefixes is
> to get and register all defined namespaces in the message, so that the
> user can use *any* namespace prefix in the XPath expressions.
>
> An alternative which I have also developed is to use the method
> "findDefaultPrefixNamespaces" , which uses a predefined list of
> namespaces.
>
> I hope the changes will be committed to rampart-1.2 and will benefit
> everyone -:) Thanks.
>
> Best Regards,
> Angel
>


-- 
www.ruchith.org
www.wso2.org