Re: Unable to see SOAP headers while using UsernameToken assertion

[Giriraj Bhojak]

I forgot to mention that I am setting ws-security.username and
ws-security.password programmatically onto BindingProvider.

Thanks,
Giriraj
On Feb 24, 2016 11:07 PM, "Giriraj Bhojak"  wrote:

> Hi,
>
> I have been trying to use UsernameToken WS-SecurityPolicy assertion, but I
> do not see the SOAP headers in the payload.
> Hence I keep getting the following exception on the server side:
>
> org.apache.cxf.ws.policy.PolicyException: These policy alternatives can
> not be satisfied:
>
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}SupportingTokens
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}UsernameToken
>  at
> org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
> I am using CXF 2.7.11 and following are the relevant client side
> configurations.
>
> Spring config has following entries:
>
> 
>
> 
>
>
>
>
>
>
>
>  serviceClass="com.company.EndpointClassName"
>
>
>
> WSDL refers to policy as follows:
>
>
>   
>
>  sp:IncludeToken="
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
> ">
>
>
>
> 
>
> 
>   
> ….
>
>  
>
>
> ...
>
> The client has cxf-rt-ws-security and cxf-rt-ws-policy dependencies in the
> classpath.
>
> I am using cxf-codegen-plugin to generate the source classes using the
> WSDL. The serviceClass attribute of jaxws:client element above points to
> the generated endpoint interface.
>
> I am unable to get to the root cause of why SOAP headers are absent in the
> request, could someone please help me with it?
>
> Thanks,
> Giriraj.
>

Unable to see SOAP headers while using UsernameToken assertion

[Giriraj Bhojak]

Hi,

I have been trying to use UsernameToken WS-SecurityPolicy assertion, but I
do not see the SOAP headers in the payload.
Hence I keep getting the following exception on the server side:

org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not
be satisfied:

{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}SupportingTokens
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}UsernameToken
 at
org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
I am using CXF 2.7.11 and following are the relevant client side
configurations.

Spring config has following entries:





   

   

   

 

WSDL refers to policy as follows:

   
  

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">

   
   



  
….

 
   

...

The client has cxf-rt-ws-security and cxf-rt-ws-policy dependencies in the
classpath.

I am using cxf-codegen-plugin to generate the source classes using the
WSDL. The serviceClass attribute of jaxws:client element above points to
the generated endpoint interface.

I am unable to get to the root cause of why SOAP headers are absent in the
request, could someone please help me with it?

Thanks,
Giriraj.

Re: JAX-RS CookieHeaderProvider with httpOnly cookie doesn't work

[Sergey Beryozkin]

Hi

Yes, you send a NewCookie but attempt to read it later on as Cookie.
You should use NewCookie.valueOf(newCookieValue) to recreate it.

Can you please use one of Cookie constructors to convert NewCookie to 
Cookie ?


Or simply take the relevant value from this new cookie and send the name 
and value only which is what is expected really by the Cookie receiver.


Sergey
On 24/02/16 17:58, cc75005++ wrote:

Sorry, now I understand your question.. please find,I think, the bad code
that I use to create a new webclient to make the request :




Thanks for your time





--
View this message in context: 
http://cxf.547215.n5.nabble.com/JAX-RS-CookieHeaderProvider-with-httpOnly-cookie-doesn-t-work-tp5766083p5766290.html
Sent from the cxf-user mailing list archive at Nabble.com.




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: No support for FailoverFeature in CXF Rest Client implementation (version 3.1.0)

[Sergey Beryozkin]

Hi

Please create a CXF JIRA issue, not sure how to qualify it, 'Task' I 
guess. As I said though it is unlikely to be addressed in the short term 
unless one of colleagues or yourself will look at it.


Cheers, Sergey

On 24/02/16 16:36, ranadeep.sha...@gmail.com wrote:

Hi Sergey,

Thanks for the reply.

Is there any place where I can raise a request for this feature
implementation ?
That way, I believe all CXF consumers including myself can keep a track of
it.

