[GitHub] [cxf] JohnMTu commented on pull request #1150: add option to configure externally supplied implementation for sensitive data masking

2023-06-28 Thread via GitHub


JohnMTu commented on PR #1150:
URL: https://github.com/apache/cxf/pull/1150#issuecomment-1610970541

   hello,
   
   @reta: so far i removed "final" from maskSensitiveHelper field and added 
setters. Hence subclasses can be passed.
   
   In next step i tried to extract interface. Here I realized there is some 
inconsistency, as configuration used for hiding data is in once case on 
Interceptor 
org.apache.cxf.ext.logging.AbstractLoggingInterceptor#sensitiveProtocolHeaderNames
 while in other case it's near to implementation in 
org.apache.cxf.ext.logging.DefaultMaskSensitiveHelper#replacementsJSON (and 
replacementsXML).
   
   Best would be to cleanup it and keep it next to implementation, but 
unfortunately that would mean to change to some public methods, e.g. 
   
org.apache.cxf.ext.logging.event.DefaultLogEventMapper#map(org.apache.cxf.message.Message,
 java.util.Set) would not need 2nd argument anymore.
   And also org.apache.cxf.ext.logging.MaskSensitiveHelper#maskHeaders would 
not need it.
   
   Anyway, i'm not sure, if even change MaskSensitiveHelper to from class to 
interface is allowed in terms of backward compatibility. Please give me some 
hints, 
   
   So here is my attempt:
   
https://github.com/JohnMTu/cxf/compare/3.5.x-fixes...JohnMTu:cxf:CXF-8831_extract_interface?expand=1
   
   Unfortunately github doesn't show rename of MaskSensitiveHelper to 
DefaultMaskSensitiveHelper and instead shows diff against extracted interface 
.. but when checking commit by commit, rename is visible. Not sure how it would 
look like, if squash would be used.
   
   Please check. 
   Thanks you.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Final Reminder: Community Over Code call for presentations closing soon

2023-06-28 Thread Rich Bowen
[Note: You're receiving this email because you are subscribed to one or
more project dev@ mailing lists at the Apache Software Foundation.]

This is your final reminder that the Call for Presentations for
Community Over Code (formerly known as ApacheCon) is closing soon - on
Thursday, 13 July 2023 at 23:59:59 GMT.

https://communityovercode.org/call-for-presentations/

We are looking for talk proposals on all topics related to ASF projects
and open source software.

The event will be held in Halifax, Nova Scotia, Octiber 7th through
10th. More details about the event may be found on the event website at
https://communityovercode.org/

Rich, for the event planners


Re: Apache CXF JAX-RS threadsafe clients

2023-06-28 Thread Andriy Redko
Hi Jean,

So the 1st part is 100% correct way to create a thread safe client proxy, but 
with the 2nd one
we have an issue well documented here [1]. Since you only modify headers, the 
thread safe proxy 
should work, but you probably could avoid using the WebClient part (just use 
JAXRSClientFactoryBean)
directly:

   final JAXRSClientFactoryBean factory = new JAXRSClientFactoryBean();
   factory.setServiceClass(SodexoApi.class);
   factory.setProviders(providers);
   factory.getOutInterceptors().add(new LoggingOutInterceptor());
   factory.getInInterceptors().add(new LoggingInInterceptor());
   factory.setThreadSafe(true)

   SodexoApi api = factory.create(SodexoApi.class);
   ClientConfiguration config = WebClient.getConfig(api);
   addTLSClientParameters(config.getHttpConduit());


Hope it helps!

[1] 
https://cxf.apache.org/docs/jax-rs-client-api.html#JAXRSClientAPI-ThreadSafety

 
Best Regards,
Andriy Redko


JPU>  Apache CXF JAX-RS threadsafe clients

JPU> Hi Andriy,

JPU> I am struggling to understand threadsafety when creating/using JAX-RS
JPU> clients.

JPU> My intention is to:

JPU> 1.  Create a client once as I think it is heavy loaded:

JPU> o   We need to add providers and interceptors

JPU> o   We need to set TLS-client parameters

