[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093599#comment-15093599 ] iris ding commented on CXF-6729: Thnaks Sergey. The fix from Neal looks good to me. The difference between Neal and Jersey implementation is Jersy will always set "" when it encounters special characters while Neal's version will check the cookie version first and only set "" if it is a version 1 cookie. Let us know your thoughts about this. I will be glad to commit the final change into CXF as my first commit. By the way, what branch should I commit to? Thanks & Best Regards, Iris Ding > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProviderTest.java, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093601#comment-15093601 ] iris ding commented on CXF-6729: Hi Sergey, it seems I can not assigh this issue to me. How can I make it happen? > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProviderTest.java, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093709#comment-15093709 ] Sergey Beryozkin commented on CXF-6729: --- Hi Neal, thanks for your effort, I have few comments. - Lets keep the original toString() code, without any version0 vs version1 checks because no one actually uses Version 0 or even attempts to set Version 0 or 1, it is either Version 1 or none. You have convertV0SetCookie(cookie, false); used twice with 'false' only used twice too, what is the point of having this flag then ? Lets keep it simple (and do it the same way RI does it), JAX-RS 1.0 starts from supporting Version 1 so lets not worry about some Version 0 cookies (though I do appreciate your effort in trying to get V0 supported). - Please keep only maybeQuote() and needsQuote() functions, and indeed update the original toString() code to use maybeQuote() - Do not check the cookie value for 'null' - NewCookie super constructor does it - Do not quote empty values, I see from the spec: av-pair = attr ["=" value]; optional value So if the value is empty then it should be just attr=, it is equivalent to being null - Please do the next patch as 'git diff' - I can not see what has changed in ResponseImplTest - If we quote the white spaced values then should Cookie.fromString() unquote such values, again, what does RI does ? Many Thanks, Sergey > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProviderTest.java, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[
https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093762#comment-15093762
]
Neal Hu commented on CXF-6729:
--
Hi Sergey, thanks for your review and comments.
1. I will update the code to keep v1 cookie only. Have the flag in the
convertV0SetCookie(cookie, false); used to be compatible with RFC1123Date.
2. Done
3. Do you mean the value field of the cookie or the cookie instance?
4. Done
5. OK
6. I have updated the NewCookie.fromString() to unquote the values and added
the test case. Do we need update CookieHeaderProvider also? RI parse the string
to cookie as below:
https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/message/internal/CookiesParser.java
if (value.startsWith("\"") && value.endsWith("\"") && value.length() > 1) {
value = value.substring(1, value.length() - 1);
}
Thanks,
Neal
> Version 1 NewCookie is not compliant with RFC 2109
> ---
>
> Key: CXF-6729
> URL: https://issues.apache.org/jira/browse/CXF-6729
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8
>
> Attachments: NewCookieHeaderProvider.java,
> NewCookieHeaderProviderTest.java, ResponseImplTest.java
>
>
> Hi,
> From http://www.ietf.org/rfc/rfc2109.txt and
> http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes
> the version 1 cookie look like: name="value with
> spaces";Max-Age=3600;Path="/";Version=1
> NewCookieHeaderProvider.toString(NewCookie) has not handled the special
> characters(RFC2068) that need around with quotes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093775#comment-15093775 ] Sergey Beryozkin commented on CXF-6729: --- Hi Neal I meant the value field, but please ignore my comment, maybeQuote() does check for null, and it won't harm even if a value filed will be checked again, so it is OK. Simply keep the original code (note it also prints Version in the end) and add maybeQuote() there, and if you prefer update the maxAge check as in your code. So we need to unquote if needed in NewCookie.fromString(). I guess the same, quote/unquote should be done with Cookie to/from String - we can deal with it in another JIRA may be Sergey > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProviderTest.java, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-6729: - Attachment: ResponseImplTest.patch NewCookieHeaderProviderTest.patch NewCookieHeaderProvider.patch > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093803#comment-15093803 ] Neal Hu commented on CXF-6729: -- Hi Sergy, The type of maxAge and Version MUST be Integer, will unquote in the fromString(), but I think quote them in the toString is regardless. Thanks, Neal > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[
https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093815#comment-15093815
]
Sergey Beryozkin commented on CXF-6729:
---
Hi Neal, the last patch looks better.
However - why did you add spaces everywhere, say "; Path=" ? It is allowed but
it is optional. Please remove them. The readability is of the least concern -
some clients might not be able to handle spaces.
And as I said, please keep it consistent with the original code - Version is
printed *last* there. And I see you missed 'EXPIRES' in your code. Just go via
the original code and only add mayBequote, example:
{code:java}
sb.append(value.getName()).append('=').append(maybeQuote(value.getValue()));
//and
if (value.getComment() != null) {
sb.append(';').append(COMMENT).append('=').append(maybeQuote(value.getComment()));
}
//etc
{code}
Will I update the code myself or will you create another patch ?
> Version 1 NewCookie is not compliant with RFC 2109
> ---
>
> Key: CXF-6729
> URL: https://issues.apache.org/jira/browse/CXF-6729
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8
>
> Attachments: NewCookieHeaderProvider.java,
> NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java,
> NewCookieHeaderProviderTest.patch, ResponseImplTest.java,
> ResponseImplTest.patch
>
>
> Hi,
> From http://www.ietf.org/rfc/rfc2109.txt and
> http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes
> the version 1 cookie look like: name="value with
> spaces";Max-Age=3600;Path="/";Version=1
> NewCookieHeaderProvider.toString(NewCookie) has not handled the special
> characters(RFC2068) that need around with quotes
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093831#comment-15093831 ] Sergey Beryozkin commented on CXF-6729: --- Iris, not sure, I'm not seeing your alias in the list of Assignees. Feel free to commit to master then 3.1.x and finally to 3.0.x once Neal addresses my last comments, I will re-assign to you later on once we know how it can be fixed > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093833#comment-15093833 ] Neal Hu commented on CXF-6729: -- Thanks for your comment， I will update shortly. Neal > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093839#comment-15093839 ] Sergey Beryozkin commented on CXF-6729: --- Thanks Neal. Iris, have you submitted CLA, see http://people.apache.org/committer-index.html#I Please check your id, is it in italics ? > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093840#comment-15093840 ] Sergey Beryozkin commented on CXF-6729: --- Iris, your id seems to be OK, Dan can you please help (for Iris to be able to assign JIRAs, etc) > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java, > ResponseImplTest.patch > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-6729: - Attachment: (was: ResponseImplTest.patch) > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProvider.patch, > NewCookieHeaderProviderTest.java, NewCookieHeaderProviderTest.patch, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-6729: - Attachment: NewCookieHeaderProviderTest.patch NewCookieHeaderProvider.patch > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProvider.patch, > NewCookieHeaderProviderTest.java, NewCookieHeaderProviderTest.patch, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-6729: - Attachment: (was: NewCookieHeaderProvider.patch) > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Neal Hu updated CXF-6729: - Attachment: (was: NewCookieHeaderProviderTest.patch) > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093851#comment-15093851 ] Neal Hu commented on CXF-6729: -- Sergey, Please review the patch, thanks. Neal > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093857#comment-15093857 ] Sergey Beryozkin commented on CXF-6729: --- Neal, thanks for the patience/effort, it looks good to me. I might do a couple of small tweaks afterwards. Iris, please go ahead with your commit. This is how I usually do it (starting from master, 3.2.0-SNAPSHOT): 1. git pull 2. git commit -a --message "[CXF-6729] Your commit message" 3. git push origin master then on 3.1.x: 1. git pull 2. git cherry-pick commit-number (you will see it from your commit to the master) 3. git push origin 3.1.x-fixes and finally on 3.0.x: 1. git pull 2. git cherry-pick commit-number (you will see it from your commit to 3.1.x-fixes) 3. git push origin 3.0.x-fixes Before committing to the master: do 'mvn clean install' in rt/frontend/jaxrs and systests/jaxrs at least Thanks, Sergey > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6729) Version 1 NewCookie is not compliant with RFC 2109
[ https://issues.apache.org/jira/browse/CXF-6729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093933#comment-15093933 ] Neal Hu commented on CXF-6729: -- Sergey，thanks for your advice. I will work with Iris to commit the patch. Neal > Version 1 NewCookie is not compliant with RFC 2109 > --- > > Key: CXF-6729 > URL: https://issues.apache.org/jira/browse/CXF-6729 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.0.7, 3.1.4 > Environment: Windows >Reporter: Neal Hu > Fix For: 3.1.5, 3.0.8 > > Attachments: NewCookieHeaderProvider.java, > NewCookieHeaderProvider.patch, NewCookieHeaderProviderTest.java, > NewCookieHeaderProviderTest.patch, ResponseImplTest.java > > > Hi, > From http://www.ietf.org/rfc/rfc2109.txt and > http://stackoverflow.com/questions/572482/why-do-cookie-values-with-whitespace-arrive-at-the-client-side-with-quotes > the version 1 cookie look like: name="value with > spaces";Max-Age=3600;Path="/";Version=1 > NewCookieHeaderProvider.toString(NewCookie) has not handled the special > characters(RFC2068) that need around with quotes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6742) Weblogic Integration for secured JMS Modules
Guillaume created CXF-6742: -- Summary: Weblogic Integration for secured JMS Modules Key: CXF-6742 URL: https://issues.apache.org/jira/browse/CXF-6742 Project: CXF Issue Type: Improvement Components: JMS Affects Versions: 3.1.4 Environment: SOAP/JMS services (client or server) accessing a Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy Reporter: Guillaume This is a follow up of the user list thread : http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic security model enforces the presence of a valid user (i.e. matching the security constraint) on the thread interacting with the ressource (i.e. creating a MessageConsumer or MessageProducer on a JMS session). This is documented here : https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 This user can be logged in either by having either an open InitialContext, or a JAAS LoginContext, active at the time of the security-check. In the CXF 2.x and 3.x implementations, such a condition is met when accessing the JNDI (to retreive the ConnectionFactory or Destination queue objects), but the JNDI context is closed almost immediately after this step, meaning : 1) When sending SOAP/JMS calls, the calling thread does not have an open InitialContext anymore 2) When exposing a SOAP/JMS service, the poller threads that start never even had a logged in user at any point in time This leads to a JMS Security exception. For the server side : Caused by: weblogic.jms.common.JMSSecurityException: Access denied to resource: type=, application=... at weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) ... at org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer In CXF 2.X, the SpringJMS based implementation would allow any user to override the polling threads to actually perform InitialContext injection, as suggested here : http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where we can override the thread pool to perform such an injection too (although this suffers from several concerns, such as the difficulty to inject different credentials for different endpoints). An ideal solution would be to match SpringJMS behaviour of the "exposeAccessContext" function : http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html . That is, CXF would provide an option (say, on JMSConfig), to expose an InitialContext in the threads performing JMS API calls through JNDI. I will shortly provide a draft patch for this behavior, as a base for discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6742) Weblogic Integration for secured JMS Modules
[ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume updated CXF-6742: --- Attachment: soapJMSWeblo.diff The building blocks of this patch are : Configuration 1) Add a boolean "exposeJndiEnvironment" internal variable to the JMSEndpoint class, allowing a separate trigger for the new behavior. This makes this boolean settable inside a jms:jndi URL inside an endpoint description. 2) Mirror this property inside the JMSConfig object, to carry it on the rest of the framework 3) Make the JMSConfigFactory copy the property from step1 above to step 2 Server side SOAP/JMS 1) Make the JMSDestination object honor the "exposeJndiEnvironment" flag, by progpagating the JNDI environment from the JMSConfig to the MessageListenerContainer 2) Enhance AbstractMessageListenerContainer to be able to hold this JndiEnvironment, expose it as an InitialContext, and close it 3) Inside the PollingMessageListenerContainer, detect the presence of this JNDIEnvironment, and if available, wrap the Poller/XAPoller runnables inside a new JNDIPollerDecorator to actually call the methods at step 2 above Client side 1) Make the JMSConduit honor JMSConfig's "exposeJNDIContext" flag at the start of the sendExchange method 2) Make it propagate the environment to the conduit's MessageListernerContainer (same base class as the server side) 3) Make MessageListenerContainer honor the new behavior : there's actually nothing to do here because the current implementation does not spawn threads, but a javadoc is added to remember that if ever this would change. About this patch : well first, I'm not a seasonned CXF hacker, so my knowledge of its coding convetions is limited. Second, I did not refactor the JNDIHelper class in this, but this might reduce boilerplate code if done elegantly. Finally, I do not know the unit test infrastructure well enough to provide a basic test for this, but I guess this is weblogic dependant, and not so much unit testable as "integration" testable. > Weblogic Integration for secured JMS Modules > > > Key: CXF-6742 > URL: https://issues.apache.org/jira/browse/CXF-6742 > Project: CXF > Issue Type: Improvement > Components: JMS >Affects Versions: 3.1.4 > Environment: SOAP/JMS services (client or server) accessing a > Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy >Reporter: Guillaume > Attachments: soapJMSWeblo.diff > > > This is a follow up of the user list thread : > http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E > When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic > security model enforces the presence of a valid user (i.e. matching the > security constraint) on the thread interacting with the ressource (i.e. > creating a MessageConsumer or MessageProducer on a JMS session). > This is documented here : > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > This user can be logged in either by having either an open InitialContext, or > a JAAS LoginContext, active at the time of the security-check. > In the CXF 2.x and 3.x implementations, such a condition is met when > accessing the JNDI (to retreive the ConnectionFactory or Destination queue > objects), but the JNDI context is closed almost immediately after this step, > meaning : > 1) When sending SOAP/JMS calls, the calling thread does not have an open > InitialContext anymore > 2) When exposing a SOAP/JMS service, the poller threads that start never even > had a logged in user at any point in time > This leads to a JMS Security exception. For the server side : > Caused by: weblogic.jms.common.JMSSecurityException: Access denied to > resource: type=, application=... > at > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) >... >at > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > In CXF 2.X, the SpringJMS based implementation would allow any user to > override the polling threads to actually perform InitialContext injection, as > suggested here : > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where > we can override the thread pool to perform such an injection too (although > this suffers from several concerns, such as the difficulty to inject > different credentials for different endpoints). > An ideal solution would be to match SpringJMS behaviour of the > "exposeAccessContext" function : > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html > .
[jira] [Assigned] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned FEDIZ-140: - Assignee: Colm O hEigeartaigh > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated FEDIZ-140: -- Fix Version/s: 1.2.2 1.3.0 > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved FEDIZ-140. --- Resolution: Fixed > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094110#comment-15094110 ] Colm O hEigeartaigh commented on FEDIZ-140: --- Hi Jan, I took a look at this issue. The problem was actually with the SAML SSO parsing code in CXF. It was taking the Session NotOnOrAfter value as the expiry of the received token, and not falling back to the SubjectConfirmationData NotOnOrAfter if the former was null. Therefore no expiry was associated with the token received in the IdP. The error was when the STS is validating the token. I've fixed this now + I tested that it is working correctly. The IdP will redirect back to the SAML SSO IdP if the cached token is no longer valid. This is the same behaviour as that of the WS-Federation protocol in the IdP. I've added a boolean "tokenExpirationValidation" to the WfreshParser in the IdP to disable the expiry check per-request. It defaults to "true" to preserve past behaviour (note that same configuration option in the plugins defaults to "false"). Colm. > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FEDIZ-140) IDP caches outdated SAML Tokens
[ https://issues.apache.org/jira/browse/FEDIZ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094110#comment-15094110 ] Colm O hEigeartaigh edited comment on FEDIZ-140 at 1/12/16 3:50 PM: Hi Jan, I took a look at this issue. The problem was actually with the SAML SSO parsing code in CXF. It was taking the Session NotOnOrAfter value as the expiry of the received token, and not falling back to the SubjectConfirmationData NotOnOrAfter if the former was null. Therefore no expiry was associated with the token received in the IdP. The error was when the STS is validating the token. I've fixed this now + I tested that it is working correctly. The IdP will redirect back to the SAML SSO IdP if the cached token is no longer valid. This is the same behaviour as that of the WS-Federation protocol in the IdP. I've added a boolean "tokenExpirationValidation" to the WfreshParser in the IdP to disable the expiry check per-request. It defaults to "true" to preserve past behaviour (note that same configuration option in the plugins defaults to "false"). Edit: Just to note that the STS may reject the expired token - this is up to the STS implementation. Colm. was (Author: coheigea): Hi Jan, I took a look at this issue. The problem was actually with the SAML SSO parsing code in CXF. It was taking the Session NotOnOrAfter value as the expiry of the received token, and not falling back to the SubjectConfirmationData NotOnOrAfter if the former was null. Therefore no expiry was associated with the token received in the IdP. The error was when the STS is validating the token. I've fixed this now + I tested that it is working correctly. The IdP will redirect back to the SAML SSO IdP if the cached token is no longer valid. This is the same behaviour as that of the WS-Federation protocol in the IdP. I've added a boolean "tokenExpirationValidation" to the WfreshParser in the IdP to disable the expiry check per-request. It defaults to "true" to preserve past behaviour (note that same configuration option in the plugins defaults to "false"). Colm. > IDP caches outdated SAML Tokens > --- > > Key: FEDIZ-140 > URL: https://issues.apache.org/jira/browse/FEDIZ-140 > Project: CXF-Fediz > Issue Type: Bug > Components: IDP >Affects Versions: 1.2.1 >Reporter: Jan Bernhardt >Assignee: Colm O hEigeartaigh > Fix For: 1.3.0, 1.2.2 > > > I did some tests today with a SAML SSO trusted IDP. During these tests I've > noticed that the Fediz-IDP will only redirect me once to the trusted 3rd > party IDP for login. Then it caches my (3rd party) SAML token even if the > token is not valid because the lifetime of that token ended. The result is, > that I see an error page at the IDP, instead of getting redirected back again > to my 3rd party IDP. > I see two solutions for this issue. > Option 1: Provide a "disable" option on the Fediz IDP to ignore lifetime of > cached tokens. > Option 2: Redirect back to 3rd Party IDP if cached token is not valid any > longer. > I think it would be good if both options could be provided within Fediz, > leaving the choice to the user, depending on their use case. > A current workaround is to disable token caching in the IDP. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-141) POST Binding for SAML SSO Remote IDP
[
https://issues.apache.org/jira/browse/FEDIZ-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094252#comment-15094252
]
Colm O hEigeartaigh commented on FEDIZ-141:
---
Hi Jan,
The IdP is still using the redirect binding to send the request to the SAML SSO
IdP. Is this ok for your scenario or should we also support sending the request
via POST?
Colm.
> POST Binding for SAML SSO Remote IDP
> -
>
> Key: FEDIZ-141
> URL: https://issues.apache.org/jira/browse/FEDIZ-141
> Project: CXF-Fediz
> Issue Type: Improvement
> Components: IDP
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 1.3.0
>
>
> Currently the Fediz IDP supports only a GET Binding for a SAML Response from
> a remote (trusted 3rd party) SAML IDP.
> It is not recommended to send such big payloads like the {{SAMLResponse}}
> within the URL as a parameter. Thus POST binding should be the preferred
> solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
Benson Margulies created CXF-6743:
-
Summary: Inconsistent versions of jax-rs specs can lead to OSGi
pain
Key: CXF-6743
URL: https://issues.apache.org/jira/browse/CXF-6743
Project: CXF
Issue Type: Bug
Affects Versions: 3.1.4
Reporter: Benson Margulies
CXF's dependency tree calls for:
{code}
javax.ws.rs
javax.ws.rs-api
2.0.1
{code}
However, the Karaf features asks for a servicemix bundle that only provides
version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
OSGi bundle built with CXF will be prone to try to import 2.0.1 of the package
in this jar, and then fail to be able to wire it.
If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
feature should reference it).
I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6744) Exceptions thrown from methods annotated with @Suspended result in no response at all
Benson Margulies created CXF-6744: - Summary: Exceptions thrown from methods annotated with @Suspended result in no response at all Key: CXF-6744 URL: https://issues.apache.org/jira/browse/CXF-6744 Project: CXF Issue Type: Bug Reporter: Benson Margulies I am about to push a commit with an ignored test that fails because of the issue described in the title. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6744) Exceptions thrown from methods annotated with @Suspended result in no response at all
[ https://issues.apache.org/jira/browse/CXF-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094429#comment-15094429 ] Benson Margulies commented on CXF-6744: --- The commit on master is fa0eea884adf49a0a6f990e15a0e69d17800156e. I leave it to [~sergeyb] to comment on what to do about it. > Exceptions thrown from methods annotated with @Suspended result in no > response at all > - > > Key: CXF-6744 > URL: https://issues.apache.org/jira/browse/CXF-6744 > Project: CXF > Issue Type: Bug >Reporter: Benson Margulies > > I am about to push a commit with an ignored test that fails because of the > issue described in the title. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-3) Get the SAAJ/SOAP handlers working
[ https://issues.apache.org/jira/browse/CXF-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1509#comment-1509 ] ASF GitHub Bot commented on CXF-3: -- GitHub user CMoH opened a pull request: https://github.com/apache/incubator-brooklyn/pull/1140 [WIP] CXF implementation of rest api I've worked on a separate REST API project for Brooklyn using CXF, since changing the current brooklyn-rest-server in a manner that's compatible both with karaf and the current launcher seems impossible. However, the main downside is that for the time being there are two parallel implementations of brooklyn REST resources, and the same for the rest-api. Below are the causes for this: 1. While the first duplication is to be expected, duplication of the rest-api project is a bad idea. Unfortunately CXF-3.1.4 is already based on jax-rs-2.x, while brooklyn is using jax-rs-1.1 because of jersey-1.19. 2. Another problem is that ```CatalogApi.createFromMultipart()``` uses HTTP forms, which do not seem to have standard jax-rs annotations. This means custom jersey annotations in brooklyn-rest-api and the reverse in brooklyn-rest-api-cxf. Does anyone have any idea on how to create a single rest-api project with annotations usable both by CXF and Jersey1? I've also moved tests that rely on a having a fully-blown brooklyn instance running to karaf integration tests project. For the time being they fail - I'll try to address them and update the PR, but your input is already valuable. Thanks You can merge this pull request into a Git repository by running: $ git pull https://github.com/CMoH/incubator-brooklyn cxf Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-brooklyn/pull/1140.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 #1140 commit d848091e18d27bb7cac06ec7e38c40faa19e40a2 Author: Ciprian Ciubotariu Date: 2015-12-09T14:01:06Z [BROOKLYN-183] Add CXF projects for rest API Create two new projects holding the CXF resources for later use only within the OSGi launcher. The HA code was removed from the CXF resources, with the intention of implementing HA using karaf cellar. For a time this will create code duplication, but hopefully the jersey code will be dropped when migrating to the karaf distro. REST API tests were adapted from existing tests in the jersey implementation, but this commit does not attempt to have them working. commit 1522141e80c27bcf1e15e013f23086da4d034463 Author: Ciprian Ciubotariu Date: 2015-12-10T02:01:12Z [BROOKLYN-183] Remove jersey references from brooklyn-rest-resources-cxf commit 1d9bbda922df0e35b938f47066dc1707699f169a Author: Ciprian Ciubotariu Date: 2015-12-10T02:02:09Z [BROOKLYN-183] Use relative paths for REST resource paths Move the context root at /v1, and use paths relative to that in resource annotations. commit 4c4a442f21f46495d8dcf13d274468feef8a34a0 Author: Ciprian Ciubotariu Date: 2015-12-10T02:03:08Z [BROOKLYN-183] Add CXF REST resources to karaf features commit 64081782d23a9a1550f1e14ae1cf2c5078995705 Author: Ciprian Ciubotariu Date: 2015-12-11T13:42:37Z [BROOKLYN-183] Move CXF servlet context to /v1 In order to preserve compatibility with the existing brooklyn REST API we need to expose resources at path /v1 instead of /cxf/v1. For now move the whole CXF servlet at /v1, and with resources mounted at / we get the historical path /v1/ for the REST API. We'll need to make the JSGUI configurable with the base REST API path in the future though. Also add appropriate providers to the OSGi CXF service blueprint. commit fb02ea783c288c64bbdd0eff9ba6604ec646573b Author: Ciprian Ciubotariu Date: 2015-12-11T19:15:19Z [BROOKLYN-183] Use relative paths when referring REST resources Don't use absolute paths based on the assumption that the REST API is deployed at /v1. Instead use an UriBuilder provided by JAX-RS as a context-injected UriInfo object, which should work with any root context path. Also drop the /v1 prefix from REST API tests and test fixtures. commit 96710edb0dae01a45d28a5b0d1051bc7020386c1 Author: Ciprian Ciubotariu Date: 2015-12-17T14:03:29Z [BROOKLYN-183] Fix usage of resources in CXF unit tests Use HTTP transport instead of local transport so we can have a ServletContext to get/setAttribute. Allow CXF to use BrooklynJacksonJsonProvider for message formatting and parsing. Inject the ManagementContext in resources and providers. Add request/response logging during tests. commit d7409839c1a76a3d3a1831241193d1499c187cb3 Author: Ciprian Ciubotar
[jira] [Commented] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
[
https://issues.apache.org/jira/browse/CXF-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094942#comment-15094942
]
Sergey Beryozkin commented on CXF-6743:
---
Hi Benson
I thought you had it resolved earlier ? Curious why 2.0 and 2.0.1 are not
mutually compatible...
> Inconsistent versions of jax-rs specs can lead to OSGi pain
> ---
>
> Key: CXF-6743
> URL: https://issues.apache.org/jira/browse/CXF-6743
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Benson Margulies
>
> CXF's dependency tree calls for:
> {code}
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
> {code}
> However, the Karaf features asks for a servicemix bundle that only provides
> version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
> OSGi bundle built with CXF will be prone to try to import 2.0.1 of the
> package in this jar, and then fail to be able to wire it.
> If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
> feature should reference it).
> I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
[
https://issues.apache.org/jira/browse/CXF-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095012#comment-15095012
]
Benson Margulies commented on CXF-6743:
---
My workaround broke and had to be laboriously repaired, so I became motivated
to try to make a real fix.
The problem here is that the JAX-RS API jar is not a p
> Inconsistent versions of jax-rs specs can lead to OSGi pain
> ---
>
> Key: CXF-6743
> URL: https://issues.apache.org/jira/browse/CXF-6743
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Benson Margulies
>
> CXF's dependency tree calls for:
> {code}
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
> {code}
> However, the Karaf features asks for a servicemix bundle that only provides
> version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
> OSGi bundle built with CXF will be prone to try to import 2.0.1 of the
> package in this jar, and then fail to be able to wire it.
> If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
> feature should reference it).
> I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-6743) Inconsistent versions of jax-rs specs can lead to OSGi pain
[
https://issues.apache.org/jira/browse/CXF-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095012#comment-15095012
]
Benson Margulies edited comment on CXF-6743 at 1/12/16 9:41 PM:
My workaround broke and had to be laboriously repaired, so I became motivated
to try to make a real fix.
The problem here is that the JAX-RS API jar is not a pure specification. It has
executable code in it. The version that CXF depends on contains an SPI that
doesn't work in OSGi; it ends up getting ClassNotFound errors on Glassfish.
That's why the CXF Karaf feature replaces it with the ServiceMix jar. When I
just tried to exclude the spec jar altogether in favor of the SM jar, I got
strange failures that I could not figure out. So I've ended up forcing the
dependency at compile time back to the 2.0 spec jar, and then using the SM jar
at runtime. If we do what this JIRA says, the existing 2.0.1 dependency in the
main CXF poms will work right.
was (Author: bmargulies):
My workaround broke and had to be laboriously repaired, so I became motivated
to try to make a real fix.
The problem here is that the JAX-RS API jar is not a p
> Inconsistent versions of jax-rs specs can lead to OSGi pain
> ---
>
> Key: CXF-6743
> URL: https://issues.apache.org/jira/browse/CXF-6743
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.1.4
>Reporter: Benson Margulies
>
> CXF's dependency tree calls for:
> {code}
>
> javax.ws.rs
> javax.ws.rs-api
> 2.0.1
>
> {code}
> However, the Karaf features asks for a servicemix bundle that only provides
> version 2.0 of the spec, and indeed, there's no SM bundle for 2.0.1. So, an
> OSGi bundle built with CXF will be prone to try to import 2.0.1 of the
> package in this jar, and then fail to be able to wire it.
> If CXF really needs 2.0.1, then we need an SM bundle for 2.0.1 (and the CXF
> feature should reference it).
> I'll link the SM jira.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FEDIZ-141) POST Binding for SAML SSO Remote IDP
[
https://issues.apache.org/jira/browse/FEDIZ-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095731#comment-15095731
]
Jan Bernhardt commented on FEDIZ-141:
-
Hi Colm,
redirect binding (for SAMLRequest) is all I need for now. I've added a POST
operation to the mockup service so it is available for testing once the IDP
supports the POST binding.
Cheers
Jan
> POST Binding for SAML SSO Remote IDP
> -
>
> Key: FEDIZ-141
> URL: https://issues.apache.org/jira/browse/FEDIZ-141
> Project: CXF-Fediz
> Issue Type: Improvement
> Components: IDP
>Reporter: Jan Bernhardt
>Assignee: Jan Bernhardt
> Fix For: 1.3.0
>
>
> Currently the Fediz IDP supports only a GET Binding for a SAML Response from
> a remote (trusted 3rd party) SAML IDP.
> It is not recommended to send such big payloads like the {{SAMLResponse}}
> within the URL as a parameter. Thus POST binding should be the preferred
> solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-6742) Weblogic Integration for secured JMS Modules
[ https://issues.apache.org/jira/browse/CXF-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider reassigned CXF-6742: Assignee: Christian Schneider > Weblogic Integration for secured JMS Modules > > > Key: CXF-6742 > URL: https://issues.apache.org/jira/browse/CXF-6742 > Project: CXF > Issue Type: Improvement > Components: JMS >Affects Versions: 3.1.4 > Environment: SOAP/JMS services (client or server) accessing a > Weblogic (10 to 12) JMS Module with a Weblogic Security Strategy >Reporter: Guillaume >Assignee: Christian Schneider > Attachments: soapJMSWeblo.diff > > > This is a follow up of the user list thread : > http://mail-archives.apache.org/mod_mbox/cxf-users/201601.mbox/%3CCAC88joDPa%2BRmY02jSrnDdVV8ctyA0wGP_Z9j0ipZhWHSCvEybA%40mail.gmail.com%3E > When accessing JMS ressources of a secured Weblogic JMS Module, the weblogic > security model enforces the presence of a valid user (i.e. matching the > security constraint) on the thread interacting with the ressource (i.e. > creating a MessageConsumer or MessageProducer on a JMS session). > This is documented here : > https://docs.oracle.com/cd/E13222_01/wls/docs81/jndi/jndi.html#467275 > This user can be logged in either by having either an open InitialContext, or > a JAAS LoginContext, active at the time of the security-check. > In the CXF 2.x and 3.x implementations, such a condition is met when > accessing the JNDI (to retreive the ConnectionFactory or Destination queue > objects), but the JNDI context is closed almost immediately after this step, > meaning : > 1) When sending SOAP/JMS calls, the calling thread does not have an open > InitialContext anymore > 2) When exposing a SOAP/JMS service, the poller threads that start never even > had a logged in user at any point in time > This leads to a JMS Security exception. For the server side : > Caused by: weblogic.jms.common.JMSSecurityException: Access denied to > resource: type=, application=... > at > weblogic.jms.common.JMSSecurityHelper.checkPermission(JMSSecurityHelper.java:160) >... >at > org.apache.cxf.transport.jms.util.PollingMessageListenerContainer.createConsumer > In CXF 2.X, the SpringJMS based implementation would allow any user to > override the polling threads to actually perform InitialContext injection, as > suggested here : > http://stackoverflow.com/questions/19849766/org-springframework-jms-jmssecurityexception-access-denied-to-resource-type-j > In CXF 3.2 (not yet released), we have a workaround thanks to CXF-6702, where > we can override the thread pool to perform such an injection too (although > this suffers from several concerns, such as the difficulty to inject > different credentials for different endpoints). > An ideal solution would be to match SpringJMS behaviour of the > "exposeAccessContext" function : > http://docs.spring.io/spring-framework/docs/2.5.6/api/org/springframework/jndi/JndiObjectFactoryBean.html > . That is, CXF would provide an option (say, on JMSConfig), to expose an > InitialContext in the threads performing JMS API calls through JNDI. > I will shortly provide a draft patch for this behavior, as a base for > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