Regards,
Ranadeep.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/No-support-for-FailoverFeature-in-CXF-Rest-Client-implementation-version-3-1-0-tp5765813p5766277.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: JAX-RS CookieHeaderProvider with httpOnly cookie doesn't work

[cc75005++]

Sorry, now I understand your question.. please find,I think, the bad code
that I use to create a new webclient to make the request :




Thanks for your time





--
View this message in context: 
http://cxf.547215.n5.nabble.com/JAX-RS-CookieHeaderProvider-with-httpOnly-cookie-doesn-t-work-tp5766083p5766290.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: No support for FailoverFeature in CXF Rest Client implementation (version 3.1.0)

[ranadeep.sha...@gmail.com]

Hi Sergey,

Thanks for the reply. 

Is there any place where I can raise a request for this feature
implementation ?
That way, I believe all CXF consumers including myself can keep a track of
it.

Regards,
Ranadeep.



--
View this message in context: 
http://cxf.547215.n5.nabble.com/No-support-for-FailoverFeature-in-CXF-Rest-Client-implementation-version-3-1-0-tp5765813p5766277.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: Proxy-based API genaration (two or more interaces)

[Sergey Beryozkin]

Hi
On 24/02/16 13:42, Vjacheslav V. Borisov wrote:

Hi!

Currently it is possible to write server side resource implementing two
interfaces at the same time

Eg,.

public class SomeResource implements OneResourceInterface,
TwoResourceInterface

does it possible to generate Proxy-based client based on more that one
interface?

http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI

Currently I am see only possibility to generate two ProxyBased client
interfaces an combine them in client side?

  in class like
public class SomeResourceClient implements OneResourceInterface,
TwoResourceInterface

Yes, this is how it can be done, please make sure cglib-nodep dependency 
is on the classpath


Cheers, Sergey

--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Proxy-based API genaration (two or more interaces)

[Vjacheslav V. Borisov]

Hi!

Currently it is possible to write server side resource implementing two
interfaces at the same time

Eg,.

public class SomeResource implements OneResourceInterface,
TwoResourceInterface

does it possible to generate Proxy-based client based on more that one
interface?

http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI

Currently I am see only possibility to generate two ProxyBased client
interfaces an combine them in client side?

 in class like
public class SomeResourceClient implements OneResourceInterface,
TwoResourceInterface

Re: [cxf-fediz] advanced IDP federation of multiple realms possible?

[Colm O hEigeartaigh]

Hi Ingo,

I think it should be feasible to get this scenario working in Fediz.
However, the only way I can see it working is if the IDP-A at least knows
to send requests for REALM-C to IDP-B for validation, passing through the
home realm. Actually I just reviewed the code, and the WS-Federation
protocol handler in the IdP doesn't send the realm of the configured
TrustedIdp bean as the "whr" / home-realm parameter to the remote IdP. So
I've just merged a fix for this.

Colm.

On Fri, Feb 19, 2016 at 4:43 PM, Ingo  wrote:

> Dear list,
>
> Federation of IDPs in multiple realms (realm-a, realm-b) is shown in the
> 'simpleWebapp' example of fediz.
> Basically the trust-relations in this example are like this:
>
> - RP-service trusts IDP/STS of Realm-A (operated within the same
> security realm)
> - IDP/STS-A trusts IDP/STS-B
>
> Extending the example with another IDP/STS of let's say Realm-C is straight
> forward in such way, that HRDS offers 3 choices (Realm-A, Realm-B,
> Realm-C).
> However, the resulting trust relation is IDP/STS-A has two trusted IDP's (B
> and C). It is unclear if and how another setting of trust relations can be
> realized, where A and C have no direct trust relation but instead B takes
> the role of a trust-broker. So this is the targeted scenario:
>
> - IDP/STS-A and RP-Service are situated in the same security domain
> (realm).
> - IDP/STS-B is a trusted IDP of A
> - IDP/STS-C is a trusted IDP of B and not known by IDP/STS-A
> - IDP/STS-B acts as a broker (eventually doing claims mapping) between
> Realm-C and Realm-A
>
> Does anyone know if this setup is feasible with fediz?
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/cxf-fediz-advanced-IDP-federation-of-multiple-realms-possible-tp5766065.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: No support for FailoverFeature in CXF Rest Client implementation (version 3.1.0)