JPU> 2.  Then (re-)use this client in a threadsafe way for multiple
JPU> (possibly concurrent) invocations of service methods

JPU> So step ‘1.’ I have done by creating a static  threadsafe proxy using the
JPU> JAXRSClientFactory class.

JPU> Now the problem is step ‘2.’ How do I invoke this (static) client to make
JPU> sure that:

JPU> ·   Stuff under’1.’ is reused

JPU> ·   Reset and add headers specific for this invocation

JPU> ·   all is threadsafe

JPU> Currently, in my service method I create a client as follows:

JPU> SodexoApi* clientProxy* = 
JAXRSClientFactory.*fromClient*(WebClient.*client*
JPU> (*getClientProxy*()), SodexoApi.*class*);

JPU> Here getClientProxy() is the static proxy I created, covering for step ‘1.’
JPU> Stuff, that I want to re-use to create a proxy for the SodexoApi interface.

JPU> But I am doubting whether this is the correct way.

JPU> For the moment I don’t think I’ve a problem due to the fact that the
JPU> service methods are defined as ‘synchronized’ but that comes with a
JPU> performance penalty.

JPU> Below, a stripped version of the code I am using, to help you understanding
JPU> what I am trying to do:

JPU> public class SodexoApiClientImpl {

JPU> private static final Logger LOG =
JPU> Logger.getLogger(SodexoApiClientImpl.class);



JPU> /** custom HEADER field name for X-KMO-OPERATION-ID */

JPU> public static final String HEADER_OPERATION_ID =
JPU> "X-KMO-OPERATION-ID";

JPU> /** A threadsafe proxy to serve as {@link WebClient} for the {@link
JPU> SodexoApi} interface*/

JPU> private static SodexoApi clientProxy;

JPU> protected static synchronized SodexoApi getClientProxy() throws
JPU> GeneralSecurityException {

JPU> if (clientProxy == null) {

JPU> //Get the base address of the service endpoint

JPU> String baseAddress =
JPU> 
Configuration.getInstance().getItem(EmittentProperties.emmitent_service_endpoint);

JPU> clientProxy = getThreadsafeProxy(baseAddress);

JPU> }

JPU> return clientProxy;

JPU> }

JPU> /**

JPU>  * Create a proxy for the {@link SodexoApi} service endpoint

JPU>  *

JPU>  * @param baseAddress - The base URI of the SDX REST API endpoint.

JPU>  * @return The {@link SodexoApi} service endpoint proxy

JPU>  *

JPU>  * @throws GeneralSecurityException - when retrieving certificate
JPU> info fails

JPU>  */

JPU> private static SodexoApi getThreadsafeProxy(String baseAddress)
JPU> throws GeneralSecurityException {

JPU> JacksonJsonProvider provider = new JacksonJsonProvider(new
JPU> CustomObjectMapper());

JPU> List providers = new
JPU> ArrayList();

JPU> providers.add(provider);

JPU> SodexoApi api = JAXRSClientFactory.create(baseAddress,
JPU> SodexoApi.class, providers,true);

JPU> Client client = WebClient.client(api);

JPU> ClientConfiguration config = WebClient.getConfig(client);

JPU> config.getOutInterceptors().add(new
JPU> LoggingOutInterceptor());

JPU> config.getInInterceptors().add(new LoggingInInterceptor());

JPU> addTLSClientParameters(config.getHttpConduit());

JPU> return api;

JPU> }

JPU> /**

JPU>  * Add {@link TLSClientParameters} to the {@link HTTPConduit}.

JPU>  * In the Devoteam test environement the SSL certificates of
JPU> both KMOP and KmopEmittent

JPU>  * are self-signed with a CN not referring to their

RE: Apache CXF JAX-RS threadsafe clients

2023-06-28 Thread Jean Pierre URKENS
 RE: Apache CXF JAX-RS threadsafe clients

Hi Andriy,

Ok, it is clear for the 1st part, which I restructured to:

   * private** static* SodexoApi* getThreadsafeProxy*(String
baseAddress)* throws* GeneralSecurityException {

JacksonJsonProvider* provider* =* new* JacksonJsonProvider(
*new* CustomObjectMapper());

List* providers* =* new*
ArrayList();

providers.add(provider);



   * final* JAXRSClientFactoryBean* factory* =* new*
JAXRSClientFactoryBean();

factory.setAddress(baseAddress);

factory.setServiceClass(SodexoApi.*class*);

factory.setProviders(providers);

factory.getOutInterceptors().add(*new*
LoggingOutInterceptor());

factory.getInInterceptors().add(*new*
LoggingInInterceptor());

factory.setThreadSafe(*true*);

SodexoApi* api* = factory.create(SodexoApi.*class*);

ClientConfiguration* config* = WebClient.*getConfig*(api);

   * addTLSClientParameters*(config.getHttpConduit());

   * return* api;

}

You’re less clear on the 2nd part. If I look at the example
*http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSMultithreadedClientTest.java*

(especially the runproxies() method),

then in my service method (which I am trying to make threadsafe) I wouldn’t
need to call:

//Get a threadsafe API client

SodexoApi* clientProxy* = JAXRSClientFactory.*fromClient*
(WebClient.*client*(*getClientProxy*()), SodexoApi.*class*);

The* getClientProxy*() which returns a singleton instance from the*
getThreadsafeProxy*(…) method above is already threadsafe even though it is
the same proxy instance for all service invocations as state is kept in a*
ThreadLocalClientState* object.

So my service method could just look like (still need a casting to
WebClient to be able to set the authorization HTTP header):

   * public** synchronized* Response* closeAccount*(UUID operationId,
Long authorisationId, AccountKey accountKey) {

   * try* {

//Set the Bearer authorization header

String* issuer* = Configuration.*getInstance*
().getItem(EmittentProperties.*emit_security_bearer_issuer*);

String* audience* = Configuration.*getInstance*
().getItem(EmittentProperties.*emit_security_bearer_audience*);

String* jws* = BearerUtils.*createJwtSignedJose*
(BearerUtils.*SDX_HEADER_TYPE*,issuer,audience,
operationId.toString(),(PrivateKey) BearerUtils.*getKey*(KeyName.
*kmopSignPrivKey*));

WebClient.*client*(*getClientProxy*())

.reset()


.header(HttpHeaders.*AUTHORIZATION*, "Bearer
" + jws);

//Send service request

   * return**
getClientProxy*().closeAccount(operationId.toString(),
authorisationId, accountKey);

}* catch* (GeneralSecurityException* e*) {

StringBuilder* bldr* =* new* StringBuilder("Internal
error processing customerFund request (")

.append("operationId="
).append(operationId.toString())

.append(",authorisationId="
).append(authorisationId)

.append("): "
).append(e.getMessage());

   * LOG*.error(bldr.toString(), e);

   * return* Response.*status*(Status.
*INTERNAL_SERVER_ERROR*).entity(e.getMessage()).build();

}

}

Regards,

J.P.

-Original Message-
From: Andriy Redko 
Sent: woensdag 28 juni 2023 23:55
To: Jean Pierre URKENS ; CXF Dev List <
dev@cxf.apache.org>
Subject: Re: Apache CXF JAX-RS threadsafe clients

Hi Jean,

So the 1st part is 100% correct way to create a thread safe client proxy,
but with the 2nd one we have an issue well documented here [1]. Since you
only modify headers, the thread safe proxy should work, but you probably
could avoid using the WebClient part (just use JAXRSClientFactoryBean)

directly:

   final JAXRSClientFactoryBean factory = new JAXRSClientFactoryBean();

   factory.setServiceClass(SodexoApi.class);

   factory.setProviders(providers);

   factory.getOutInterceptors().add(new LoggingOutInterceptor());

   factory.getInInterceptors().add(new LoggingInInterceptor());

   factory.setThreadSafe(true)

   SodexoApi api = factory.create(SodexoApi.class);

   ClientConfiguration config = WebClient.getConfig(api);

   addTLSClientParameters(config.getHttpConduit());

Hope it helps!

[1]
https://cxf.apache.org/docs/jax-rs-client-api.html#JAXRSClientAPI-ThreadSafety



Best Regards,

Andriy