[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails
[ https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635425#comment-17635425 ] Werner Punz commented on MYFACES-4499: -- I have to postpone both fixes until tomorrow, because I was busy with porting the TCK, my preference would be anyway, to get this fixed when I have the TCKs fully ported to Selenium (which should be sometime next week). Does anyone have objections, or can we wait with the fixes until then? Then I can run a full TCK ajax test against the new codebase anyway (and against the old one) > TCK: Issue3020IT: testDelayNegative Fails > - > > Key: MYFACES-4499 > URL: https://issues.apache.org/jira/browse/MYFACES-4499 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > Attachments: test-faces22-ajax.war > > > App Code: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35] > > Unit Test: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54] > > The test verifies that a delay on the f:ajax is a valid input. The test uses > "NaN" and the implementation is expected to throw an exception to stop the > request from occurring. > Our RC2 code appears to be here: > [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314] > I've attached the TCK application (with Mojarra) to this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails
[ https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635151#comment-17635151 ] Werner Punz edited comment on MYFACES-4499 at 11/17/22 6:00 AM: Yes this is a simple one, thanks for reporting, one of those corner cases I have missed in both implementations, will get a fix today together with the script tag removal issue. Expect a fix later today with a new RC of my reimplementation. was (Author: werpu): Yes this is a simple one, thanks for reporting, one of those corner cases I have missing in my reimplementation, will get a fix today together with the script tag removal issue. Expect a fix later today with a new RC of my reimplementation. > TCK: Issue3020IT: testDelayNegative Fails > - > > Key: MYFACES-4499 > URL: https://issues.apache.org/jira/browse/MYFACES-4499 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > Attachments: test-faces22-ajax.war > > > App Code: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35] > > Unit Test: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54] > > The test verifies that a delay on the f:ajax is a valid input. The test uses > "NaN" and the implementation is expected to throw an exception to stop the > request from occurring. > Our RC2 code appears to be here: > [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314] > I've attached the TCK application (with Mojarra) to this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4499) TCK: Issue3020IT: testDelayNegative Fails
[ https://issues.apache.org/jira/browse/MYFACES-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635151#comment-17635151 ] Werner Punz commented on MYFACES-4499: -- Yes this is a simple one, thanks for reporting, one of those corner cases I have missing in my reimplementation, will get a fix today together with the script tag removal issue. Expect a fix later today with a new RC of my reimplementation. > TCK: Issue3020IT: testDelayNegative Fails > - > > Key: MYFACES-4499 > URL: https://issues.apache.org/jira/browse/MYFACES-4499 > Project: MyFaces Core > Issue Type: Bug >Reporter: Volodymyr Siedlecki >Priority: Major > Attachments: test-faces22-ajax.war > > > App Code: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue3020Negative.xhtml#L35] > > Unit Test: > [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue3020IT.java#L49-L54] > > The test verifies that a delay on the f:ajax is a valid input. The test uses > "NaN" and the implementation is expected to throw an exception to stop the > request from occurring. > Our RC2 code appears to be here: > [https://github.com/apache/myfaces/blob/89c747e85615e3f33265e664c8361789f38ea7db/api/src/main/javascript/META-INF/resources/myfaces/_impl/core/Impl.js#L311-L314] > I've attached the TCK application (with Mojarra) to this issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
[
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
]
Werner Punz edited comment on MYFACES-4498 at 11/17/22 5:57 AM:
Yes please assign it to me. The script tags in fact are appended but then
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a
script tag and then remove it)
I probably have to remove the removal for the head update case.
So is it a bug, if yes a mild one, but definitely a deviation from the expected
behavior which needs a fix.
Btw. did the TCK code work on the new codebase? Or did you just a check whether
the new codebase exposes the same behavior.
It normally should not since the test uses HTMLUnit, it is in fact one of those
cases I have ported already to Webdrivers! If the TCK ran, than I probably can
stop my work on the porting process and have to check what they did with HTML
unit that this test runs (and also I can pull my challenge on this one), I
might have missed something.
was (Author: werpu):
Yes please assign it to me. The script tags in fact are appended but then
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a
script tag and then remove it)
I probably have to remove the removal for the head update case.
Btw. did the TCK code work on the new codebase, or did you just a check whether
the new codebase exposes the same behavior.
It normally should not since the test uses HTMLUnit, it is in fact one of those
cases I have ported already to Webdrivers!
> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
>
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code:
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> {code}
> The HTML is then set as :
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
> @import
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
>
> {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL?
> Should that occur? The JavaScript in issue4345result.xhtml specifically
> looks for a link element.
> 2) The script tags *are not appended* to the head element, but I do see
> network requests for them. Additionally, the scripts do run (confirmed by the
> console: "issue4345.js loaded." ).
> This fails on both the RC2 scripts and the new TypeScript code.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
[
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
]
Werner Punz edited comment on MYFACES-4498 at 11/17/22 5:56 AM:
Yes please assign it to me. The script tags in fact are appended but then
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a
script tag and then remove it)
I probably have to remove the removal for the head update case.
Btw. did the TCK code work on the new codebase, or did you just a check whether
the new codebase exposes the same behavior.
It normally should not since the test uses HTMLUnit, it is in fact one of those
cases I have ported already to Webdrivers!
was (Author: werpu):
Yes please assign it to me. The script tags in fact are appended but then
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a
script tag and then remove it)
I probably have to remove the removal for the head update case.
> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
>
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code:
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> {code}
> The HTML is then set as :
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
> @import
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
>
> {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL?
> Should that occur? The JavaScript in issue4345result.xhtml specifically
> looks for a link element.
> 2) The script tags *are not appended* to the head element, but I do see
> network requests for them. Additionally, the scripts do run (confirmed by the
> console: "issue4345.js loaded." ).
> This fails on both the RC2 scripts and the new TypeScript code.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4498) TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
[
https://issues.apache.org/jira/browse/MYFACES-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635150#comment-17635150
]
Werner Punz commented on MYFACES-4498:
--
Yes please assign it to me. The script tags in fact are appended but then
removed, this is the standard way on how you evaluate them.
(call to eval are basically forbidden, an eval is done by swiftly appending a
script tag and then remove it)
I probably have to remove the removal for the head update case.
> TCK: Issue 4345 : Head Element Not Updated As Expected via Ajax Call
>
>
> Key: MYFACES-4498
> URL: https://issues.apache.org/jira/browse/MYFACES-4498
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0-RC2
>Reporter: Volodymyr Siedlecki
>Priority: Major
> Attachments: test-faces22-ajax.war
>
>
> Test Code:
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/main/webapp/issue4345result.xhtml]
>
> [https://github.com/jakartaee/faces/blob/4.0.1/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax/Issue4345IT.java#L47]
> This test was created for ensure HTML is only escaped twice ([Issue
> 4345|https://github.com/eclipse-ee4j/mojarra/issues/4345). However, MyFaces
> is encountering two problems with this test.
> Firstly, here is the Ajax response and the updated HTML:
> {code:java}
>
>
>
>
>
>
>
>
>
>
> {code}
> The HTML is then set as :
> {code:java}
> http://www.w3.org/1999/xhtml;>
>
> @import
> url('/test-faces22-ajax/jakarta.faces.resource/issue4345.css.xhtml?firstParam=1&secondParam=2');
>
>
>
> {code}
> 1) We change from a link (type/css ) to a style tag that imports the URL?
> Should that occur? The JavaScript in issue4345result.xhtml specifically
> looks for a link element.
> 2) The script tags *are not appended* to the head element, but I do see
> network requests for them. Additionally, the scripts do run (confirmed by the
> console: "issue4345.js loaded." ).
> This fails on both the RC2 scripts and the new TypeScript code.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'
[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
]
Werner Punz edited comment on MYFACES-4481 at 11/15/22 9:38 AM:
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handler thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
Unfortunately you cannot automate this over javascript because you are not
allowed to read in the unsecured onclick attribute on js level in the CSP
fortified inline script part.
So theoretically a you can fix this in an automated manner on renderer level,
but not on javascript level. Otherwise you do it by hand on a case by case base.
was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - add
[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'
[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
]
Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:21 AM:
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - add h:commandLink inside h:form
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and click to link
> - get error in console:
> {{Refused to execute inline event handler because it violates the following
> Content Security Policy
[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'
[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
]
Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:20 AM:
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - add h:commandLink inside h:form
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and click to link
> - get error in console:
> {{Refused to execute inline event handler because it violates the following
> Content Security Policy
[jira] [Comment Edited] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'
[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
]
Werner Punz edited comment on MYFACES-4481 at 11/15/22 8:19 AM:
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
{code}
would become
{code:html}
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
```html
```
would become
```html
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
```
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - add h:commandLink inside h:form
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and click to link
> - get error in console:
> {{Refused to execute inline event handler because it violates the following
> Content Security Policy directive: "script-src
[jira] [Commented] (MYFACES-4481) HTML event handlers don't work without 'unsafe-inline'
[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634224#comment-17634224
]
Werner Punz commented on MYFACES-4481:
--
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
```html
```
would become
```html
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
```
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> --
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - add h:commandLink inside h:form
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and click to link
> - get error in console:
> {{Refused to execute inline event handler because it violates the following
> Content Security Policy directive: "script-src 'self' 'nonce-test123'".
> Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce
> ('nonce-...') is required to enable inline execution. Note that hashes do not
> apply to event handlers, style attributes and javascript: navigations unless
> the 'unsafe-hashes' keyword is present.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4496) Server side Websocket/Push Implementation not working
[ https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631148#comment-17631148 ] Werner Punz commented on MYFACES-4496: -- Error was on my side, I was using the javax namespace accidentally instead of the jakarta namespace for the context param change. > Server side Websocket/Push Implementation not working > -- > > Key: MYFACES-4496 > URL: https://issues.apache.org/jira/browse/MYFACES-4496 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0-RC2 >Reporter: Werner Punz >Priority: Blocker > > While fixing several reported bugs in the new faces.js code I ran against a > non working push implementation on the 4.0.0-RC2 codebase. > Problem was a simple new WebSocket() could not > establish a working connection. > The problem is definitely somewhere in the server, either not registering the > Websocket endpoint or delivering the wrong connection token. > A example implemented via the Websocket servlet api and plain html works in > the same configuration, se we can rule out the server environment (Embedded > Tomcat 10). You can use straight the code from master to replicate this > problem (I have decorated the faces.js api accordingly just to try a > connection on the jsf side instead of going into the code) > > An example can be found at: [https://github.com/werpu/websocketproblem] > Run instructions are included in the integrated readme, it uses an embedded > tomcat/openwebbeans/myfaces 4.0.0 stack so a simple > mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts > the server and installs all libraries, the rest is documented in the github > repo readme. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4496) Server side Websocket/Push Implementation not working
[ https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631069#comment-17631069 ] Werner Punz edited comment on MYFACES-4496 at 11/9/22 1:18 PM: --- Apparently the entire push api now is getting a refactoring: [https://github.com/apache/myfaces/pull/327] I will retest the issue once the pull request is merged. was (Author: werpu): Apparently the entire push api now gets a refactoring: [https://github.com/apache/myfaces/pull/327] I will retest the issue once the pull request is merged. > Server side Websocket/Push Implementation not working > -- > > Key: MYFACES-4496 > URL: https://issues.apache.org/jira/browse/MYFACES-4496 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0-RC2 >Reporter: Werner Punz >Priority: Blocker > > While fixing several reported bugs in the new faces.js code I ran against a > non working push implementation on the 4.0.0-RC2 codebase. > Problem was a simple new WebSocket() could not > establish a working connection. > The problem is definitely somewhere in the server, either not registering the > Websocket endpoint or delivering the wrong connection token. > A example implemented via the Websocket servlet api and plain html works in > the same configuration, se we can rule out the server environment (Embedded > Tomcat 10). You can use straight the code from master to replicate this > problem (I have decorated the faces.js api accordingly just to try a > connection on the jsf side instead of going into the code) > > An example can be found at: [https://github.com/werpu/websocketproblem] > Run instructions are included in the integrated readme, it uses an embedded > tomcat/openwebbeans/myfaces 4.0.0 stack so a simple > mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts > the server and installs all libraries, the rest is documented in the github > repo readme. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4496) Server side Websocket/Push Implementation not working
[ https://issues.apache.org/jira/browse/MYFACES-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631069#comment-17631069 ] Werner Punz commented on MYFACES-4496: -- Apparently the entire push api now gets a refactoring: [https://github.com/apache/myfaces/pull/327] I will retest the issue once the pull request is merged. > Server side Websocket/Push Implementation not working > -- > > Key: MYFACES-4496 > URL: https://issues.apache.org/jira/browse/MYFACES-4496 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0-RC2 >Reporter: Werner Punz >Priority: Blocker > > While fixing several reported bugs in the new faces.js code I ran against a > non working push implementation on the 4.0.0-RC2 codebase. > Problem was a simple new WebSocket() could not > establish a working connection. > The problem is definitely somewhere in the server, either not registering the > Websocket endpoint or delivering the wrong connection token. > A example implemented via the Websocket servlet api and plain html works in > the same configuration, se we can rule out the server environment (Embedded > Tomcat 10). You can use straight the code from master to replicate this > problem (I have decorated the faces.js api accordingly just to try a > connection on the jsf side instead of going into the code) > > An example can be found at: [https://github.com/werpu/websocketproblem] > Run instructions are included in the integrated readme, it uses an embedded > tomcat/openwebbeans/myfaces 4.0.0 stack so a simple > mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts > the server and installs all libraries, the rest is documented in the github > repo readme. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4496) Server side Websocket/Push Implementation not working
Werner Punz created MYFACES-4496: Summary: Server side Websocket/Push Implementation not working Key: MYFACES-4496 URL: https://issues.apache.org/jira/browse/MYFACES-4496 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.0.0-RC2 Reporter: Werner Punz While fixing several reported bugs in the new faces.js code I ran against a non working push implementation on the 4.0.0-RC2 codebase. Problem was a simple new WebSocket() could not establish a working connection. The problem is definitely somewhere in the server, either not registering the Websocket endpoint or delivering the wrong connection token. A example implemented via the Websocket servlet api and plain html works in the same configuration, se we can rule out the server environment (Embedded Tomcat 10). You can use straight the code from master to replicate this problem (I have decorated the faces.js api accordingly just to try a connection on the jsf side instead of going into the code) An example can be found at: [https://github.com/werpu/websocketproblem] Run instructions are included in the integrated readme, it uses an embedded tomcat/openwebbeans/myfaces 4.0.0 stack so a simple mvn clean clean install -DskipTests exec:java -Pstandalone -f pom.xml starts the server and installs all libraries, the rest is documented in the github repo readme. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling
[ https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17621124#comment-17621124 ] Werner Punz commented on MYFACES-4487: -- Fixed in the branch by adding another chained resource loader the map file transformation is only active on the faces.js resource and only in development mode > faces.js/ts new codebase, improve mapping handling > -- > > Key: MYFACES-4487 > URL: https://issues.apache.org/jira/browse/MYFACES-4487 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > Fix For: 4.0.0-RC3 > > > In our git pull request we use a specialized Faces servlet mapping jsf_map to > enable the mapping functionality. > Now this is suboptimal, if we do not enable this mapping we still get errors > in the browser log that a mapping file could not be loaded. > A better way would be to provide the functionality probably is a switchable > resource handler, wich adds the mapping info depending on the request data. > This must be documented one way or the other that we have this functionality > once merged. > (Impl functionality) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling
[ https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4487. -- Resolution: Fixed > faces.js/ts new codebase, improve mapping handling > -- > > Key: MYFACES-4487 > URL: https://issues.apache.org/jira/browse/MYFACES-4487 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > Fix For: 4.0.0-RC3 > > > In our git pull request we use a specialized Faces servlet mapping jsf_map to > enable the mapping functionality. > Now this is suboptimal, if we do not enable this mapping we still get errors > in the browser log that a mapping file could not be loaded. > A better way would be to provide the functionality probably is a switchable > resource handler, wich adds the mapping info depending on the request data. > This must be documented one way or the other that we have this functionality > once merged. > (Impl functionality) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling
[ https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620973#comment-17620973 ] Werner Punz edited comment on MYFACES-4487 at 10/20/22 9:58 AM: I have the resource wrapper now working in my github project which does the mapping file remapping. We probably do not even have to document it. As far as I recall there already is a chain active in the impl code where we can add the wrapper for dev mode (prod mode for now will not get any mapping file support, probably unwanted for prod due to causing extra requests) was (Author: werpu): I have the resource wrapper now working which does the mapping file remapping. We probably do not even have to document it. As far as I recall there already is a chain active in the impl code where we can add the wrapper for dev mode (prod mode for now will not get any mapping file support, probably unwanted for prod due to causing extra requests) > faces.js/ts new codebase, improve mapping handling > -- > > Key: MYFACES-4487 > URL: https://issues.apache.org/jira/browse/MYFACES-4487 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Priority: Major > > In our git pull request we use a specialized Faces servlet mapping jsf_map to > enable the mapping functionality. > Now this is suboptimal, if we do not enable this mapping we still get errors > in the browser log that a mapping file could not be loaded. > A better way would be to provide the functionality probably is a switchable > resource handler, wich adds the mapping info depending on the request data. > This must be documented one way or the other that we have this functionality > once merged. > (Impl functionality) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling
[ https://issues.apache.org/jira/browse/MYFACES-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620973#comment-17620973 ] Werner Punz commented on MYFACES-4487: -- I have the resource wrapper now working which does the mapping file remapping. We probably do not even have to document it. As far as I recall there already is a chain active in the impl code where we can add the wrapper for dev mode (prod mode for now will not get any mapping file support, probably unwanted for prod due to causing extra requests) > faces.js/ts new codebase, improve mapping handling > -- > > Key: MYFACES-4487 > URL: https://issues.apache.org/jira/browse/MYFACES-4487 > Project: MyFaces Core > Issue Type: New Feature >Reporter: Werner Punz >Priority: Major > > In our git pull request we use a specialized Faces servlet mapping jsf_map to > enable the mapping functionality. > Now this is suboptimal, if we do not enable this mapping we still get errors > in the browser log that a mapping file could not be loaded. > A better way would be to provide the functionality probably is a switchable > resource handler, wich adds the mapping info depending on the request data. > This must be documented one way or the other that we have this functionality > once merged. > (Impl functionality) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4487) faces.js/ts new codebase, improve mapping handling
Werner Punz created MYFACES-4487: Summary: faces.js/ts new codebase, improve mapping handling Key: MYFACES-4487 URL: https://issues.apache.org/jira/browse/MYFACES-4487 Project: MyFaces Core Issue Type: New Feature Reporter: Werner Punz In our git pull request we use a specialized Faces servlet mapping jsf_map to enable the mapping functionality. Now this is suboptimal, if we do not enable this mapping we still get errors in the browser log that a mapping file could not be loaded. A better way would be to provide the functionality probably is a switchable resource handler, wich adds the mapping info depending on the request data. This must be documented one way or the other that we have this functionality once merged. (Impl functionality) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test
[ https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4482. -- Fix Version/s: 2.3-next-M8 4.0.0-RC3 Resolution: Fixed was a test issue > jsf.js and faces.js old codebase fails on my decorator integration test > --- > > Key: MYFACES-4482 > URL: https://issues.apache.org/jira/browse/MYFACES-4482 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0-RC1 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > Fix For: 2.3-next-M8, 4.0.0-RC3 > > > I have a set of integration tests which are currently hosted in a pull > request for 4.0 > While the tests pass for the new codebase entirely, for the old one they fail > on > test-12 decoration, which tests whether the decorated apis are called > correctly. > This could be an issue with the testcases, but more likely we have a small > bug in the old implementation which bypasses the api for one of the testcases > and calls the impl directly. > We had several bugs in this area in the past, when people started to decorate > the apis. Hence I wrote this test to begin with. > I will work on this issue on monday and get this fixed either in the test or > in the old soon to be legacy codebase. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test
[ https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618728#comment-17618728 ] Werner Punz edited comment on MYFACES-4482 at 10/17/22 8:51 AM: Turned out to be a small bug in the test codebase. The getViewState decoration, did not return a value. The new codebase seems to be more forgiving regarding an empty viewstate than the old one. Both are valid implementations, this is just a slight variation in how to handle the case of an undefined viewstate (which should not happen anyway) Will fix this for the pull request 4476, given it only affects the codebase for the integration tests not the implementation itself was (Author: werpu): Turned out to be a small bug in the test codebase. The getViewState decoration, did not return a value. The new codebase seems to be more forgiving regarding an empty viewstate than the old one. Both are valid implementations, this is just a slight variation in how to handle the case of an undefined viewstate (which should not happen anyway) > jsf.js and faces.js old codebase fails on my decorator integration test > --- > > Key: MYFACES-4482 > URL: https://issues.apache.org/jira/browse/MYFACES-4482 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0-RC1, 2.3-next-M7 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > I have a set of integration tests which are currently hosted in a pull > request for 4.0 > While the tests pass for the new codebase entirely, for the old one they fail > on > test-12 decoration, which tests whether the decorated apis are called > correctly. > This could be an issue with the testcases, but more likely we have a small > bug in the old implementation which bypasses the api for one of the testcases > and calls the impl directly. > We had several bugs in this area in the past, when people started to decorate > the apis. Hence I wrote this test to begin with. > I will work on this issue on monday and get this fixed either in the test or > in the old soon to be legacy codebase. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test
[ https://issues.apache.org/jira/browse/MYFACES-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618728#comment-17618728 ] Werner Punz commented on MYFACES-4482: -- Turned out to be a small bug in the test codebase. The getViewState decoration, did not return a value. The new codebase seems to be more forgiving regarding an empty viewstate than the old one. Both are valid implementations, this is just a slight variation in how to handle the case of an undefined viewstate (which should not happen anyway) > jsf.js and faces.js old codebase fails on my decorator integration test > --- > > Key: MYFACES-4482 > URL: https://issues.apache.org/jira/browse/MYFACES-4482 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 4.0.0-RC1, 2.3-next-M7 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > > I have a set of integration tests which are currently hosted in a pull > request for 4.0 > While the tests pass for the new codebase entirely, for the old one they fail > on > test-12 decoration, which tests whether the decorated apis are called > correctly. > This could be an issue with the testcases, but more likely we have a small > bug in the old implementation which bypasses the api for one of the testcases > and calls the impl directly. > We had several bugs in this area in the past, when people started to decorate > the apis. Hence I wrote this test to begin with. > I will work on this issue on monday and get this fixed either in the test or > in the old soon to be legacy codebase. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4482) jsf.js and faces.js old codebase fails on my decorator integration test
Werner Punz created MYFACES-4482: Summary: jsf.js and faces.js old codebase fails on my decorator integration test Key: MYFACES-4482 URL: https://issues.apache.org/jira/browse/MYFACES-4482 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.3-next-M7, 4.0.0-RC1 Reporter: Werner Punz Assignee: Werner Punz I have a set of integration tests which are currently hosted in a pull request for 4.0 While the tests pass for the new codebase entirely, for the old one they fail on test-12 decoration, which tests whether the decorated apis are called correctly. This could be an issue with the testcases, but more likely we have a small bug in the old implementation which bypasses the api for one of the testcases and calls the impl directly. We had several bugs in this area in the past, when people started to decorate the apis. Hence I wrote this test to begin with. I will work on this issue on monday and get this fixed either in the test or in the old soon to be legacy codebase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617690#comment-17617690
]
Werner Punz commented on MYFACES-4479:
--
Done and fixed for main as well, which means it should go into the next rc!
I am closing the issue now.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617650#comment-17617650
]
Werner Punz edited comment on MYFACES-4479 at 10/14/22 12:00 PM:
-
The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.
I will also crossport the fix for RC2
was (Author: werpu):
The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.
Question is are we going to take the fix in also for RC2 or are we going to
wait for RC3 to have it automatically with the new scripts?
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617650#comment-17617650
]
Werner Punz commented on MYFACES-4479:
--
The fix is in for 2.3 next and the new 4.0RC3 codebase, please test it.
Question is are we going to take the fix in also for RC2 or are we going to
wait for RC3 to have it automatically with the new scripts?
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
]
Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:23 AM:
I have added the tests and fixes to my pull requests for the integrationtests
and the new typescript scripts (all in the pull requests which are pending for
RC3).
I will now tackle the old codebase.
When fixing this on my new code, I noticed that the fixes proposed in the patch
do not suffice entirely, because "nonce" is not handled properly for embedded
scripts (which are concatenated and then executed as once via the global nonce
we have for jsf.jsf
This works, if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
* failing nonce, for script src,
* non failing nonce for script src,
* and the same for embedded scripts
So my plan for today is:
I will backport my intrgration tests to JSF 2.3 and then will take the patches
in and fix the eval behavior as well.
The 4.0 codebase is working already and committed, you can get the code from
the pull request.
Question is, since we are going to migrate the code anyway for 4.0 RC3 to the
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as
well?
There is not too much sense to perform this extra work in this case given that
the code soon will be dropped anyway.
2.3 is out of the question we are not going to migrate despite having the
possibility (I have a working 2.3 version of my new code in my github project)
was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase.
When fixing this on my new code, I noticed that the fixes proposed in the patch
do not suffice entirely, because nonce is not handled properly for embedded
scripts (which are concatenated and then executed as once via the global nonce
we have for jsf.js)
This works, if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
* failing nonce, for script src,
* non failing nonce for script src,
* and the same for embedded scripts
So my plan for today is:
I will backport my intrgration tests to JSF 2.3 and then will take the patches
in and fix the eval behavior as well.
The 4.0 codebase is working already and committed, you can get the code from
the pull request.
Question is, since we are going to migrate the code anyway for 4.0 RC3 to the
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as
well?
There is not too much sense to perform this extra work in this case given that
the code soon will be dropped anyway.
2.3 is out of the question we are not going to migrate despite having the
possibility (I have a working 2.3 version of my new code in my github project)
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
]
Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:22 AM:
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase.
When fixing this on my new code, I noticed that the fixes proposed in the patch
do not suffice entirely, because nonce is not handled properly for embedded
scripts (which are concatenated and then executed as once via the global nonce
we have for jsf.js)
This works, if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
* failing nonce, for script src,
* non failing nonce for script src,
* and the same for embedded scripts
So my plan for today is:
I will backport my intrgration tests to JSF 2.3 and then will take the patches
in and fix the eval behavior as well.
The 4.0 codebase is working already and committed, you can get the code from
the pull request.
Question is, since we are going to migrate the code anyway for 4.0 RC3 to the
new Typescript code, are we going to fix this for 4.0RC2 on the old codebase as
well?
There is not too much sense to perform this extra work in this case given that
the code soon will be dropped anyway.
2.3 is out of the question we are not going to migrate despite having the
possibility (I have a working 2.3 version of my new code in my github project)
was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase. When fixing this on my new code, I noticed
that the fixes proposed in the patch do not suffice entirely, because nonce is
not handled properly for embedded scripts (which are concatenated and then
executed as once via the global nonce we have for jsf.js)
This works if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
(failing nonce, for script src, non failing nonce for script src, and the same
for embedded scripts)
So my plan for today is, I will backport my intrgration tests to jsf 2.3 and
then will take the patches in and fix the eval behavior as well.
The 4.0 codebase is working already and comitted, you can get the code from the
pull request. Question is, since we are going to migrate the code anyway for
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the
old codebase?
There is not too much sense to perform this extra work in this case.
2.3 is out of the question we are not going to migrate despite having the
possibility (I have a working 2.3 version of my new code in my github project)
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
]
Werner Punz edited comment on MYFACES-4479 at 10/14/22 7:19 AM:
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase. When fixing this on my new code, I noticed
that the fixes proposed in the patch do not suffice entirely, because nonce is
not handled properly for embedded scripts (which are concatenated and then
executed as once via the global nonce we have for jsf.js)
This works if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
(failing nonce, for script src, non failing nonce for script src, and the same
for embedded scripts)
So my plan for today is, I will backport my intrgration tests to jsf 2.3 and
then will take the patches in and fix the eval behavior as well.
The 4.0 codebase is working already and comitted, you can get the code from the
pull request. Question is, since we are going to migrate the code anyway for
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the
old codebase?
There is not too much sense to perform this extra work in this case.
2.3 is out of the question we are not going to migrate despite having the
possibility (I have a working 2.3 version of my new code in my github project)
was (Author: werpu):
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase. When fixing this on my new code, I noticed
that the fixes proposed in the patch do not suffice entirely, because nonce is
not handled properly for embedded scripts (which are concatenated and then
executed as once via the global nonce we have for jsf.js)
This works if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
(failing nonce, for script src, non failing nonce for script src, and the same
for embedded scripts)
So my plan for today is, I will backport my intrgration tests to jsf 2.3 and
then will take the patches in and fix the eval behavior as well.
The 4.0 codebase is working already and comitted, you can get the code from the
pull request. Question is, since we are going to migrate the code anyway for
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the
old codebase?
There is not too much sense to perform this extra work in this case.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617529#comment-17617529
]
Werner Punz commented on MYFACES-4479:
--
I have added the tests and fixes to my pull requests for the integrationtests
and the new scripts.
I will now tackle the old codebase. When fixing this on my new code, I noticed
that the fixes proposed in the patch do not suffice entirely, because nonce is
not handled properly for embedded scripts (which are concatenated and then
executed as once via the global nonce we have for jsf.js)
This works if the embedded script is not "nonced" but if there is a nonce flag
we have to pull out of this scheme and eval with the nonce it has (and eval the
concatenated scripts before)
I added 4 cases to my tests to handle the 4 possible scenarii
(failing nonce, for script src, non failing nonce for script src, and the same
for embedded scripts)
So my plan for today is, I will backport my intrgration tests to jsf 2.3 and
then will take the patches in and fix the eval behavior as well.
The 4.0 codebase is working already and comitted, you can get the code from the
pull request. Question is, since we are going to migrate the code anyway for
4.0 RC3 to the new typescript code, are we going to fix this for 4.0RC2 on the
old codebase?
There is not too much sense to perform this extra work in this case.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617180#comment-17617180
]
Werner Punz edited comment on MYFACES-4479 at 10/13/22 4:38 PM:
Thanks for changing the versions, I already have the fix working for the 4.0
scripts and
a set of tests on top of it.
Will cross check the old codebase tomorrow.
Expect both to be fixed sometime tomorrow and a set of new tests in the
integration testsuite.
was (Author: werpu):
Thanks for changing the versions, I already have the fix working for the 4.0
scripts and
a set of tests on top of it.
Will cross check the old codebase tomorrow.
Expect both to be fixed sometime tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617180#comment-17617180
]
Werner Punz commented on MYFACES-4479:
--
Thanks for changing the versions, I already have the fix working for the 4.0
scripts and
a set of tests on top of it.
Will cross check the old codebase tomorrow.
Expect both to be fixed sometime tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC1, 2.3.10, 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
]
Werner Punz edited comment on MYFACES-4479 at 10/13/22 1:24 PM:
So first of all thanks for reporting the bug, this went under my radar.
I have a small testcase working, which needs to be fleshed out more., following,
at the first look, I have to run the tests, your patch seems valid
item.getAttribute("nonce") does not work anymore
but item.nonce still returns the nonce value.
I have the same issue in my new code, respectively its underlying baselib.
I will test your pull request once my new testcase is properly integrated and
if all is well, I will merge it tomorrow.
I also have to fix the faces_ts nextgen codebase for 4.0.
Either way I expect the api to still change in this area probably again,
because for me moving item.getAttribute("nonce") to item.nonce is only half a
fix, you cannot see the nonce anymore in the browser dom but you still can
reach it on dom level via a small issued js element.nonce.
was (Author: werpu):
So first of all thanks for reporting the bug, this went under my radar.
I have a small testcase working, which needs to be fleshed out more., following,
at the first look, I have to run the tests, your patch seems valid
item.getAttribute("nonce") does not work anymore
but item.nonce still returns the nonce value.
I have the same issue in my new code, respectively its underlying baselib.
I will test your pull request once my new testcase is properly integrated and
if all is well, I will merge it tomorrow.
I also have to fix the faces_ts nextgen codebase for 4.0.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
]
Werner Punz edited comment on MYFACES-4479 at 10/13/22 1:22 PM:
So first of all thanks for reporting the bug, this went under my radar.
I have a small testcase working, which needs to be fleshed out more., following,
at the first look, I have to run the tests, your patch seems valid
item.getAttribute("nonce") does not work anymore
but item.nonce still returns the nonce value.
I have the same issue in my new code, respectively its underlying baselib.
I will test your pull request once my new testcase is properly integrated and
if all is well, I will merge it tomorrow.
I also have to fix the faces_ts nextgen codebase for 4.0.
was (Author: werpu):
I have a small testcase working, which needs to be fleshed out more., following,
at the first look, I have to run the tests, your patch seems valid
item.getAttribute("nonce") does not work anymore
but item.nonce still returns the nonce value.
I have the same issue in my new code, respectively its underlying baselib.
I will test your pull request once my new testcase is properly integrated and
if all is well, I will merge it tomorrow.
I also have to fix the faces_ts nextgen codebase for 4.0.
So first of all thanks for reporting the bug, this went under my radar.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617048#comment-17617048
]
Werner Punz commented on MYFACES-4479:
--
I have a small testcase working, which needs to be fleshed out more., following,
at the first look, I have to run the tests, your patch seems valid
item.getAttribute("nonce") does not work anymore
but item.nonce still returns the nonce value.
I have the same issue in my new code, respectively its underlying baselib.
I will test your pull request once my new testcase is properly integrated and
if all is well, I will merge it tomorrow.
I also have to fix the faces_ts nextgen codebase for 4.0.
So first of all thanks for reporting the bug, this went under my radar.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617036#comment-17617036
]
Werner Punz commented on MYFACES-4479:
--
I will check it once I have my testcase in place.
So expect an answer from me tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617011#comment-17617011
]
Werner Punz commented on MYFACES-4479:
--
I also will add a testcase for this in our integration testsuite, which is
pending for merge.
Seems like this spec is changing a lot.
And yes newer browsers seem to break the nonce handling for security reasons,
we probably have to take special care for that during our script evaluation.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
]
Werner Punz edited comment on MYFACES-4479 at 10/13/22 12:22 PM:
-
I will have a look at it, both for the old and for the 4.0 scripts.
A fix will be available probably by tomorrow.
was (Author: werpu):
I will have a look at it, both for the old and for the 4.0 scripts.
A fix will be available probably by tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
]
Werner Punz edited comment on MYFACES-4479 at 10/13/22 11:59 AM:
-
I will have a look at it, both for the old and for the 4.0 scripts.
A fix will be available probably by tomorrow.
was (Author: werpu):
I will have a look at it, both for the old and for the 4.0 scripts.
I remember we had a similar issue before, might have been a regression which
went in.
A fix will be available probably by tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Assignee: Werner Punz
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4479) The jsf.js script does not read the nonce correctly in modern browsers.
[
https://issues.apache.org/jira/browse/MYFACES-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616988#comment-17616988
]
Werner Punz commented on MYFACES-4479:
--
I will have a look at it, both for the old and for the 4.0 scripts.
I remember we had a similar issue before, might have been a regression which
went in.
A fix will be available probably by tomorrow.
> The jsf.js script does not read the nonce correctly in modern browsers.
> ---
>
> Key: MYFACES-4479
> URL: https://issues.apache.org/jira/browse/MYFACES-4479
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 2.3-next-M7
> Environment: Myfaces 2.3-next-M7
> Chrome: 106.0.5249.103
>Reporter: Vitaly Sidorov
>Priority: Major
>
> In Chrome it is no longer possible to get a nonce with getAttribute("nonce").
> You can only use HTMLElement.nonce (see:
> [https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/nonce)]
> Steps to reproduce:
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set target="head"/>
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and get multiple errors in console:
> {{jsf.js.jsf?ln=javax.faces=Development:93 Refused to execute inline
> script because it violates the following Content Security Policy directive:
> "script-src 'self' 'nonce=test123'". Either the 'unsafe-inline' keyword, a
> hash ('sha256-Xu6aRWi9bDVg9FaanKbn/uUSQUCsJ5g+bPB5SUYUIfk='), or a nonce
> ('nonce-...') is required to enable inline execution.}}
> The reason:
> The error falls on .appendChild(element) in code
> {{var htmlScriptElement = document.head.appendChild(element);}}
> {{document.head.removeChild(htmlScriptElement);}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4478) namespace bug for faces 4.0 and composite components
[ https://issues.apache.org/jira/browse/MYFACES-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17615709#comment-17615709 ] Werner Punz commented on MYFACES-4478: -- Reproducible example: Checkout [https://github.com/werpu/myfaces-js-integrationtests/tree/MYFACES-4478] and run the server via: clean clean install -DskipTests exec:java -Pstandalone -f pom.xml You can expose the bug via: [http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test1-protocol-4478.jsf] while calling: [http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test1-protocol.jsf] works. The first case uses the faces namespace to reference the composite component, the second case uses the jcp namespace. > namespace bug for faces 4.0 and composite components > > > Key: MYFACES-4478 > URL: https://issues.apache.org/jira/browse/MYFACES-4478 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 3.0.0-RC1 > Environment: normal servlet environment >Reporter: Werner Punz >Priority: Minor > > Composite Components atm only work in the > [http://xmlns.jcp.org/jsf/composite/] namespace but not in the > jakarta.faces.composite namespace, as required per Faces 4.0 spec. > > I will link an example in a later comment once setup which shows this behavior > a composite component hostet under webapp/resources is found in the jcp > namespace but not in the new jakarta faces namespace, so: > components="jakarta.faces.composite/components" produces following error: > * Warning: The page /integrationtestsjasmine/test1-protocol.xhtml declares > namespace jakarta.faces.composite/components and uses the tag > components:jasmineTest , but no TagLibrary associated to namespace. > on > > http://www.w3.org/1999/xhtml; > xmlns:h="jakarta.faces.html" > xmlns:ui="jakarta.faces.facelets" > xmlns:components="jakarta.faces.composite/components" > > > > > The namespace > http://www.w3.org/1999/xhtml; > xmlns:h="jakarta.faces.html" > xmlns:ui="jakarta.faces.facelets" > xmlns:components="http://xmlns.jcp.org/jsf/composite/components; > > > > Produces no error. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4478) namespace bug for faces 4.0 and composite components
Werner Punz created MYFACES-4478: Summary: namespace bug for faces 4.0 and composite components Key: MYFACES-4478 URL: https://issues.apache.org/jira/browse/MYFACES-4478 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 3.0.0-RC1 Environment: normal servlet environment Reporter: Werner Punz Composite Components atm only work in the [http://xmlns.jcp.org/jsf/composite/] namespace but not in the jakarta.faces.composite namespace, as required per Faces 4.0 spec. I will link an example in a later comment once setup which shows this behavior a composite component hostet under webapp/resources is found in the jcp namespace but not in the new jakarta faces namespace, so: components="jakarta.faces.composite/components" produces following error: * Warning: The page /integrationtestsjasmine/test1-protocol.xhtml declares namespace jakarta.faces.composite/components and uses the tag components:jasmineTest , but no TagLibrary associated to namespace. on http://www.w3.org/1999/xhtml; xmlns:h="jakarta.faces.html" xmlns:ui="jakarta.faces.facelets" xmlns:components="jakarta.faces.composite/components" > The namespace http://www.w3.org/1999/xhtml; xmlns:h="jakarta.faces.html" xmlns:ui="jakarta.faces.facelets" xmlns:components="http://xmlns.jcp.org/jsf/composite/components; > Produces no error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4476) Integration of the full integration testsuite for faces.js from github
Werner Punz created MYFACES-4476: Summary: Integration of the full integration testsuite for faces.js from github Key: MYFACES-4476 URL: https://issues.apache.org/jira/browse/MYFACES-4476 Project: MyFaces Core Issue Type: New Feature Components: General Affects Versions: 4.0.0-RC2 Reporter: Werner Punz Assignee: Werner Punz We have a set of 20 integration tests against the faces.js codebase on github. This testuite was one of my cornerstones for fortifying the old and new implementation. The problem was it used homegrown testing frameworks. I now have moved all the tests to npm and mocha with an embedded chrome as testrunner. The project on github has everything integrated into maven and starts its own embedded tomcat during testing. It bypasses Arquilian entirely (results in less code because less java code is involved). After questioning the mailing list whether myfaces wants the test suite, they agreed to wanting them. I will move the code over to myfaces and then issue a pull request for further discussion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4473) Integration Tests dependency issue
Werner Punz created MYFACES-4473: Summary: Integration Tests dependency issue Key: MYFACES-4473 URL: https://issues.apache.org/jira/browse/MYFACES-4473 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.0.0-RC1 Environment: Java 11 Reporter: Werner Punz The integration tests atm, have a problem with a servlet implementation coming in, not reflecting the actual layer. SCHWERWIEGEND: Servlet.service() for servlet [FacesServlet] in context with path [/ajax-4.0.0-SNAPSHOT] threw exception ['java.lang.String jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String)'] with root cause java.lang.NoSuchMethodError: 'java.lang.String jakarta.servlet.SessionCookieConfig.getAttribute(java.lang.String)' at org.apache.myfaces.context.flash.FlashImpl._createFlashCookie(FlashImpl.java:1194) at org.apache.myfaces.context.flash.FlashImpl._saveRenderFlashMapTokenForNextRequest(FlashImpl.java:774) at org.apache.myfaces.context.flash.FlashImpl._manageFlashMapTokens(FlashImpl.java:889) at org.apache.myfaces.context.flash.FlashImpl.doPrePhaseActions(FlashImpl.java:197) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:155) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:125) at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:223) The called api is present, but somewhere still an old servlet impl is pushed into the container. I have tried to upgrade to tomcat embedded 10, no dice. The api is correctly referenced though and I can see it from the ide. My idea is that Aquilian might push an old servlet definition in during runtime. Also the currently used Aquilian is incompatible with the latest jdks. (Proxy mechanism, which is used causes errors on the latest jdk) I am still searching where the issue stems from, but so far no luck on my side. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
[
https://issues.apache.org/jira/browse/MYFACES-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612584#comment-17612584
]
Werner Punz edited comment on MYFACES-4471 at 10/4/22 12:13 PM:
For this issue, no.
Some else can take over it. I never did anything in the ViewState handling area.
A simple check for an incoming null fixed it, but given that probably a wrong
state internally is referenced, this needs to be fixed on a higher level.
(aka a state number was coming in, wich did not exist anymore)
was (Author: werpu):
For this issue, no.
Some else can take over it. I never did anything in the ViewState handling area.
> java.lang.NullPointerException at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> --
>
> Key: MYFACES-4471
> URL: https://issues.apache.org/jira/browse/MYFACES-4471
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC2
> Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot)
> before RC2
>Reporter: Werner Punz
>Priority: Major
>
> During my integration testing for the new scripts I ran into this issue.
> It seems that some viewstate "pointers" are not cleared up properly in my
> test case, and reference after a while state entries which have dropped out
> of the state history.
> The problem is not related to my scripts, because the same test works for jsf
> 2.3 flawlessly with the same scripts and a 2.3 shim. So the Javascript code
> executed is the same.
> Reproducible:
> [https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug]
> then run the project via mvn clean clean install exec:java -f pom.xml
> then point your browser to:
> [http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]
>
>
> or follow the link to the loop navigation test in the index.html
> The test case performs an implicit Ajax navigation by sending a faces.request
> execute on a command link, which triggers the navigation.
> Note, only the command link is sent as execute not the entire form, but the
> entire form is refreshed.
>
> Let it run, after roughly a minute you should get following error:
>
> java.lang.NullPointerException
> viewId=/loop/test8-navcase1.xhtml
> location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
>
> Stack Trace:
> {{java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
> at
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
> at
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
> at
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
> at
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
> at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
> at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
> at
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
> at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
> at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
> at
>
[jira] [Commented] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
[
https://issues.apache.org/jira/browse/MYFACES-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612584#comment-17612584
]
Werner Punz commented on MYFACES-4471:
--
For this issue, no.
Some else can take over it. I never did anything in the ViewState handling area.
> java.lang.NullPointerException at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> --
>
> Key: MYFACES-4471
> URL: https://issues.apache.org/jira/browse/MYFACES-4471
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 4.0.0-RC2
> Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot)
> before RC2
>Reporter: Werner Punz
>Priority: Major
>
> During my integration testing for the new scripts I ran into this issue.
> It seems that some viewstate "pointers" are not cleared up properly in my
> test case, and reference after a while state entries which have dropped out
> of the state history.
> The problem is not related to my scripts, because the same test works for jsf
> 2.3 flawlessly with the same scripts and a 2.3 shim. So the Javascript code
> executed is the same.
> Reproducible:
> [https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug]
> then run the project via mvn clean clean install exec:java -f pom.xml
> then point your browser to:
> [http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]
>
>
> or follow the link to the loop navigation test in the index.html
> The test case performs an implicit Ajax navigation by sending a faces.request
> execute on a command link, which triggers the navigation.
> Note, only the command link is sent as execute not the entire form, but the
> entire form is refreshed.
>
> Let it run, after roughly a minute you should get following error:
>
> java.lang.NullPointerException
> viewId=/loop/test8-navcase1.xhtml
> location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
> phaseId=RENDER_RESPONSE(6)
> Caused by:
> java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
>
> Stack Trace:
> {{java.lang.NullPointerException
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
> at
> org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
> at
> org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
> Source)
> at
> org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
> at
> org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
> at
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
> at
> org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
> at
> org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
> at
> org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
> at
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
> at
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
> at
> jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
> at
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
> at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
> at
>
[jira] [Commented] (TOBAGO-2158) Use jsf-development.js in development environments
[ https://issues.apache.org/jira/browse/TOBAGO-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612578#comment-17612578 ] Werner Punz commented on TOBAGO-2158: - Already implemented for MyFaces in my pull request. Also i enabled the mapping files accordingly, see my pull request comments, you might take an idea or 2 from there. > Use jsf-development.js in development environments > -- > > Key: TOBAGO-2158 > URL: https://issues.apache.org/jira/browse/TOBAGO-2158 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Themes >Affects Versions: 5.2.0 >Reporter: Henning Nöth >Assignee: Henning Nöth >Priority: Minor > > The "jsf.js_next_gen" Dependency provide a "jsf.js" and a > "jsf-development.js". > We should use the "jsf-development.js" in development environments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4471) java.lang.NullPointerException at org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
Werner Punz created MYFACES-4471:
Summary: java.lang.NullPointerException at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
Key: MYFACES-4471
URL: https://issues.apache.org/jira/browse/MYFACES-4471
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 4.0.0-RC2
Environment: Java 9 or higher, MyFaces 4.0 main branch (snapshot)
before RC2
Reporter: Werner Punz
During my integration testing for the new scripts I ran into this issue.
It seems that some context "pointers" are not cleared up properly in my
testcase and reference after a while context entries which have dropped out of
the state history.
The problem is not related to my scripts, because the same test works for jsf
2.3 flawlessly with the same scripts and a 2.3 shim. So the javascript code
executed is the same.
Reproducible:
https://github.com/werpu/myfaces-js-integrationtests/tree/faces_40_viestate_bug
then run the project via mvn clean clean install exec:java -f pom.xml
then point your browser to:
[http://localhost:8080/IntegrationJSTest/loop/test8-navcase1.jsf?autoTest=true]
or follow the link to the loop navigation test in the index.html
Let it run, after roughly a minute you should get following error:
java.lang.NullPointerException
viewId=/loop/test8-navcase1.xhtml
location=/Users/werpu2/development/workspace/myfaces-js-integrationtests/src/main/webapp/loop/test8-navcase1.xhtml
phaseId=RENDER_RESPONSE(6)
Caused by:
java.lang.NullPointerException
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
Stack Trace:
{{java.lang.NullPointerException
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:201)
at
org.apache.myfaces.cdi.util.AbstractContextualStorageHolder.destroyAll(AbstractContextualStorageHolder.java:242)
at
org.apache.myfaces.cdi.view.ViewScopeContextualStorageHolder$Proxy$_$$_WeldClientProxy.destroyAll(Unknown
Source)
at
org.apache.myfaces.cdi.view.ViewScopeContext.destroyAll(ViewScopeContext.java:202)
at
org.apache.myfaces.application.viewstate.SerializedViewCollection.lambda$put$1(SerializedViewCollection.java:71)
at
org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:228)
at
org.apache.myfaces.application.viewstate.SerializedViewCollection.put(SerializedViewCollection.java:70)
at
org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedViewInSession(StateCacheServerSide.java:196)
at
org.apache.myfaces.application.viewstate.StateCacheServerSide.saveSerializedView(StateCacheServerSide.java:465)
at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.saveState(HtmlResponseStateManager.java:107)
at
org.apache.myfaces.view.facelets.PartialStateManagementStrategy.saveView(PartialStateManagementStrategy.java:794)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1854)
at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:316)
at
jakarta.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:74)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:225)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:223)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:185)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:158)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:119)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:357)
at
[jira] [Created] (MYFACES-4466) Integration of the JSF_JS next gen scripts
Werner Punz created MYFACES-4466: Summary: Integration of the JSF_JS next gen scripts Key: MYFACES-4466 URL: https://issues.apache.org/jira/browse/MYFACES-4466 Project: MyFaces Core Issue Type: New Feature Affects Versions: 4.0.0-RC2 Reporter: Werner Punz Assignee: Werner Punz We have a full reimplemtation of the jsf.js scripts in the pipeline it is hosted atm under [https://github.com/werpu/jsfs_js_ts] The implementation is a 100% reimplementation of the original scripts, in typescript with maintainability and readability in its core. It cuts down heavily on old browser support for the same reason. The implementation has a good unit test coverage on javascript level and uses the latest state of the art build and test infrastructure based on node (mocha, webpack etc...) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4344) The _FormDataRequest.js is not part of jsf.js
[
https://issues.apache.org/jira/browse/MYFACES-4344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143194#comment-17143194
]
Werner Punz commented on MYFACES-4344:
--
Thanks I just saw the issue... You were faster than me.
> The _FormDataRequest.js is not part of jsf.js
> -
>
> Key: MYFACES-4344
> URL: https://issues.apache.org/jira/browse/MYFACES-4344
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M2
>Reporter: Jan Krpata
>Priority: Critical
> Fix For: 2.3-next-M3
>
>
> The _FormDataRequest.js is not part of jsf.js or other generated js files.
> The file path is incorrect in:
> * jsfscripts-compiler.xml
> * jsfscripts-minimal-compiler.xml
> * jsfscripts-uncompressed-full-compiler.xml
> * jsf-uncompressed.js
>
> My Error:
> {color:#9cdcfe}myfaces{color}{color:#d4d4d4}.{color}{color:#9cdcfe}_impl{color}{color:#d4d4d4}.{color}{color:#9cdcfe}xhrCore{color}{color:#d4d4d4}.{color}{color:#9cdcfe}_FormDataRequest{color}
> is undefined
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MYFACES-4323) Several tests failing under JDK 11
Werner Punz created MYFACES-4323: Summary: Several tests failing under JDK 11 Key: MYFACES-4323 URL: https://issues.apache.org/jira/browse/MYFACES-4323 Project: MyFaces Core Issue Type: Bug Reporter: Werner Punz Assignee: Werner Punz Several locale related tests and the beanvalidation tests fail under JDK11. The Locale tests fail because Java 9 introduced locale providers which follow standards, the tests were written against the java locale providers, so changing the tests to COMPAT should suffice. The bean validation tests fail because under Java 11 the order of the validators is reversed, someone else needs to have a deep look into this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MYFACES-4322) Body replace Ajax integration test failing
[ https://issues.apache.org/jira/browse/MYFACES-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4322. -- Resolution: Fixed > Body replace Ajax integration test failing > --- > > Key: MYFACES-4322 > URL: https://issues.apache.org/jira/browse/MYFACES-4322 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3-next-M1 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Major > Original Estimate: 3h > Remaining Estimate: 3h > > The first of the two body replacement integration test is failing. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MYFACES-4322) Body replace Ajax integration test failing
Werner Punz created MYFACES-4322: Summary: Body replace Ajax integration test failing Key: MYFACES-4322 URL: https://issues.apache.org/jira/browse/MYFACES-4322 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.3-next-M1 Reporter: Werner Punz Assignee: Werner Punz The first of the two body replacement integration test is failing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893425#comment-16893425
]
Werner Punz edited comment on MYFACES-4280 at 7/26/19 7:53 AM:
---
Yes and there is nothing I can do on the javascript side about it.
The problem there is the *onclick="jsf.util.chain(this,event
'jsf.ajax.request...)* call
When this was written there was no csp, and it was valid javascript, however
CSP does not allow such a construct anymore unless you ease the restrictions.
However this is relaxed per default on chrome while Firefox has the stricter
default security in this case. (and is probably the reason why sites sometimes
have non working submit buttons on fox)
The proper csp way would be following
<{color:#80}input {color}{color:#ff}type{color}{color:#008000}="button"
{color}{color:#ff}id{color}{color:#008000}="chaincall"
{color}{color:#ff}value{color}{color:#008000}="press for chaintest"{color}/>
<{color:#80}script
{color}{color:#ff}type{color}{color:#008000}="text/javascript"
{color}{color:#ff}nonce{color}{color:#008000}="booga"{color}>
{color:#660e7a}document{color}.{color:#7a7a43}getElementById{color}({color:#008000}"chaincall"{color}).{color:#660e7a}onclick
{color}= {color:#80}function{color}(event) {
var _t = this;
{color:#660e7a}jsf{color}.{color:#660e7a}util{color}.chain({color:#80}this{color},
event, function() { {color:#008000}javax.ajax.request(_t, event...) }{color});
{color:#80}return false{color};
}
Note not even in the nonce marked block a call to *jsf.util.chain(.. , 'script
to be evaled').*.. is possible anymore.
The reason lies within the nature of how the eval is possible.
An normal eval is with CSP not possible anymore, the head appendix method
literally everyone uses is still possible.
The problem with the head appendix method is, it is by nature asynchronous to
the javascript execution. While this poses normally no problem for chain it
does.
Chain requires a true or false return value for a single script. Now if a true
is returned the chain is properly executed with the next function/eval part. In
case of false it is not possible anymore and terminated prematurely. This is by
spec.
Now if we use the head appendix method this is done asynchronously and an
onDomReady handler should be used to go to the next step.
A proper solution would be to replace the true false return on the spec side
with promises, but for IE11 support we need a shim, since promises are not
supported natively by that browser. And also the spec needs to be reworked in
this area for proper csp support.
However what can we do now?
We probably have to replace our inline onclick handler with a nonced emvedded
javascript and apply the pattern I am proposing here.
I checked the specs, I could not find anything which points towards an
implementation with an onclick handler for the ajax behavior, but I might have
missed something.
If there is a spec enforcement it would be wise simply to add a csp context
param and adjust the f:ajax accordingly.
So thats all I can do for the moment. Someone else might have to pick up the
f:ajax side.
was (Author: werpu):
Yes and there is nothing I can do on the javascript side about it.
The problem there is the *onclick="jsf.util.chain(this,event
'jsf.ajax.request...)* call
When this was written there was no csp, and it was valid javascript the spec
also states clearly that, however CSP does not allow such a construct unless
you ease the restrictions.
However this is relaxed per default on chrome while Firefox has the stricter
default security in this case. (and is probably the reason why sites sometimes
have non working submit buttons on fox)
The proper csp way would be following
<{color:#80}input {color}{color:#ff}type{color}{color:#008000}="button"
{color}{color:#ff}id{color}{color:#008000}="chaincall"
{color}{color:#ff}value{color}{color:#008000}="press for chaintest"{color}/>
<{color:#80}script
{color}{color:#ff}type{color}{color:#008000}="text/javascript"
{color}{color:#ff}nonce{color}{color:#008000}="booga"{color}>
{color:#660e7a}document{color}.{color:#7a7a43}getElementById{color}({color:#008000}"chaincall"{color}).{color:#660e7a}onclick
{color}= {color:#80}function{color}(event) {
var _t = this;
{color:#660e7a}jsf{color}.{color:#660e7a}util{color}.chain({color:#80}this{color},
event, function() { {color:#008000}javax.ajax.request(_t, event...) }{color});
{color:#80}return false{color};
}
Note not even in the nonce marked block a call to *jsf.util.chain(.. , 'script
to be evaled').*.. is possible anymore.
The reason lies within the nature of how the eval is possible.
An normal eval is with CSP not possible anymore, the head appendix method
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893425#comment-16893425
]
Werner Punz commented on MYFACES-4280:
--
Yes and there is nothing I can do on the javascript side about it.
The problem there is the *onclick="jsf.util.chain(this,event
'jsf.ajax.request...)* call
When this was written there was no csp, and it was valid javascript the spec
also states clearly that, however CSP does not allow such a construct unless
you ease the restrictions.
However this is relaxed per default on chrome while Firefox has the stricter
default security in this case. (and is probably the reason why sites sometimes
have non working submit buttons on fox)
The proper csp way would be following
<{color:#80}input {color}{color:#ff}type{color}{color:#008000}="button"
{color}{color:#ff}id{color}{color:#008000}="chaincall"
{color}{color:#ff}value{color}{color:#008000}="press for chaintest"{color}/>
<{color:#80}script
{color}{color:#ff}type{color}{color:#008000}="text/javascript"
{color}{color:#ff}nonce{color}{color:#008000}="booga"{color}>
{color:#660e7a}document{color}.{color:#7a7a43}getElementById{color}({color:#008000}"chaincall"{color}).{color:#660e7a}onclick
{color}= {color:#80}function{color}(event) {
var _t = this;
{color:#660e7a}jsf{color}.{color:#660e7a}util{color}.chain({color:#80}this{color},
event, function() { {color:#008000}javax.ajax.request(_t, event...) }{color});
{color:#80}return false{color};
}
Note not even in the nonce marked block a call to *jsf.util.chain(.. , 'script
to be evaled').*.. is possible anymore.
The reason lies within the nature of how the eval is possible.
An normal eval is with CSP not possible anymore, the head appendix method
literally everyone uses is still possible.
The problem with the head appendix method is, it is by nature asynchronous to
the javascript execution. While this poses normally no problem for chain it
does.
Chain requires a true or false return value for a single script. Now if a true
is returned the chain is properly executed with the next function/eval part. In
case of false it is not possible anymore and terminated prematurely. This is by
spec.
Now if we use the head appendix method this is done asynchronously and an
onDomReady handler should be used to go to the next step.
A proper solution would be to replace the true false return on the spec side
with promises, but for IE11 support we need a shim, since promises are not
supported natively by that browser. And also the spec needs to be reworked in
this area for proper csp support.
However what can we do now?
We probably have to replace our inline onclick handler with a nonced emvedded
javascript and apply the pattern I am proposing here.
I checked the specs, I could not find anything which points towards an
implementation with an onclick handler for the ajax behavior, but I might have
missed something.
If there is a spec enforcement it would be wise simply to add a csp context
param and adjust the f:ajax accordingly.
So thats all I can do for the moment. Someone else might have to pick up the
f:ajax side.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888727#comment-16888727
]
Werner Punz edited comment on MYFACES-4280 at 7/19/19 9:13 AM:
---
Ok fixed, I now only apply the head appendix method as eval, and also pass the
nonce attribute wherever possible.
At least in my tests which resembles Thomas testcase it works now. My
integration tests also pass.
Please give my patches a proper run in real life, and then close this issue.
Also some now unused legacy code was dumped along the lines (RTQirks and the
global eval handling via eval instead of head append(
was (Author: werpu):
Ok fixed, I now only apply the head appendix method as eval, and also pass the
nonce attribute wherever possible.
At least in my tests which resembles Thomas testcase it works now. My
integration tests also pass.
Please give my patches a proper run in real life, and then close this issue.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888727#comment-16888727
]
Werner Punz edited comment on MYFACES-4280 at 7/19/19 9:13 AM:
---
Ok fixed, I now only apply the head appendix method as eval, and also pass the
nonce attribute wherever possible.
At least in my tests which resembles Thomas testcase it works now. My
integration tests also pass.
Please give my patches a proper run in real life, and then close this issue.
Also some now unused legacy code was dumped along the lines (RTQirks and the
global eval handling via eval instead of head append). Eval is an absolute no
go for CSP.
was (Author: werpu):
Ok fixed, I now only apply the head appendix method as eval, and also pass the
nonce attribute wherever possible.
At least in my tests which resembles Thomas testcase it works now. My
integration tests also pass.
Please give my patches a proper run in real life, and then close this issue.
Also some now unused legacy code was dumped along the lines (RTQirks and the
global eval handling via eval instead of head append(
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888727#comment-16888727
]
Werner Punz commented on MYFACES-4280:
--
Ok fixed, I now only apply the head appendix method as eval, and also pass the
nonce attribute wherever possible.
At least in my tests which resembles Thomas testcase it works now. My
integration tests also pass.
Please give my patches a proper run in real life, and then close this issue.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887965#comment-16887965
]
Werner Punz edited comment on MYFACES-4280 at 7/18/19 1:15 PM:
---
the issue is csp difference related.
Thomas provided me with an example.
The example worked in Chrome
It failed in firefox
The reason is that firefox prohibits eval per default while chrome allows it.
Now the myfaces codebase relies on eval to run the inline scripts
and generically fetch the namespace modules.
A short workaround would be to allow eval, a long fix probably will be to
investigate if there is an eval with nonce possible or a move to the header
appendix method only for everything eval and use nonce there.
I have to do some investigation on how to fix this properly. In the meanwhile
simply explicitely enable eval so that firefox and chrome have the same CSP
behavior.
was (Author: werpu):
the issue is csp difference related.
Thomas provided me with an example.
The example worked in Chrome
It failed in firefox
The reason is that firefox prohibits eval per default while chrome allows it.
Now the myfaces codebase relies on eval to run the inline scripts
and generically fetch the namespace modules.
A short workaround would be to allow eval, a long fix probably will be to
investigate if there is an eval with nonce possible or a move to the header
appendix method only for everything eval and use nonce there.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887965#comment-16887965
]
Werner Punz commented on MYFACES-4280:
--
the issue is csp difference related.
Thomas provided me with an example.
The example worked in Chrome
It failed in firefox
The reason is that firefox prohibits eval per default while chrome allows it.
Now the myfaces codebase relies on eval to run the inline scripts
and generically fetch the namespace modules.
A short workaround would be to allow eval, a long fix probably will be to
investigate if there is an eval with nonce possible or a move to the header
appendix method only for everything eval and use nonce there.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887916#comment-16887916
]
Werner Punz edited comment on MYFACES-4280 at 7/18/19 12:15 PM:
I am in contact with thomas, stopping it until I get an example. Cannot
reproduce it for the time being.
was (Author: werpu):
I am in contact with thomas, closing it until I get an example. Cannot
reproduce it for the time being.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887916#comment-16887916
]
Werner Punz commented on MYFACES-4280:
--
I am in contact with thomas, closing it until I get an example. Cannot
reproduce it for the time being.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887871#comment-16887871
]
Werner Punz edited comment on MYFACES-4280 at 7/18/19 10:53 AM:
Ok not even there. I probably need an example to reproduce that.
I will put this on hold until I have further info or an example.
Does this occur in a browser or just unit tests? Which browser?
was (Author: werpu):
Ok not even there. I probably need an example to reproduce that.
I will put this on hold until I have further info or an example.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887871#comment-16887871
]
Werner Punz commented on MYFACES-4280:
--
Ok not even there. I probably need an example to reproduce that.
I will put this on hold until I have further info or an example.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887854#comment-16887854
]
Werner Punz edited comment on MYFACES-4280 at 7/18/19 10:43 AM:
ok the only case this can occur according to the current codebase is a script
src tag this one simply goes through an eval stage where the nonce might be
lost.
was (Author: werpu):
ok loadScriptByBrowser is basically dead code, I will eliminate that one.
There the head appendix method basically is the last fallback which no modern
browser atm falls into since they all support eval.
I really would need a proper example here on how to trigger this via ajax. I
ran a set of tests and I could only trigger it by having embedded script tags
with no nonce attributes set. But this is hardly anything I can do something on
my side about. This needs a fix on outputscript if there is none already
present.
So here is my request. Can you provide a proper mini example (just one page)
with your exact case. A war suffices or even an xhtml page.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887862#comment-16887862
]
Werner Punz commented on MYFACES-4280:
--
I will put the work on this one on hold until I have further info.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887854#comment-16887854
]
Werner Punz commented on MYFACES-4280:
--
ok loadScriptByBrowser is basically dead code, I will eliminate that one.
There the head appendix method basically is the last fallback which no modern
browser atm falls into since they all support eval.
I really would need a proper example here on how to trigger this via ajax. I
ran a set of tests and I could only trigger it by having embedded script tags
with no nonce attributes set. But this is hardly anything I can do something on
my side about. This needs a fix on outputscript if there is none already
present.
So here is my request. Can you provide a proper mini example (just one page)
with your exact case. A war suffices or even an xhtml page.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887811#comment-16887811
]
Werner Punz edited comment on MYFACES-4280 at 7/18/19 9:58 AM:
---
It would be easier to tackle the issue with a proper working example. However
we have several parts where nonce needs to be added on the client side.
loadScriptByBrowser, the css loading part, and the eval fallback which utilizes
the head appendix method.
However this does not resolve the problem that nonce also must be added to
h:outputscript i cannot append nonce on the client side to scripts which come
in via ajax and h:outputscript.
The example must be the loadScriptByBrowser case, because a src attribute is
mentioned and this is the only script eval case where a browser rendering
engine fallback is performed instead of using eval and xhr
was (Author: werpu):
It would be easier to tackle the issue with a proper working example. However
we have several parts where nonce needs to be added on the client side.
loadScriptByBrowser, the css loading part, and the eval fallback which utilizes
the head appendix method.
However this does not resolve the problem that nonce also must be added to
h:outputscript i cannot append nonce on the client side to scripts which come
in via ajax and h:outputscript
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887811#comment-16887811
]
Werner Punz commented on MYFACES-4280:
--
It would be easier to tackle the issue with a proper working example. However
we have several parts where nonce needs to be added on the client side.
loadScriptByBrowser, the css loading part, and the eval fallback which utilizes
the head appendix method.
However this does not resolve the problem that nonce also must be added to
h:outputscript i cannot append nonce on the client side to scripts which come
in via ajax and h:outputscript
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887718#comment-16887718
]
Werner Punz commented on MYFACES-4280:
--
Just a short discussion start here, after reading up on nonce (this is coming
in from html5.1 hence it is not implemented yet). We need a proper way to deal
with it on the server as well. The issue is nonce should be used once for
security reasons.
Hence the ajax response probably will not issue updated nonce numbers. Which
means every request will recycle the initial nonce.
I for once will implement nonce as is by just checking for an existing page
nonce and forward it to the ajax request, but we might have to use the extends
flag in the response protocol for a new nonce from time to time. The issue is
that some old nonce might be issued before the updated nonce comes in. So I am
not sure how to resolve that properly, maybe by a nonce list and timestamp
which kills old nonce values after a fixed period of time.
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4280) CSP: nonce attribute on script tags will be ignored on ajax updates
[
https://issues.apache.org/jira/browse/MYFACES-4280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887637#comment-16887637
]
Werner Punz commented on MYFACES-4280:
--
I will tackle this one today
> CSP: nonce attribute on script tags will be ignored on ajax updates
> ---
>
> Key: MYFACES-4280
> URL: https://issues.apache.org/jira/browse/MYFACES-4280
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
>
> simple CSP case:
> - add a static nonce via phaselistener/servlerfilter in the headers
> - add the the static nonce to a script tag
> this works fine for a GET request or non-ajax POST but our ajax engine just
> ignores the nonce attribute on scripts and following error occurs in the
> browser:
> Content Security Policy: Die Einstellungen der Seite haben das Laden einer
> Ressource auf inline blockiert ("script-src").
> There will probably other tickets in the future but thats the first basic
> case which must be supported.
> There are of course other problems like onclick handlers in the DOM or the
> eval node in the partial-response.
> Similar to: https://github.com/jquery/jquery/issues/3541
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746217#comment-16746217 ] Werner Punz commented on MYFACES-4265: -- Ok i have started to move my github based integration tests over into myfaces. The first two tests are now in and running (basically low level protocol tests testing the xml based response protocol) I will move over all 23 testcases I have on github in the long run. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741652#comment-16741652 ] Werner Punz commented on MYFACES-4265: -- thanks > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741646#comment-16741646 ] Werner Punz commented on MYFACES-4265: -- yes... the iframe file upload method has been removed in favor of newer methods (form object) > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740319#comment-16740319 ] Werner Punz commented on MYFACES-4265: -- First small integration test added which checks for a proper import and checks for the namespace afterwards. I have a set of 20 integration tests hosted on github, they use jasmine, I will check the upcoming fridays how to move those over. It would make sense to have them in the integration testbase. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740261#comment-16740261 ] Werner Punz commented on MYFACES-4265: -- The double include of the sources now is fixed by readjusting our build a little bit. the sources are now only available in the internal-resources folder in the final jar and in the long run probably will be replaced by javascript maps. Also I removed the dynamic include build, no one was using it anyway. To check for errors checking the uncompressed source file for the time being suffices, I guess. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726676#comment-16726676 ] Werner Punz commented on MYFACES-4265: -- Ok changes are pushed, I will tackle the other isses after x-mas. So please leave this issue open. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726671#comment-16726671 ] Werner Punz commented on MYFACES-4265: -- Ok I checked the build dir, there are indeed way too many files in there. The problem is... some of them are legitimately in since we allow a dynamic script loading as well. (thats the hierarchy under myfaces). We probably should think of removing this dynamic loading feature and simply bundle js maps instead (which has the same effect, except for just providing the needed meta info, there is no modern browser which cannot handle those) But others are double for no reason except that the build seems to throw them in - the non jsf.js files under javax.faces... . I will check this issue separately. For now I can commit the current fixed files and the adjusted builds. I double checked the generated jsf.js it works in my integration tests, so you can get this into the master branch before x-mas the rest has to wait 1-2 weeks. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726599#comment-16726599 ] Werner Punz edited comment on MYFACES-4265 at 12/21/18 9:50 AM: I will add them if possible with the build structure.. I have my own set of about 20 tests I run through testing standard and extreme corner conditions... but those need to be started manually and rely on jasmine, not sure how to combine those with maven and build servers. They are rough, but way more extensive than what we have in myfaces to secure the codebase. The problem I see here might be triggering ajax via automated tests here without relying on a js framework. But I will see what can be done. The tests need to wait a few days, though. But thinks will become faster in the new year. I finally got a dedicated day from my employer per week to work on opensource (before that I had to do most of the stuff in my sparetime). was (Author: werpu): I will add them.. I have my own set of about 20 tests I run through testing standard and extreme corner conditions... but those need to be started manually and rely on jasmine, not sure how to combine those with maven and build servers. They are rough, but way more extensive than what we have in myfaces to secure the codebase. The problem I see here might be triggering ajax via automated tests here without relying on a js framework. But I will see what can be done. The tests need to wait a few days, though. But thinks will become faster in the new year. I finally got a dedicated day from my employer per week to work on opensource (before that I had to do most of the stuff in my sparetime). > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726599#comment-16726599 ] Werner Punz commented on MYFACES-4265: -- I will add them.. I have my own set of about 20 tests I run through testing standard and extreme corner conditions... but those need to be started manually and rely on jasmine, not sure how to combine those with maven and build servers. They are rough, but way more extensive than what we have in myfaces to secure the codebase. The problem I see here might be triggering ajax via automated tests here without relying on a js framework. But I will see what can be done. The tests need to wait a few days, though. But thinks will become faster in the new year. I finally got a dedicated day from my employer per week to work on opensource (before that I had to do most of the stuff in my sparetime). > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726070#comment-16726070 ] Werner Punz commented on MYFACES-4265: -- Ok I am in the middle of implementing it, I will remove following a) The legacy parts regarding ie6 - ie10 b) The iframe workaround will be switched to formdata c) xhr level1 will be removed only xhr level2+ will be supported I will not implement a general formdata submit, because this might break legacy frameworks relying on post ans www-urlencoded. A formdata request is always multipart. The fileupload iframe -> formdata change will be backwards compatible with the advantage that multiple file inputs per form now will be possible. The profiles supported then will be modern (this is just the codebase and english messages) and modern-all which is the codebase and all translations. I probably also will be able to remove the experimental files, because most of the stuff can now be merged into the core codebase. If all goes well then I will be able to commit the code sometime tomorrow. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Werner Punz >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4266) Ajax update fails due to invalid characters in response XML (DoS)
[
https://issues.apache.org/jira/browse/MYFACES-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695940#comment-16695940
]
Werner Punz edited comment on MYFACES-4266 at 11/22/18 2:20 PM:
@tandraschko, how do you wanna address this?
I guess a server side filter is a safer bet.
Basically the client code just gets the cdata out and uses innerHTML to push
the update in.
I could prefilter the cdata for illegal chars on the client as well, but I am
not sure if this is the proper way to go here.
If the illegal chars come in in between the xml tags I have no way to address
this on the client side (basically the browser already throws an xml error
then).
was (Author: werpu):
@tandraschko, how do you wanna address this?
I guess a server side filter is a safer bet.
Basically the client code just gets the cdata out and uses innerHTML to push
the update in.
I could prefilter the cdata for illegal chars on the client as well, but I am
not sure if this is the proper way to go here.
> Ajax update fails due to invalid characters in response XML (DoS)
> -
>
> Key: MYFACES-4266
> URL: https://issues.apache.org/jira/browse/MYFACES-4266
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: jetty 9.4.14.v20181114
> JDK 10
>Reporter: cnsgithub
>Priority: Major
>
> I noticed that the {{}} update fails when the updated form contains
> unicode characters, which are not allowed in the [XML 1.0
> spec|https://www.w3.org/TR/REC-xml/#charsets].
> h2. Expected Behaviour
> If the update response contains characters that are not allowed in XML, they
> should be filtered by MyFaces before writing the response.
> h2. Actual Behaviour
> Some illegal XML characters are not filtered and therefore the browser fails
> to parse the response.
> h2. Steps to reproduce
> I created a small github project to reproduce this behaviour:
> [https://github.com/cnsgithub/mojarra-ajax/tree/myfaces] (branch myfaces)
> To reproduce:
> - {{git clone [https://github.com/cnsgithub/mojarra-ajax]}}
> - {{git checkout myfaces}}
> - run {{mvn clean package jetty:run}}
> - after the server has started, open [http://localhost:8080/index.xhtml]
> - Click the button, the error should occur
> The issue also occurs with user supplied inputs:
> - open [http://localhost:8080/input.xhtml]
> - Paste the characters from the {{illegal-xml-chars.txt}} file into the
> input field
> - Click the button
> This issue should be addressed with high priority since it is security
> related (might be exploited for Denial of Service).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4266) Ajax update fails due to invalid characters in response XML (DoS)
[
https://issues.apache.org/jira/browse/MYFACES-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16695940#comment-16695940
]
Werner Punz commented on MYFACES-4266:
--
@tandraschko, how do you wanna address this?
I guess a server side filter is a safer bet.
Basically the client code just gets the cdata out and uses innerHTML to push
the update in.
I could prefilter the cdata for illegal chars on the client as well, but I am
not sure if this is the proper way to go here.
> Ajax update fails due to invalid characters in response XML (DoS)
> -
>
> Key: MYFACES-4266
> URL: https://issues.apache.org/jira/browse/MYFACES-4266
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: jetty 9.4.14.v20181114
> JDK 10
>Reporter: cnsgithub
>Priority: Major
>
> I noticed that the {{}} update fails when the updated form contains
> unicode characters, which are not allowed in the [XML 1.0
> spec|https://www.w3.org/TR/REC-xml/#charsets].
> h2. Expected Behaviour
> If the update response contains characters that are not allowed in XML, they
> should be filtered by MyFaces before writing the response.
> h2. Actual Behaviour
> Some illegal XML characters are not filtered and therefore the browser fails
> to parse the response.
> h2. Steps to reproduce
> I created a small github project to reproduce this behaviour:
> [https://github.com/cnsgithub/mojarra-ajax/tree/myfaces] (branch myfaces)
> To reproduce:
> - {{git clone [https://github.com/cnsgithub/mojarra-ajax]}}
> - {{git checkout myfaces}}
> - run {{mvn clean package jetty:run}}
> - after the server has started, open [http://localhost:8080/index.xhtml]
> - Click the button, the error should occur
> The issue also occurs with user supplied inputs:
> - open [http://localhost:8080/input.xhtml]
> - Paste the characters from the {{illegal-xml-chars.txt}} file into the
> input field
> - Click the button
> This issue should be addressed with high priority since it is security
> related (might be exploited for Denial of Service).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4265) Remove old IE6 (and older) workarounds
[ https://issues.apache.org/jira/browse/MYFACES-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680325#comment-16680325 ] Werner Punz commented on MYFACES-4265: -- yes the legacy and experimental later can be removed once the build is adjusted. Also the source files do not necessarily need to be in the final jar. > Remove old IE6 (and older) workarounds > -- > > Key: MYFACES-4265 > URL: https://issues.apache.org/jira/browse/MYFACES-4265 > Project: MyFaces Core > Issue Type: Task >Reporter: Thomas Andraschko >Assignee: Werner Punz >Priority: Major > Fix For: 3.0.0-SNAPSHOT > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MYFACES-3460) onsubmit of form not executed for ajax commands
[
https://issues.apache.org/jira/browse/MYFACES-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16667169#comment-16667169
]
Werner Punz commented on MYFACES-3460:
--
I guess we can close it. However I am not sure how Mojarra behaves in this area
atm. The workaround is in the comments.
But in the end, when we run into a spec gray area which is not specified, I
think both implementations should behave the same. So if Mojarra takes the
onSubmit into consideration by now we have to take it into consideration as
well).
But I am not very eager to fix this on our own here, because if we do, we might
break an awful lot of existing 2.x apps.
> onsubmit of form not executed for ajax commands
> ---
>
> Key: MYFACES-3460
> URL: https://issues.apache.org/jira/browse/MYFACES-3460
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.8, 2.1.5
> Environment: Tomcat 6.0.32, Facelets
>Reporter: Michael Heinen
>Assignee: Werner Punz
>Priority: Major
>
> During the migration from JSF 1.2 to 2.1 I noticed that the onsubmit
> attribute of forms is not executed for ajax links.
> Sample:
> http://www.w3.org/1999/xhtml;
> xmlns:ui="http://java.sun.com/jsf/facelets;
> xmlns:h="http://java.sun.com/jsf/html;
> xmlns:f="http://java.sun.com/jsf/core;>
>
>
>
>
> >
>
>
>
>
>
>
> @ManagedBean(name = "MyController")
> @SessionScoped
> public class MyController{
> private int counter = 1;
> public int getCounter() {
> return counter;
> }
> public void increase(ActionEvent ae) {
> counter++;
> }
> }
> This is also not working with mojarra 2.1.6 and 2.0.8.
> I used the onsbumit with JSF 1.2 in order to lock the screen and prevent
> double submits.
> Now I do not see any working alternative in JSF 2.1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-3751) Log exception on submitForm in Javascript
[
https://issues.apache.org/jira/browse/MYFACES-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1874#comment-1874
]
Werner Punz edited comment on MYFACES-3751 at 10/29/18 9:03 AM:
Ups sorry... I did not read properly (time for a coffee) oamsubmit is not part
of the standard and was not written by me it is pretty old by now btw., this is
myfaces specific, so if something is swallowed there it is better to log the
error out.
JSF ajax is another issue, there we have a dedicated error handling specified
via dev mode and error listeners.
as for console.error in oamsubmit, check for the existence first, i am not
sure, but there still might be some users who are on browsers without consoles
or where the console is undefined in non debug mode. (ie6-10 I think)
was (Author: werpu):
Ups sorry... I did not read properly (time for a coffee) oamsubmit is not part
of the standard, this is myfaces specific, so if something is swallowed there
it is better to log the error out.
JSF ajax is another issue, there we have a dedicated error handling specified
via dev mode and error listeners.
as for console.error in oamsubmit, check for the existence first, i am not
sure, but there still might be some users who are on browsers without consoles
or where the console is undefined in non debug mode. (ie6-10 I think)
> Log exception on submitForm in Javascript
> -
>
> Key: MYFACES-3751
> URL: https://issues.apache.org/jira/browse/MYFACES-3751
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.12
>Reporter: dennis hoersch
>Priority: Major
>
> I was looking for a bug in our scripts happening on submit of the form.
> Unfortunately the JSF-Javascript submitting the form
> (myfaces.oam.submitForm()) is swallowing exceptions that occur while
> submitting.
> try {
> form.submit();
> }
> catch(e) {
> }
> Maybe one could do some kind of logging there to help debugging.
> try {
> form.submit();
> }
> catch(e) {
> console.error(e); //?
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-3751) Log exception on submitForm in Javascript
[
https://issues.apache.org/jira/browse/MYFACES-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1874#comment-1874
]
Werner Punz edited comment on MYFACES-3751 at 10/29/18 9:02 AM:
Ups sorry... I did not read properly (time for a coffee) oamsubmit is not part
of the standard, this is myfaces specific, so if something is swallowed there
it is better to log the error out.
JSF ajax is another issue, there we have a dedicated error handling.
as for console.error in oamsubmit, check for the existence first, i am not
sure, but there still might be some users who are on browsers without consoles
or where the console is undefined in non debug mode. (ie6-10 I think)
was (Author: werpu):
Afair expected behavior, script errors on the JSF side are only exposed in dev
mode or if an error listener is explicitely set.
I think it was part of the spec... but I really have to look this up.
So if you apply an error listener you can do whatever you want with the error
info.
> Log exception on submitForm in Javascript
> -
>
> Key: MYFACES-3751
> URL: https://issues.apache.org/jira/browse/MYFACES-3751
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.12
>Reporter: dennis hoersch
>Priority: Major
>
> I was looking for a bug in our scripts happening on submit of the form.
> Unfortunately the JSF-Javascript submitting the form
> (myfaces.oam.submitForm()) is swallowing exceptions that occur while
> submitting.
> try {
> form.submit();
> }
> catch(e) {
> }
> Maybe one could do some kind of logging there to help debugging.
> try {
> form.submit();
> }
> catch(e) {
> console.error(e); //?
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-3751) Log exception on submitForm in Javascript
[
https://issues.apache.org/jira/browse/MYFACES-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1874#comment-1874
]
Werner Punz edited comment on MYFACES-3751 at 10/29/18 9:02 AM:
Ups sorry... I did not read properly (time for a coffee) oamsubmit is not part
of the standard, this is myfaces specific, so if something is swallowed there
it is better to log the error out.
JSF ajax is another issue, there we have a dedicated error handling specified
via dev mode and error listeners.
as for console.error in oamsubmit, check for the existence first, i am not
sure, but there still might be some users who are on browsers without consoles
or where the console is undefined in non debug mode. (ie6-10 I think)
was (Author: werpu):
Ups sorry... I did not read properly (time for a coffee) oamsubmit is not part
of the standard, this is myfaces specific, so if something is swallowed there
it is better to log the error out.
JSF ajax is another issue, there we have a dedicated error handling.
as for console.error in oamsubmit, check for the existence first, i am not
sure, but there still might be some users who are on browsers without consoles
or where the console is undefined in non debug mode. (ie6-10 I think)
> Log exception on submitForm in Javascript
> -
>
> Key: MYFACES-3751
> URL: https://issues.apache.org/jira/browse/MYFACES-3751
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.12
>Reporter: dennis hoersch
>Priority: Major
>
> I was looking for a bug in our scripts happening on submit of the form.
> Unfortunately the JSF-Javascript submitting the form
> (myfaces.oam.submitForm()) is swallowing exceptions that occur while
> submitting.
> try {
> form.submit();
> }
> catch(e) {
> }
> Maybe one could do some kind of logging there to help debugging.
> try {
> form.submit();
> }
> catch(e) {
> console.error(e); //?
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-3751) Log exception on submitForm in Javascript
[
https://issues.apache.org/jira/browse/MYFACES-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1874#comment-1874
]
Werner Punz commented on MYFACES-3751:
--
Afair expected behavior, script errors on the JSF side are only exposed in dev
mode or if an error handler is explicitely set.
I think it was part of the spec... but I really have to look this up.
> Log exception on submitForm in Javascript
> -
>
> Key: MYFACES-3751
> URL: https://issues.apache.org/jira/browse/MYFACES-3751
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.12
>Reporter: dennis hoersch
>Priority: Major
>
> I was looking for a bug in our scripts happening on submit of the form.
> Unfortunately the JSF-Javascript submitting the form
> (myfaces.oam.submitForm()) is swallowing exceptions that occur while
> submitting.
> try {
> form.submit();
> }
> catch(e) {
> }
> Maybe one could do some kind of logging there to help debugging.
> try {
> form.submit();
> }
> catch(e) {
> console.error(e); //?
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-3751) Log exception on submitForm in Javascript
[
https://issues.apache.org/jira/browse/MYFACES-3751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1874#comment-1874
]
Werner Punz edited comment on MYFACES-3751 at 10/29/18 8:59 AM:
Afair expected behavior, script errors on the JSF side are only exposed in dev
mode or if an error listener is explicitely set.
I think it was part of the spec... but I really have to look this up.
So if you apply an error listener you can do whatever you want with the error
info.
was (Author: werpu):
Afair expected behavior, script errors on the JSF side are only exposed in dev
mode or if an error handler is explicitely set.
I think it was part of the spec... but I really have to look this up.
> Log exception on submitForm in Javascript
> -
>
> Key: MYFACES-3751
> URL: https://issues.apache.org/jira/browse/MYFACES-3751
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.1.12
>Reporter: dennis hoersch
>Priority: Major
>
> I was looking for a bug in our scripts happening on submit of the form.
> Unfortunately the JSF-Javascript submitting the form
> (myfaces.oam.submitForm()) is swallowing exceptions that occur while
> submitting.
> try {
> form.submit();
> }
> catch(e) {
> }
> Maybe one could do some kind of logging there to help debugging.
> try {
> form.submit();
> }
> catch(e) {
> console.error(e); //?
> }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519367#comment-16519367
]
Werner Punz commented on MYFACES-4240:
--
No problem, thanks for testing.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
> Fix For: 2.3.2
>
> Attachments: screenshot-1.png
>
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4240.
--
Resolution: Fixed
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
> Fix For: 2.3.2
>
> Attachments: screenshot-1.png
>
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519258#comment-16519258
]
Werner Punz commented on MYFACES-4240:
--
Yes.. my code was pushed to git:
[https://gitbox.apache.org/repos/asf/myfaces.git] on both branches the master
and the 2.3.x branch.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
> Fix For: 2.3.2
>
> Attachments: screenshot-1.png
>
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519248#comment-16519248
]
Werner Punz commented on MYFACES-4240:
--
yes thats my fix. I did not take your patch 1:1 but the idea because there were
other structural issues with the code like the variable not being initialized
upfront.
!varName basically is the same in this context as varName == null || varName ==
0 || 'undefined' typeof varName || varName == false
Javascript is like that :)
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
> Fix For: 2.3.2
>
> Attachments: screenshot-1.png
>
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518014#comment-16518014
]
Werner Punz commented on MYFACES-4240:
--
Yes definitely... otherwise I probably will have a little bit of time next
weekend (I am in a release phase jobwise atm) to setup everything to test it.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516950#comment-16516950
]
Werner Punz edited comment on MYFACES-4240 at 6/19/18 11:21 AM:
Fixed the issue by initializing reconnectAttemtns with 0 and replacing the 0
checks with simple not checks.
It should work, but I atm do not have a proper test environment to test the fix
quickly.
Can anyone do that for me? So that I can resolve this bug.
If no one does it, it might take 1-2 days until I have the time to build a
proper testenv for that case.
was (Author: werpu):
Fixed the issue by initializing reconnectAttemtns with 0 and replacing the 0
checks with simple not checks.
It should work, but I atm do not have a proper test environment to test the fix
quickly.
Can anyone do that for me? So that I can resolve this bug.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516950#comment-16516950
]
Werner Punz commented on MYFACES-4240:
--
Fixed the issue by initializing reconnectAttemtns with 0 and replacing the 0
checks with simple not checks.
It should work, but I atm do not have a proper test environment to test the fix
quickly.
Can anyone do that for me? So that I can resolve this bug.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Assignee: Werner Punz
>Priority: Critical
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516918#comment-16516918
]
Werner Punz edited comment on MYFACES-4240 at 6/19/18 10:33 AM:
this is very likely due to the reconnectAttemts being null initialized at
variable declaration.
another fix would be simply
if(!reconnectAttempts) this basically triggers true in case of null, undefined
or 0
was (Author: werpu):
this is very likely due to the reconnectAttemts being null initialized at
variable declaration.
another fix would be simply
if(!reconnectAttempts) this basically triggers true in case of null undefined
and 0
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Priority: Critical
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MYFACES-4240) onopen eventhandler is called only the first time
[
https://issues.apache.org/jira/browse/MYFACES-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516918#comment-16516918
]
Werner Punz edited comment on MYFACES-4240 at 6/19/18 10:33 AM:
this is very likely due to the reconnectAttemts being null initialized at
variable declaration.
another fix would be simply
if(!reconnectAttempts) this basically triggers true in case of null undefined
and 0
was (Author: werpu):
this is very likely due to the reconnectAttemts being null initialized at
variable declaration.
> onopen eventhandler is called only the first time
> -
>
> Key: MYFACES-4240
> URL: https://issues.apache.org/jira/browse/MYFACES-4240
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.1
> Environment: java 1.8, tomcat 9.0.8, Windows 10
>Reporter: Harry Ring
>Priority: Critical
>
> I use the socket below.
> _ _onmessage="userSocketListener"_
> _onopen="userSocketOpened"_
> _onclose="userSocketClosed"_
> _onerror="alert('ERROR')"_
> _/>_
>
> If I call _jsf.push.open('usersocket')_ and __ _userSocketOpened()_ is
> called.
> Then I call _jsf.__push.close('usersocket')_ and _userSocketClosed()_ is
> called.
> Then I call _jsf.push.open('usersocket')_ and _userSocketOpened()_ is not
> called.
>
> I looked into
> myfaces-api-2.3.1-sources.jar!\META-INF\internal-resources\org.apache.myfaces.core.api\jsf.js
> and found the _onopen_ eventhandler in line 283:
>
> _socket.onopen = function(event) {_
> _{color:#d04437}if (reconnectAttempts == null) {color}{_
> _var clientIds = clientIdsByTokens[channelToken];_
> _for (var i = clientIds.length - 1; i >= 0; i--){_
> _var socketClientId = clientIds[i];_
> _components[socketClientId]['onopen'](channel);_
> _}_
> _}_
> _reconnectAttempts = 0;_
> _}_
> When the socket is opened the first time reconnectAttempts is null, when the
> socket is opened the second time reconnectAttempts is 0, so the line should be
> _if (reconnectAttempts == null || reconnectAttempts == 0)_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