[Sergey Beryozkin]

Hi Ranadeep,

On 24/02/16 01:35, ranadeep.sha...@gmail.com wrote:

Hi Sergey,

Thanks for the response. We have a requirement where we are planning to
preserve the usage of standard API going forward so that the functionality
is not impacted, no matter what the underlying implementation is.
I have some follow-up questions, below.

1) Is there any roadmap of releasing a future version of CXF Clustering
with full support for JAX-RS 2.0 API including the Failover retry features.
If so, when can we expect that to happen?


No specific work is being planned, but I suppose that can be done 
eventually.



2) Is the CXF implementation of Failover Retry (for both SOAP client and
REST client) thread-safe?


I haven't seen any thread-safety related issues reported so far

Cheers, Sergey


Regards,
Ranadeep.

Regards,
Ranadeep.

On Wed, Feb 10, 2016 at 5:42 PM, Sergey Beryozkin [via CXF] <
ml-node+s547215n5765816...@n5.nabble.com> wrote:


JAX-RS 2.0 API does not work with a CXF specific failover feature,
definitely not something I've had a chance to look into.
We'd need to create a JAX-RS 2.0 Feature wrapper but what is the point
of such a JAX-RS Feature can not be portable.

Consider using WebClient with FailoverFeature.

Sergey


On 10/02/16 21:57, [hidden email]
 wrote:


I had tried some heavy exploration on enabling Failover feature, as per
documentation provided by Apache CXF. While the one for SOAP client

works

like a charm, the other one for REST client is not so with the way I am
trying to instantiate the client. My requirement of instantiating the

REST

client is via JAXRS 2.0.1 API, as shown in following sample code.NOTE :

The

following endpoint URL is a valid one, except that the port number has

been

switched from 8080 (working one) to 8081 (non-working one), since I need

to

simulate the invocation failure retry behavior.Client client =
ClientBuilder.newClient(); WebTarget target =
client.target("http://localhost:8081/my-app/ws/ers/customers";);
Invocation.Builder builder =
target.request(MediaType.APPLICATION_JSON_TYPE); Response response =
builder.get();I have found that the Failover feature is not working when

the

above last line of code is invoked.Now, here comes the interesting part.

I

have found only 2 classes in cxf-rt-rs-client-3.1.0-sources.jar where

the

initialization of Failover feature in a
org.apache.cxf.jaxrs.client.JAXRSClientFactoryBean instance happens. And

my

requirement is to have one of these methods (or, a similar one where
bean.setFeatures(features) is invoked ) being called.Method in
org.apache.cxf.jaxrs.client.JAXRSClientFactory class.public static  T
create(String baseAddress,Class cls, List
providers,   List features,
String configLocation) {JAXRSClientFactoryBean bean =
getBean(baseAddress, cls, configLocation);

  bean.setProviders(providers);

bean.setFeatures(features);return bean.create(cls);}Method in
org.apache.cxf.jaxrs.client.WebClient class.public static WebClient
create(String baseAddress,List providers,
List features,   String
configLocation) {JAXRSClientFactoryBean bean = getBean(baseAddress,
configLocation);bean.setProviders(providers);
bean.setFeatures(features);return bean.createWebClient();}However,

when

my custom client code above is executed, neither of the above 2 methods

have

been invoked. Instead, the following method in
org.apache.cxf.jaxrs.client.spec.ClientImpl is invoked.private void
initTargetClientIfNeeded() {URI uri = this.uriBuilder.build(new
Object[0]);if(this.targetClient == null) {

  JAXRSClientFactoryBean

bean = new JAXRSClientFactoryBean();

  bean.setAddress(uri.toString());

this.targetClient = bean.createWebClient();
ClientImpl.this.baseClients.add(this.targetClient);} else
if(!this.targetClient.getCurrentURI().equals(uri)) {
this.targetClient.to(uri.toString(), false);} }Does this imply that
Failover Feature is NOT supported for CXF version 3.1.0 ?If so, which
upcoming version of CXF will support my above requirement ?



