[jira] [Commented] (CXF-4437) Stack Overflow exception in org.apache.cxf.endpoint.ClientImpl when logging set to FINE
[
https://issues.apache.org/jira/browse/CXF-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421271#comment-13421271
]
Aki Yoshida commented on CXF-4437:
--
Hi Jason,
that explains the reason. The request message contains the invocation context,
whereas the response message does not. So, the current code that copies the
response message properties into the response context should not create a
recursive reference. However, if the request message is directly used as the
response message, there will be a recursive reference.
So, if you are not using the request message directly as the response message,
this problem should not occur.
@Dan,
to be on the protected side, we should change the code to not put the
invocation context into the response context.
In addition, should we even get rid of this log line or log only the keys? I
don't know if it is okay to log the context properties from the security point
of view even if the level is set to FINEST.
regards, aki
> Stack Overflow exception in org.apache.cxf.endpoint.ClientImpl when logging
> set to FINE
> ---
>
> Key: CXF-4437
> URL: https://issues.apache.org/jira/browse/CXF-4437
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.6.1
> Environment: JDK 1.6.0_32
>Reporter: Jason Pell
> Fix For: 2.6.2
>
>
> Hi,
> I can reproduce the issue in our code, but will probably struggle to
> create a test case.
> I have narrowed down the culprit (in 2.6.1) to
> org.apache.cxf.endpoint.ClientImpl line 636
> The method protected Object[] processResult(Message message,
>Exchange exchange,
>BindingOperationInfo oi,
>Map resContext)
> throws Exception {
> And the code:
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("set responseContext to be" + resContext);
> }
> The code to add all the properties from the message to resContext, creates a
> recursive reference, because the message already has a reference to
> resContext. This causes the logging to fail as when it tries to serialise
> the content of the map, it gets a stack overflow.
> The org.apache.cxf.invocation.context contains the ResponseContext and
> the ResponseContext contains the org.apache.cxf.invocation.context
> To prove my hypothesis I added the following code to replace the log call:
> HashMap contextMap = (HashMap)
> resContext.get("org.apache.cxf.invocation.context");
> HashMap responseContextMap = (HashMap)
> contextMap.get("ResponseContext");
> HashMap secondContextMap = (HashMap)
> responseContextMap.get("org.apache.cxf.invocation.context");
> if (secondContextMap != null) {
> System.out.println("Oh boy here is the
> error!");
> }
> And I got the Oh boy here is the error! message back.
> The original stack trace is:
> java.lang.StackOverflowError
> at java.util.HashMap$EntrySet.iterator(HashMap.java:950)
> at java.util.AbstractMap.toString(AbstractMap.java:478)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2826)
> at java.lang.StringBuilder.append(StringBuilder.java:115)
> at java.util.AbstractMap.toString(AbstractMap.java:490)
> at java.lang.String.valueOf(String.java:2
[jira] [Commented] (CXF-4431) Add support for OAuth2 'mac' token type
[ https://issues.apache.org/jira/browse/CXF-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421504#comment-13421504 ] Sergey Beryozkin commented on CXF-4431: --- FYI, you've been working with the outdated draft, this one is the recent: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 I'm taking care of the relevant updates > Add support for OAuth2 'mac' token type > --- > > Key: CXF-4431 > URL: https://issues.apache.org/jira/browse/CXF-4431 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Sasi M > Fix For: 2.7.0 > > Attachments: mac_token_nonce_checking.txt, mac_token_support.txt > > > CXF currently supports only the Bearer token type. This token type is not > feasible for use without SSL. > OAuth2 specs out the 'mac' token type that requires request signing for > authentication using the access token. The spec is described here: > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4431) Add support for OAuth2 'mac' token type
[ https://issues.apache.org/jira/browse/CXF-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421518#comment-13421518 ] Sasi M commented on CXF-4431: - Actually this looks more recent: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05 > Add support for OAuth2 'mac' token type > --- > > Key: CXF-4431 > URL: https://issues.apache.org/jira/browse/CXF-4431 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Sasi M > Fix For: 2.7.0 > > Attachments: mac_token_nonce_checking.txt, mac_token_support.txt > > > CXF currently supports only the Bearer token type. This token type is not > feasible for use without SSL. > OAuth2 specs out the 'mac' token type that requires request signing for > authentication using the access token. The spec is described here: > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4431) Add support for OAuth2 'mac' token type
[ https://issues.apache.org/jira/browse/CXF-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421520#comment-13421520 ] Sergey Beryozkin commented on CXF-4431: --- Hi, here is the initial commit to the trunk: http://svn.apache.org/viewvc?rev=1365160&view=rev will merge it later to 2.6.x. Here are some comments on the modifications I did: - Made relevant updates to get the latest draft supported - I did quite a few refactorings, mainly to get all the Hmac and normalization work done in one or two places. - I did not introduce mac specific properties into ClientAccessToken - it needs to be able to manage not only bearer/mac, but other types too, it has the typed well-known properties all token share and then a map of parameters for keeping the token specific extensions - I've not added a NonceVerifier implementation yet, only the interface. I think the implementation is actually pretty advanced :-), which is good, but I guess we need to think a bit more about whether we should ship it with CXF or may be as part of the demo - may be we should get ECache-based store added, etc, need to think more - plus few other bits and pieces Hope you will won't be disappointed with the changes I did. Overall it's a very good contribution - thanks for the effort. Few more minor updates may need to be done, like the queries normalization, etc, but it's nearly there. As a side note - I'd like to review if we can get this Mac-specific code available to other OAuth projects once it settles down a bit, we can discuss it offline, I'll ping you here or please ping me later on. > Add support for OAuth2 'mac' token type > --- > > Key: CXF-4431 > URL: https://issues.apache.org/jira/browse/CXF-4431 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Sasi M > Fix For: 2.7.0 > > Attachments: mac_token_nonce_checking.txt, mac_token_support.txt > > > CXF currently supports only the Bearer token type. This token type is not > feasible for use without SSL. > OAuth2 specs out the 'mac' token type that requires request signing for > authentication using the access token. The spec is described here: > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4431) Add support for OAuth2 'mac' token type
[ https://issues.apache.org/jira/browse/CXF-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421531#comment-13421531 ] Sergey Beryozkin commented on CXF-4431: --- OK, I was working with the older draft :-) This latest one has still refers to "access_token", "secret" and "algorithm" props, with "access_token" being the mac key itself. However Authorization header uses an 'id' for the key, and 'mac' for the signature (which I recall seeing in your patch) but it also drops a 'timestamp' property, and uses an 'ext' one. The normalization algo is a bit different too I think, I'll take care of it. > Add support for OAuth2 'mac' token type > --- > > Key: CXF-4431 > URL: https://issues.apache.org/jira/browse/CXF-4431 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Sasi M > Fix For: 2.7.0 > > Attachments: mac_token_nonce_checking.txt, mac_token_support.txt > > > CXF currently supports only the Bearer token type. This token type is not > feasible for use without SSL. > OAuth2 specs out the 'mac' token type that requires request signing for > authentication using the access token. The spec is described here: > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4431) Add support for OAuth2 'mac' token type
[ https://issues.apache.org/jira/browse/CXF-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421856#comment-13421856 ] Sergey Beryozkin commented on CXF-4431: --- Here is an update to get aligned closer to the v5 draft: http://svn.apache.org/viewvc?rev=1365332&view=rev. Will merge to 2.6.2-SNAPSHOT tomorrow Summary of what I did: - updated the normalization code - timestamp is still passed - via an 'ext' parameter - however it would make sense to get the server code tolerable to the absence of it - will deal with it later. - nonce is calculated based on the age of the client token, as per v5 I think it would be safe enough to resolve this JIRA without actually shipping a nonce implementation, at least for 2.6.2, custom NonceVerifier can alway be used which is a good start. We can review the option of shipping it post 2.6.2, once you tune it :-) I won't have more time till 2.6.2 is out to deal with this issue - however please work with the snapshot and test if possible, you may also spot some bugs there. It's quote close but a bit of tuning will be needed. > Add support for OAuth2 'mac' token type > --- > > Key: CXF-4431 > URL: https://issues.apache.org/jira/browse/CXF-4431 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Affects Versions: 2.6.1 >Reporter: Sasi M > Fix For: 2.7.0 > > Attachments: mac_token_nonce_checking.txt, mac_token_support.txt > > > CXF currently supports only the Bearer token type. This token type is not > feasible for use without SSL. > OAuth2 specs out the 'mac' token type that requires request signing for > authentication using the access token. The spec is described here: > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4441) Enabling XJC DV plugin creates invalid content
Dan Retzlaff created CXF-4441: - Summary: Enabling XJC DV plugin creates invalid content Key: CXF-4441 URL: https://issues.apache.org/jira/browse/CXF-4441 Project: CXF Issue Type: Bug Components: Tooling Affects Versions: 2.6.1 Reporter: Dan Retzlaff Priority: Minor CF-1206 introduces a behavior where complex types containing elements with default values get automatically instantiated in a parent. For example, given A(complex) contains B(complex) contains C(simple with default) A's constructor initializes "B b = new B()". This behavior goes beyond applying a default value; nothing in the schema says that A's "b" should be present by default. In our case, the presence of B has semantic value. What's more, B contains additional required fields, so this "default" invalidates the content model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4441) Enabling XJC DV plugin creates invalid content
[ https://issues.apache.org/jira/browse/CXF-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Retzlaff updated CXF-4441: -- Attachment: fix-dv-test.patch fix-dv.patch fail-dv-test.patch The first patch demonstrates the problem. The second two do not depend on the first. They patch the plugin and test respectively. (Sorry they're separate; my workspace doesn't lend itself to a single patch.) > Enabling XJC DV plugin creates invalid content > -- > > Key: CXF-4441 > URL: https://issues.apache.org/jira/browse/CXF-4441 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.6.1 >Reporter: Dan Retzlaff >Priority: Minor > Attachments: fail-dv-test.patch, fix-dv-test.patch, fix-dv.patch > > > CF-1206 introduces a behavior where complex types containing elements with > default values get automatically instantiated in a parent. For example, given > A(complex) contains B(complex) contains C(simple with default) > A's constructor initializes "B b = new B()". This behavior goes beyond > applying a default value; nothing in the schema says that A's "b" should be > present by default. > In our case, the presence of B has semantic value. What's more, B contains > additional required fields, so this "default" invalidates the content model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4441) Enabling XJC DV plugin creates invalid content
[ https://issues.apache.org/jira/browse/CXF-4441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Retzlaff updated CXF-4441: -- Description: CXF-1206 introduces a behavior where complex types containing elements with default values get automatically instantiated in a parent. For example, given A(complex) contains B(complex) contains C(simple with default) A's constructor initializes "B b = new B()". This behavior goes beyond applying a default value; nothing in the schema says that A's "b" should be present by default. In our case, the presence of B has semantic value. What's more, B contains additional required fields, so this "default" invalidates the content model. was: CF-1206 introduces a behavior where complex types containing elements with default values get automatically instantiated in a parent. For example, given A(complex) contains B(complex) contains C(simple with default) A's constructor initializes "B b = new B()". This behavior goes beyond applying a default value; nothing in the schema says that A's "b" should be present by default. In our case, the presence of B has semantic value. What's more, B contains additional required fields, so this "default" invalidates the content model. > Enabling XJC DV plugin creates invalid content > -- > > Key: CXF-4441 > URL: https://issues.apache.org/jira/browse/CXF-4441 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.6.1 >Reporter: Dan Retzlaff >Priority: Minor > Attachments: fail-dv-test.patch, fix-dv-test.patch, fix-dv.patch > > > CXF-1206 introduces a behavior where complex types containing elements with > default values get automatically instantiated in a parent. For example, given > A(complex) contains B(complex) contains C(simple with default) > A's constructor initializes "B b = new B()". This behavior goes beyond > applying a default value; nothing in the schema says that A's "b" should be > present by default. > In our case, the presence of B has semantic value. What's more, B contains > additional required fields, so this "default" invalidates the content model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4442) Process OneTimeUse element of SAML assertion
Oliver Wulff created CXF-4442: - Summary: Process OneTimeUse element of SAML assertion Key: CXF-4442 URL: https://issues.apache.org/jira/browse/CXF-4442 Project: CXF Issue Type: New Feature Components: WS-* Components Affects Versions: 2.6.1 Reporter: Oliver Wulff The OneTimeUse element is specified in secton 2.5.1.5 of the SAML core specification: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf CXF service endpoint doesn't process the OneTimeUse. Maybe the STS should set this flag if the following attribut is set: /wst:RequestSecurityToken/wst:Renewing/@Allow=False -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
