[jira] [Assigned] (CXF-7086) Dynamically load signature validation keys using KeyName
[ https://issues.apache.org/jira/browse/CXF-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7086: Assignee: Colm O hEigeartaigh > Dynamically load signature validation keys using KeyName > > > Key: CXF-7086 > URL: https://issues.apache.org/jira/browse/CXF-7086 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Assignee: Colm O hEigeartaigh >Priority: Minor > > The current implementation of handling incoming messages with a KeyName > identifier is to rely on a single "default" key. The SignatureValidationKey. > However it is possible to have multiple different KeyNames and the expected > behaviour is to select the right certificate based on the KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7086) Dynamically load signature validation keys using KeyName
[ https://issues.apache.org/jira/browse/CXF-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568109#comment-15568109 ] Colm O hEigeartaigh commented on CXF-7086: -- Revisit when we pick up Santuario 2.0.8. > Dynamically load signature validation keys using KeyName > > > Key: CXF-7086 > URL: https://issues.apache.org/jira/browse/CXF-7086 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Hugo Trippaers >Assignee: Colm O hEigeartaigh >Priority: Minor > > The current implementation of handling incoming messages with a KeyName > identifier is to rely on a single "default" key. The SignatureValidationKey. > However it is possible to have multiple different KeyNames and the expected > behaviour is to select the right certificate based on the KeyName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[
https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549928#comment-15549928
]
Sergey Beryozkin edited comment on CXF-7075 at 10/12/16 10:53 AM:
--
Interestingly, when I bump up the TIMES_TO_RUN from 500k to 1 million, then the
proposed fix looks a bit slower:
Original Code Test
Time to parse one type: 146873609 nanoseconds
Time to parse two types: 119980999 nanoseconds
Time to parse three types: 158751189 nanoseconds
Time to parse twelve types: 792077205 nanoseconds
Proposed Change Test
Time to parse one type: 166478348 nanoseconds
Time to parse two types: 135731365 nanoseconds
Time to parse three types: 163320358 nanoseconds
Time to parse twelve types: 758674187 nanoseconds
Original Code Test
Time to parse one type: 157246321 nanoseconds
Time to parse two types: 129763922 nanoseconds
Time to parse three types: 164354449 nanoseconds
Time to parse twelve types: 840647904 nanoseconds
Proposed Change Test
Time to parse one type: 162607531 nanoseconds
Time to parse two types: 123097493 nanoseconds
Time to parse three types: 165173994 nanoseconds
Time to parse twelve types: 768583383 nanoseconds
Original Code Test
Time to parse one type: 143968053 nanoseconds
Time to parse two types: 133924033 nanoseconds
Time to parse three types: 161509309 nanoseconds
Time to parse twelve types: 809422872 nanoseconds
Proposed Change Test
Time to parse one type: 157101703 nanoseconds
Time to parse two types: 135634786 nanoseconds
Time to parse three types: 158294707 nanoseconds
Time to parse twelve types: 781427304 nanoseconds
I tried re-implementing another way which looks like it might be a little
faster...
{code:java}
public static List parseMediaTypes(String types) {
List acceptValues = new ArrayList();
if (types != null) {
int x = 0;
int y = types.indexOf(',');
while (y > 0) {
acceptValues.add(toMediaType(types.substring(x, y)));
x = y + 2;
y = types.indexOf(',', x);
}
acceptValues.add(toMediaType(types.substring(x)));
} else {
acceptValues.add(ALL_TYPES);
}
return acceptValues;
}
{code}
With that code, I get these results (new code is labeled as Proposed):
Original Code Test
Time to parse one type: 162089550 nanoseconds
Time to parse two types: 121634212 nanoseconds
Time to parse three types: 164150901 nanoseconds
Time to parse twelve types: 1027082012 nanoseconds
Proposed Change Test
Time to parse one type: 147992281 nanoseconds
Time to parse two types: 118361681 nanoseconds
Time to parse three types: 154465943 nanoseconds
Time to parse twelve types: 744372633 nanoseconds
Original Code Test
Time to parse one type: 171457432 nanoseconds
Time to parse two types: 123348169 nanoseconds
Time to parse three types: 163685283 nanoseconds
Time to parse twelve types: 759016041 nanoseconds
Proposed Change Test
Time to parse one type: 147617428 nanoseconds
Time to parse two types: 118008933 nanoseconds
Time to parse three types: 153649110 nanoseconds
Time to parse twelve types: 756229153 nanoseconds
Original Code Test
Time to parse one type: 151245814 nanoseconds
Time to parse two types: 122917357 nanoseconds
Time to parse three types: 159188030 nanoseconds
Time to parse twelve types: 843513510 nanoseconds
Proposed Change Test
Time to parse one type: 145248903 nanoseconds
Time to parse two types: 118914505 nanoseconds
Time to parse three types: 155509909 nanoseconds
Time to parse twelve types: 767379270 nanoseconds
I haven't run this change on the simple JAX-RS benchmark, but I can do that --
I'll be on vacation the next couple of days, so I may not have results until
next week.
Thanks, Andy
was (Author: andymc):
Interestingly, when I bump up the TIMES_TO_RUN from 500k to 1 million, then the
proposed fix looks a bit slower:
Original Code Test
Time to parse one type: 146873609 nanoseconds
Time to parse two types: 119980999 nanoseconds
Time to parse three types: 158751189 nanoseconds
Time to parse twelve types: 792077205 nanoseconds
Proposed Change Test
Time to parse one type: 166478348 nanoseconds
Time to parse two types: 135731365 nanoseconds
Time to parse three types: 163320358 nanoseconds
Time to parse twelve types: 758674187 nanoseconds
Original Code Test
Time to parse one type: 157246321 nanoseconds
Time to parse two types: 129763922 nanoseconds
Time to parse three types: 164354449 nanoseconds
Time to parse twelve types: 840647904 nanoseconds
Proposed Change Test
Time to parse one type: 162607531 nanoseconds
Time to parse two types: 123097493 nanoseconds
Time to parse three types: 165173994 nanoseconds
Time to parse twelve types: 768583383 nanoseconds
Original Code Test
Time to parse one type: 143968053 nanoseconds
Time to parse two types: 133924033 nanoseconds
Time to parse
[jira] [Resolved] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7075. --- Resolution: Fixed > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > Attachments: JAXRSUtils-parseMediaType-perfTest.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7075) Remove unnecessary string.length() and map.containsKey(...) calls to improve performance
[ https://issues.apache.org/jira/browse/CXF-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15568731#comment-15568731 ] Sergey Beryozkin commented on CXF-7075: --- Hi Andy I've applied the code highlighted here: https://issues.apache.org/jira/browse/CXF-7075?focusedCommentId=15549928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15549928 with the minor modifications - some tests were failing: if media types had no spaces between them hence trim() was also required, or if the string had a trailing ',' - which I believe can happen sometimes with Accept). Thanks, Sergey > Remove unnecessary string.length() and map.containsKey(...) calls to improve > performance > > > Key: CXF-7075 > URL: https://issues.apache.org/jira/browse/CXF-7075 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.7 >Reporter: Andy McCright >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > Attachments: JAXRSUtils-parseMediaType-perfTest.zip > > Original Estimate: 24h > Remaining Estimate: 24h > > Using a simple (echo) JAX-RS benchmark, we've found a few hot spots around > string.length() and map.containsKey(...) calls that could be optimized. > Initial testing with the proposed changes yielded about a 2-3% improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[ https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6798. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.0.10 3.1.7 3.2.0 > JAXRS 2.0 Clients do not support ParamConverters > > > Key: CXF-6798 > URL: https://issues.apache.org/jira/browse/CXF-6798 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.7, 3.0.10 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[ https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569058#comment-15569058 ] Sergey Beryozkin commented on CXF-6798: --- I've just added a test, http://git-wip-us.apache.org/repos/asf/cxf/commit/9a46a89c Looks like it was fixed for 3.1.7 Thanks > JAXRS 2.0 Clients do not support ParamConverters > > > Key: CXF-6798 > URL: https://issues.apache.org/jira/browse/CXF-6798 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7070) HTTP headers logged in debug
[
https://issues.apache.org/jira/browse/CXF-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569098#comment-15569098
]
ASF GitHub Bot commented on CXF-7070:
-
GitHub user andymc12 opened a pull request:
https://github.com/apache/cxf/pull/178
CXF-7070 - Avoid logging sensitive headers
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andymc12/cxf headers
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/178.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #178
> HTTP headers logged in debug
>
>
> Key: CXF-7070
> URL: https://issues.apache.org/jira/browse/CXF-7070
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Reporter: Fadi Mohsen
>
> We try to avoid logging of authorization header value in out/in requests, we
> filtered out these in interceptors, but turns out these are logged anyway in
> [CXF debug mode|
> https://github.com/apache/cxf/blob/120d20f47022a76970ff0fb9c9d7413cfe019eb2/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Headers.java#L436]:
> {code}
> if (LOG.isLoggable(Level.FINE)) {
> LOG.log(Level.FINE, "Request Headers: " + headers.toString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7046) java.lang.ArrayIndexOutOfBoundsException: 1 AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)
[
https://issues.apache.org/jira/browse/CXF-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569271#comment-15569271
]
Andy McCright commented on CXF-7046:
It looks like this issue may have been resolved by CXF-6492 which was released
in 3.0.9 and 3.1.6. The affected versions shows 3.1.7, but if that is the
case, the stack trace is no longer accurate. Can you try running this test on
3.1.7 to see if the problem still occurs? If so, can you post the updated
stack trace?
Thanks, Andy
> java.lang.ArrayIndexOutOfBoundsException: 1
> AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)
> ---
>
> Key: CXF-7046
> URL: https://issues.apache.org/jira/browse/CXF-7046
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.17, 3.1.7
>Reporter: Ranjeeth
>
> When the authorization header is basic and does not contain userinfo cxf
> thorws exception
> example header authorization header [ Authorization:Basic ]
> {code:title=ArrayIndexOutOfBoundsException: 1|borderStyle=solid}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.getAuthorizationPolicyFromMessage(AbstractHTTPDestination.java:161)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.setupMessage(AbstractHTTPDestination.java:349)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:222)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:218)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:163)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:137)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:158)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:243)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:168)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:219)
> at
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl$LegacyServlet.service(HttpServiceRuntimeImpl.java:1271)
> at
> org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:162)
> at
> org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:63)
> at
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:413)
> at
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:358)
> at
> org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl.doDispatch(HttpServiceRuntimeImpl.java:204)
> at
> org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.processAlias(ProxyServlet.java:91)
> at
> org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.service(ProxyServlet.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:816)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1121)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1055)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:118)
> at org.eclipse.jetty.server.Server.handle(Server.java:515)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:291)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.ja
[jira] [Commented] (CXF-6798) JAXRS 2.0 Clients do not support ParamConverters
[
https://issues.apache.org/jira/browse/CXF-6798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569681#comment-15569681
]
Andrei Ivanov commented on CXF-6798:
Seemed weird to still have missing functionalities for 2.0 after all this time
:)
But I've learned about {{ParamConverter}} only recently, when trying to use a
Joda DateTime as param and I didn't understand how this doesn't work in 2016 :-/
I actually thought the {{jackson-datatype-joda}} module would take care of the
conversion, but it seems I just misunderstood how these things work.
Maybe CXF should provide some {{ParamConverters}} for usual types, like dates
(both Joda and JSR 310)?
> JAXRS 2.0 Clients do not support ParamConverters
>
>
> Key: CXF-6798
> URL: https://issues.apache.org/jira/browse/CXF-6798
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7041) Observed Memory leak under high traffic condition while using Apache CXF libraries SSL communication
[ https://issues.apache.org/jira/browse/CXF-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569904#comment-15569904 ] Andy McCright commented on CXF-7041: Would it be possible for you to provide an example that could be used to reproduce the issue? If not, could you provide heap dumps after you have reproduced the problem? Thanks, Andy > Observed Memory leak under high traffic condition while using Apache CXF > libraries SSL communication > > > Key: CXF-7041 > URL: https://issues.apache.org/jira/browse/CXF-7041 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.1.2 > Environment: Machine : SunOS lava 5.10 Generic_137137-09 sun4v sparc > SUNW,Sun-Fire-T200 >Reporter: Savita >Priority: Critical > Labels: patch, security > Original Estimate: 72h > Remaining Estimate: 72h > > We are using Apache CXF libraries for SSL client implementation in a Spring > based application. The client behavior is not stable. We are observing 2 > issue: > a) When the load is increased to 20-25 TPS the application processing time > increases by 2-3 time. > b) We are experiencing memory leak. Basically the memory consumption is not > going down. In the heap dump, we could see lot of Apache CXF Objects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6981) Getting "java.io.IOException: stream is closed" for > 64K messages
[ https://issues.apache.org/jira/browse/CXF-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569944#comment-15569944 ] ASF GitHub Bot commented on CXF-6981: - GitHub user andymc12 opened a pull request: https://github.com/apache/cxf/pull/179 CXF-6981 Avoid double close in CacheAndWriteOutputStream You can merge this pull request into a Git repository by running: $ git pull https://github.com/andymc12/cxf postClose Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cxf/pull/179.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #179 commit 25aa09fe52180beb183bae3cdc18d7eb9f6807cb Author: Andy McCright Date: 2016-10-03T16:30:24Z Merge pull request #1 from apache/master updating to master commit 6e5efebdff68804a4fc4faf39d4b116aa0444efe Author: Andy McCright Date: 2016-10-12T14:39:13Z Merge pull request #2 from apache/master update to latest commit 192ab806ee18e355f052b327918c84d60e71faf1 Author: andymc12 Date: 2016-10-12T21:43:52Z CXF-6981 - Avoid double close on CacheAndWriteOutputStream > Getting "java.io.IOException: stream is closed" for > 64K messages > -- > > Key: CXF-6981 > URL: https://issues.apache.org/jira/browse/CXF-6981 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.0.9 > Environment: JRE 1.8.0_101-b13 >Reporter: Michal Sabo > > I am getting an IOException (stream is closed) when CachedOutputStream is > trying to close the very same stream twice. For the first time it is closed > when maybeDeleteTempFile(currentStream) method is called, the second time > during postClose(), both as part of the close() method in CachedOutputStream. > java.io.IOException: stream is closed > at > sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.ensureOpen(HttpURLConnection.java:3309) > at > sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3314) > at org.apache.cxf.helpers.IOUtils.consume(IOUtils.java:363) > at > org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.closeInputStream(URLConnectionHTTPConduit.java:327) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1628) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1551) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1348) > at > org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:56) > at > org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:215) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:651) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) > at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:516) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:425) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:326) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:279) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:138) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7070) HTTP headers logged in debug
[
https://issues.apache.org/jira/browse/CXF-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569949#comment-15569949
]
S V Mohana Rao commented on CXF-7070:
-
But with respective security is it okay to pass sensitive data through header?
> HTTP headers logged in debug
>
>
> Key: CXF-7070
> URL: https://issues.apache.org/jira/browse/CXF-7070
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Reporter: Fadi Mohsen
>
> We try to avoid logging of authorization header value in out/in requests, we
> filtered out these in interceptors, but turns out these are logged anyway in
> [CXF debug mode|
> https://github.com/apache/cxf/blob/120d20f47022a76970ff0fb9c9d7413cfe019eb2/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Headers.java#L436]:
> {code}
> if (LOG.isLoggable(Level.FINE)) {
> LOG.log(Level.FINE, "Request Headers: " + headers.toString());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