--
View this message in context:

http://cxf.547215.n5.nabble.com/No-support-for-FailoverFeature-in-CXF-Rest-Client-implementation-version-3-1-0-tp5765813.html

Sent from the cxf-user mailing list archive at Nabble.com.




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/


--
If you reply to this email, your message will be added to the discussion
below:

http://cxf.547215.n5.nabble.com/No-support-for-FailoverFeature-in-CXF-Rest-Client-implementation-version-3-1-0-tp5765813p5765816.html
To unsubscribe from No support for FailoverFeature in CXF Rest Client
implementation (version 3.1.0), click here

.
N

Re: NullPointerException in OAuthRequestFilter

[Sergey Beryozkin]

Hi

Thanks for being so appreciative, but I'm only trying to provide 
whatever info I can, we work with all the users this way :-)


I honestly do not know where are you getting these dependencies from. 
And if you wish to run your application in Glassfish you do not have to 
start going the embedded Jetty route, simply create a war, and in 
web.xml - declare CXFNonSpringJaxrsServlet and register your custom 
JAX-RS Application with it, something like this:


https://github.com/apache/cxf/blob/master/systests/jaxrs/src/test/resources/jaxrs_non_spring/WEB-INF/web.xml#L122

HTH, Sergey
On 24/02/16 01:04, LaVloZ . wrote:

Hii,
Thank you again for your time, i tried to use JAXRSServerFactoryBean to
create a new JAX-RS server so i added it Jetty transport jar to my maven,
but CXF seems to need Google Guava and Glassfish HK2, so i got some
exceptions in the first time until i added manualy Guava and HK2 in maven,
why CXF doesn't declare these two dependencies althought it need them?

Thank you again and again, very nice from you for the support :)

2016-02-23 19:13 GMT+01:00 Sergey Beryozkin :


Hi, in most cases you'd like to configure it somehow, so may be try to
create JAX-RS Applications where it is all configured in the code and
register these applications with CXFNonSpringJaxrsServlet

Sergey

On 23/02/16 18:08, LaVloZ . wrote:


Hi,
Thank you for your time :), i have a little question, i see that the doc
uses Spring, can we use CXF and OAuth implementation totaly without
Spring?? :)

Thanks

2016-02-23 10:33 GMT+01:00 Sergey Beryozkin :

Hi,

well, Jersey is of course a quality JAX-RS RI, but indeed, given its
close
integration with Glassfish, those users who may want to run CXF JAX-RS
with
Glassfish will need to experiment and try to disable Jersey somehow :-)

Sergey

On 22/02/16 22:04, LaVloZ . wrote:

I didn't recieve an anwser mail for my original question so i resent the

same question, then i saw your answer in my SO :)
And as you said, Jersey is the problem, you have saved us alots of time.

Thank you so much :)

2016-02-22 18:35 GMT+01:00 Sergey Beryozkin :

Hi


I replied to your original question a week or so ago, can you please
check
it ?

Jersey is loaded is there so I think you may need to disable it somehow

Thanks, Sergey

On 22/02/16 17:24, LaVloZ . wrote:

Hello all



i have more than one week tryign to figure out the problem, but i
didn't
find it, googling, stackoverflow ..., but nothing.

The problem is that the web services work fine but when i add the jar
for
OAuth support using Maven i get NullPointerException raised inside
OAuthRequestFilter :

this is the link of the line on GitHub :




https://github.com/apache/cxf/blob/7d1890510a85d4fd7e70faebc56d6685f103621d/rt/rs/security/oauth-parent/oauth2/src/main/java/org/apache/cxf/rs/security/oauth2/filters/OAuthRequestFilter.java#L82

That JAXRSUtils.getCurrentMessage() returns null reference so that
null
cuz
a NullPointerException latter in code.

i'm using CXF 3.1.5 and tried it on Glassfish 4.1.1 and TomEE 7.0.63
on
Oracle JDK 1.8.0_66

Thank you all.



--

Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/











--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/