(wicket) branch wicket-9.x updated (1f418c276a -> 55d0c48427)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-9.x in repository https://gitbox.apache.org/repos/asf/wicket.git from 1f418c276a Bump junit.version from 5.10.1 to 5.10.2 (#782) new 18bfd9b301 Fix condition for simple top level navigation new bec08867c4 Correctly assert the conditions related to top-level navigation new 55d0c48427 Add test to assert that POST is not simple top-level navigation The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../http/FetchMetadataResourceIsolationPolicy.java | 4 +- .../ResourceIsolationRequestCycleListenerTest.java | 45 +++--- 2 files changed, 42 insertions(+), 7 deletions(-)
(wicket) 03/03: Add test to assert that POST is not simple top-level navigation
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-9.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit 55d0c48427c797876442defa0e383b0e85902eda
Author: Emond Papegaaij
AuthorDate: Mon Feb 26 11:10:33 2024 +0100
Add test to assert that POST is not simple top-level navigation
---
.../ResourceIsolationRequestCycleListenerTest.java| 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
index b3a9e08e21..f694ab93d8 100644
---
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
@@ -123,6 +123,18 @@ public class ResourceIsolationRequestCycleListenerTest
extends WicketTestCase
assertRequestAccepted();
}
+ /**
+* Tests that a POST is not a simple top-level navigation request and
is blocked
+*/
+ @Test
+ void topLevelNavigationPostAborted()
+ {
+ tester.addRequestHeader(SEC_FETCH_SITE_HEADER, CROSS_SITE);
+ tester.addRequestHeader(SEC_FETCH_MODE_HEADER, MODE_NAVIGATE);
+
+ assertRequestAborted("POST");
+ }
+
/**
* Tests that requests rejected by fetch metadata have the Vary header
set
*/
@@ -205,7 +217,12 @@ public class ResourceIsolationRequestCycleListenerTest
extends WicketTestCase
private void assertRequestAborted()
{
- tester.getRequest().setMethod("GET");
+ assertRequestAborted("GET");
+ }
+
+ private void assertRequestAborted(String requestMethod)
+ {
+ tester.getRequest().setMethod(requestMethod);
tester.clickLink("link");
assertEquals(javax.servlet.http.HttpServletResponse.SC_FORBIDDEN,
tester.getLastResponse().getStatus());
(wicket) 01/03: Fix condition for simple top level navigation
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch wicket-9.x in repository https://gitbox.apache.org/repos/asf/wicket.git commit 18bfd9b30146c0f003555c54e88d87c9686ae2f7 Author: Emond Papegaaij AuthorDate: Sun Feb 25 21:06:10 2024 +0100 Fix condition for simple top level navigation --- .../wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java index 18c54078b4..99def5f6e8 100644 --- a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java +++ b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java @@ -83,7 +83,7 @@ public class FetchMetadataResourceIsolationPolicy implements IResourceIsolationP String dest = request.getHeader(SEC_FETCH_DEST_HEADER); boolean isSimpleTopLevelNavigation = MODE_NAVIGATE.equals(mode) - || "GET".equals(request.getMethod()); + && "GET".equals(request.getMethod()); boolean isNotObjectOrEmbedRequest = !DEST_EMBED.equals(dest) && !DEST_OBJECT.equals(dest); return isSimpleTopLevelNavigation && isNotObjectOrEmbedRequest;
(wicket) 02/03: Correctly assert the conditions related to top-level navigation
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-9.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit bec08867c4330ab994e84cb3b82be65e23e4ad6e
Author: Emond Papegaaij
AuthorDate: Mon Feb 26 10:30:23 2024 +0100
Correctly assert the conditions related to top-level navigation
---
.../http/FetchMetadataResourceIsolationPolicy.java | 4 +++-
.../ResourceIsolationRequestCycleListenerTest.java | 28 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java
index 99def5f6e8..457130cac0 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java
@@ -42,10 +42,12 @@ public class FetchMetadataResourceIsolationPolicy
implements IResourceIsolationP
public static final String SAME_SITE = "same-site";
public static final String NONE = "none";
public static final String MODE_NAVIGATE = "navigate";
+ public static final String MODE_NO_CORS = "no-cors";
public static final String DEST_OBJECT = "object";
public static final String DEST_EMBED = "embed";
public static final String CROSS_SITE = "cross-site";
public static final String CORS = "cors";
+ public static final String DEST_DOCUMENT = "document";
public static final String DEST_SCRIPT = "script";
public static final String DEST_IMAGE = "image";
@@ -83,7 +85,7 @@ public class FetchMetadataResourceIsolationPolicy implements
IResourceIsolationP
String dest = request.getHeader(SEC_FETCH_DEST_HEADER);
boolean isSimpleTopLevelNavigation = MODE_NAVIGATE.equals(mode)
- && "GET".equals(request.getMethod());
+ && "GET".equalsIgnoreCase(request.getMethod());
boolean isNotObjectOrEmbedRequest = !DEST_EMBED.equals(dest) &&
!DEST_OBJECT.equals(dest);
return isSimpleTopLevelNavigation && isNotObjectOrEmbedRequest;
diff --git
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
index 2dce6ee988..b3a9e08e21 100644
---
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/ResourceIsolationRequestCycleListenerTest.java
@@ -19,8 +19,9 @@ package org.apache.wicket.protocol.http;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.CROSS_SITE;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.DEST_EMBED;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.DEST_OBJECT;
+import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.DEST_DOCUMENT;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.MODE_NAVIGATE;
-import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.SAME_ORIGIN;
+import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.MODE_NO_CORS;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.SAME_SITE;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.SEC_FETCH_DEST_HEADER;
import static
org.apache.wicket.protocol.http.FetchMetadataResourceIsolationPolicy.SEC_FETCH_MODE_HEADER;
@@ -85,6 +86,19 @@ public class ResourceIsolationRequestCycleListenerTest
extends WicketTestCase
assertRequestAborted();
}
+ /**
+* Tests whether cross site requests are aborted
+*/
+ @Test
+ void destNoCorsGetAborted()
+ {
+ tester.addRequestHeader(SEC_FETCH_SITE_HEADER, CROSS_SITE);
+ tester.addRequestHeader(SEC_FETCH_DEST_HEADER, DEST_DOCUMENT);
+ tester.addRequestHeader(SEC_FETCH_MODE_HEADER, MODE_NO_CORS);
+
+ assertRequestAborted();
+ }
+
/**
* Tests whether object requests (sec-fetch-dest :"object" ) are
aborted by FM checks
*/
@@ -103,7 +117,7 @@ public class ResourceIsolationRequestCycleListenerTest
extends WicketTestCase
@Test
void topLevelNavigationAllowedFM()
{
- tester.addRequestHeader(SE
(wicket) branch master updated (6f4906323f -> 851565a5a1)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/wicket.git from 6f4906323f Bump ip from 1.1.8 to 1.1.9 in /testing/wicket-js-tests (#795) add fcdc54e59e Fix condition for simple top level navigation add 31f24a0418 Correctly assert the conditions related to top-level navigation add f034525202 Add test to assert that POST is not simple top-level navigation new 851565a5a1 Merge pull request #798 from apache/fix-top-level-navigation The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../ResourceIsolationRequestCycleListenerTest.java | 45 +++--- .../http/FetchMetadataResourceIsolationPolicy.java | 4 +- 2 files changed, 42 insertions(+), 7 deletions(-)
(wicket) 01/01: Merge pull request #798 from apache/fix-top-level-navigation
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/wicket.git commit 851565a5a1a48d481e2877b5b204305d9061fd7e Merge: 6f4906323f f034525202 Author: Emond Papegaaij AuthorDate: Mon Feb 26 11:19:05 2024 +0100 Merge pull request #798 from apache/fix-top-level-navigation Fix condition for simple top level navigation .../ResourceIsolationRequestCycleListenerTest.java | 45 +++--- .../http/FetchMetadataResourceIsolationPolicy.java | 4 +- 2 files changed, 42 insertions(+), 7 deletions(-)
(wicket) branch fix-top-level-navigation updated (31f24a0418 -> f034525202)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch fix-top-level-navigation in repository https://gitbox.apache.org/repos/asf/wicket.git from 31f24a0418 Correctly assert the conditions related to top-level navigation add f034525202 Add test to assert that POST is not simple top-level navigation No new revisions were added by this update. Summary of changes: .../ResourceIsolationRequestCycleListenerTest.java| 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-)
(wicket) branch fix-top-level-navigation updated (fcdc54e59e -> 31f24a0418)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch fix-top-level-navigation in repository https://gitbox.apache.org/repos/asf/wicket.git from fcdc54e59e Fix condition for simple top level navigation add 31f24a0418 Correctly assert the conditions related to top-level navigation No new revisions were added by this update. Summary of changes: .../ResourceIsolationRequestCycleListenerTest.java | 28 +- .../http/FetchMetadataResourceIsolationPolicy.java | 4 +++- 2 files changed, 25 insertions(+), 7 deletions(-)
(wicket) 01/01: Fix condition for simple top level navigation
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch fix-top-level-navigation in repository https://gitbox.apache.org/repos/asf/wicket.git commit fcdc54e59eaf925bd5a3a04296463cb0a28e172b Author: Emond Papegaaij AuthorDate: Sun Feb 25 21:06:10 2024 +0100 Fix condition for simple top level navigation --- .../wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java index ee6d190aaf..b268847893 100644 --- a/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java +++ b/wicket-core/src/main/java/org/apache/wicket/protocol/http/FetchMetadataResourceIsolationPolicy.java @@ -83,7 +83,7 @@ public class FetchMetadataResourceIsolationPolicy implements IResourceIsolationP String dest = request.getHeader(SEC_FETCH_DEST_HEADER); boolean isSimpleTopLevelNavigation = MODE_NAVIGATE.equals(mode) - || "GET".equals(request.getMethod()); + && "GET".equals(request.getMethod()); boolean isNotObjectOrEmbedRequest = !DEST_EMBED.equals(dest) && !DEST_OBJECT.equals(dest); return isSimpleTopLevelNavigation && isNotObjectOrEmbedRequest;
(wicket) branch fix-top-level-navigation created (now fcdc54e59e)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch fix-top-level-navigation in repository https://gitbox.apache.org/repos/asf/wicket.git at fcdc54e59e Fix condition for simple top level navigation This branch includes the following new commits: new fcdc54e59e Fix condition for simple top level navigation The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference.
[jira] [Resolved] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-7090.
-
Fix Version/s: 10.0.0-M3
Resolution: Fixed
> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
> Issue Type: Bug
> Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0,
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
> Assignee: Emond Papegaaij
>Priority: Minor
> Fix For: 10.0.0-M3
>
>
> Starting with 9.8.0, the release jars are built with file entries without a
> last modification timestamp. This can cause issues if
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}.
> The browser may be using an older version of the resource, even if a newer
> version is available. This strategy is normally only used in development
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last
> modification timestamp to fixed time during the release, as git doesn't track
> this. A suggestion is to use the project.build.outputTimestamp property:
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij closed WICKET-7090.
---
> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
> Issue Type: Bug
> Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0,
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
> Assignee: Emond Papegaaij
>Priority: Minor
> Fix For: 10.0.0-M3
>
>
> Starting with 9.8.0, the release jars are built with file entries without a
> last modification timestamp. This can cause issues if
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}.
> The browser may be using an older version of the resource, even if a newer
> version is available. This strategy is normally only used in development
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last
> modification timestamp to fixed time during the release, as git doesn't track
> this. A suggestion is to use the project.build.outputTimestamp property:
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
(wicket) branch master updated (eadd734259 -> 07d457bd4d)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/wicket.git from eadd734259 Re-enable SpringWebApplicationFactoryTest add 83fc5fedfb WICKET-7090: add outputTimestamp property to enable reproducible builds add 7652239b31 WICKET-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for packaging add 07d457bd4d Merge pull request #758 from apache/wicket-7090 No new revisions were added by this update. Summary of changes: pom.xml| 7 +-- wicket-auth-roles/pom.xml | 2 +- wicket-bean-validation/pom.xml | 2 +- wicket-cdi/pom.xml | 2 +- wicket-core/pom.xml| 2 +- wicket-devutils/pom.xml| 2 +- wicket-experimental/wicket-metrics/pom.xml | 2 +- wicket-extensions-tester/pom.xml | 2 +- wicket-extensions/pom.xml | 2 +- wicket-guice/pom.xml | 2 +- wicket-ioc/pom.xml | 2 +- wicket-jmx/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-core/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-javax/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-tester/pom.xml | 2 +- wicket-request/pom.xml | 2 +- wicket-spring/pom.xml | 2 +- wicket-tester/pom.xml | 2 +- wicket-util/pom.xml| 2 +- wicket-velocity/pom.xml| 2 +- 20 files changed, 24 insertions(+), 21 deletions(-)
(wicket) branch wicket-7090 updated (d030b8ffad -> 7652239b31)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-7090 in repository https://gitbox.apache.org/repos/asf/wicket.git discard d030b8ffad TKH-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for packaging add 7652239b31 WICKET-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for packaging This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d030b8ffad) \ N -- N -- N refs/heads/wicket-7090 (7652239b31) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. No new revisions were added by this update. Summary of changes:
[jira] [Commented] (WICKET-7092) Content Security Policy 'Nonces should only use the base64 charset'
[ https://issues.apache.org/jira/browse/WICKET-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803055#comment-17803055 ] Emond Papegaaij commented on WICKET-7092: - Base64 has 2 commonly used alphabets, normal and URL. The problem with + and / is that they have special meaning in URLs, the URL safe alphabet prevents this by using - and _. Both are valid base64 alphabets. The CSP spec doesn't state which base64 alphabet to use and the ABNF for nonce allows both, so I would say both are equally valid and the tool used by the reporter is wrong. > Content Security Policy 'Nonces should only use the base64 charset' > --- > > Key: WICKET-7092 > URL: https://issues.apache.org/jira/browse/WICKET-7092 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 9.16.0 > Environment: Kali Linux >Reporter: sundar >Priority: Minor > Attachments: image-20240103-092246.png > > > Hi all, I applied a strict content security policy to my application using > wicket after I tested my application using Kali Linux to check for > vulnerabilities. The tool provides the report with an info message "Nonces > should only use the base64 charset" regarding the info message needed to > configure any properties in CSP. I attached the report screenshot -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (WICKET-7092) Content Security Policy 'Nonces should only use the base64 charset'
[ https://issues.apache.org/jira/browse/WICKET-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij closed WICKET-7092. --- Resolution: Won't Fix The characters used in the nonce are valid according to the CSP specification. > Content Security Policy 'Nonces should only use the base64 charset' > --- > > Key: WICKET-7092 > URL: https://issues.apache.org/jira/browse/WICKET-7092 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 9.16.0 > Environment: Kali Linux >Reporter: sundar >Priority: Minor > Attachments: image-20240103-092246.png > > > Hi all, I applied a strict content security policy to my application using > wicket after I tested my application using Kali Linux to check for > vulnerabilities. The tool provides the report with an info message "Nonces > should only use the base64 charset" regarding the info message needed to > configure any properties in CSP. I attached the report screenshot -- This message was sent by Atlassian Jira (v8.20.10#820010)
(wicket) branch wicket-7090 updated (83fc5fedfb -> d030b8ffad)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-7090 in repository https://gitbox.apache.org/repos/asf/wicket.git from 83fc5fedfb WICKET-7090: add outputTimestamp property to enable reproducible builds add d030b8ffad TKH-7090: use manifest from maven-bundle-plugin but use maven-jar-plugin for packaging No new revisions were added by this update. Summary of changes: pom.xml| 5 +++-- wicket-auth-roles/pom.xml | 2 +- wicket-bean-validation/pom.xml | 2 +- wicket-cdi/pom.xml | 2 +- wicket-core/pom.xml| 2 +- wicket-devutils/pom.xml| 2 +- wicket-experimental/wicket-metrics/pom.xml | 2 +- wicket-extensions-tester/pom.xml | 2 +- wicket-extensions/pom.xml | 2 +- wicket-guice/pom.xml | 2 +- wicket-ioc/pom.xml | 2 +- wicket-jmx/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-core/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-javax/pom.xml | 2 +- wicket-native-websocket/wicket-native-websocket-tester/pom.xml | 2 +- wicket-request/pom.xml | 2 +- wicket-spring/pom.xml | 2 +- wicket-tester/pom.xml | 2 +- wicket-util/pom.xml| 2 +- wicket-velocity/pom.xml| 2 +- 20 files changed, 22 insertions(+), 21 deletions(-)
[jira] [Assigned] (WICKET-7090) Files in release jars do not have a modification timestamp set
[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij reassigned WICKET-7090:
---
Assignee: Emond Papegaaij
> Files in release jars do not have a modification timestamp set
> --
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
> Issue Type: Bug
> Components: release
>Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0,
> 9.15.0, 9.16.0
>Reporter: Emond Papegaaij
> Assignee: Emond Papegaaij
>Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a
> last modification timestamp. This can cause issues if
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}.
> The browser may be using an older version of the resource, even if a newer
> version is available. This strategy is normally only used in development
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last
> modification timestamp to fixed time during the release, as git doesn't track
> this. A suggestion is to use the project.build.outputTimestamp property:
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
(wicket) 01/01: WICKET-7090: add outputTimestamp property to enable reproducible builds
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-7090
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit 83fc5fedfb592b2be532c28472bbd9a539167dbd
Author: Emond Papegaaij
AuthorDate: Thu Jan 4 11:09:22 2024 +0100
WICKET-7090: add outputTimestamp property to enable reproducible builds
In addition to reprocible builds, this should also result in timestamps
being set on files in jars.
---
pom.xml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pom.xml b/pom.xml
index 61ac4d5104..b4ef68c01c 100644
--- a/pom.xml
+++ b/pom.xml
@@ -129,6 +129,8 @@
UTF-8
UTF-8
+
2024-01-01T00:00:00Z
+
https://docs.oracle.com/en/java/javase/${java.specification.version}/docs/api/
(wicket) branch wicket-7090 created (now 83fc5fedfb)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-7090 in repository https://gitbox.apache.org/repos/asf/wicket.git at 83fc5fedfb WICKET-7090: add outputTimestamp property to enable reproducible builds This branch includes the following new commits: new 83fc5fedfb WICKET-7090: add outputTimestamp property to enable reproducible builds The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference.
[jira] [Commented] (WICKET-7092) Content Security Policy 'Nonces should only use the base64 charset'
[
https://issues.apache.org/jira/browse/WICKET-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802878#comment-17802878
]
Emond Papegaaij commented on WICKET-7092:
-
This seems like a bug in the tool used to check the application. The
[specification|https://www.w3.org/TR/CSP3/#framework-directive-source-list]
says:
{code}
nonce-source = "'nonce-" base64-value "'"
base64-value = 1*( ALPHA / DIGIT / "+" / "/" / "-" / "_" )*2( "=" )
{code}
The nonce in your example is {{nonce-QmsK_uBjkJ84B3bGJIXLqMEs}}, which does
conform to the specification.
> Content Security Policy 'Nonces should only use the base64 charset'
> ---
>
> Key: WICKET-7092
> URL: https://issues.apache.org/jira/browse/WICKET-7092
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.16.0
> Environment: Kali Linux
>Reporter: sundar
>Priority: Minor
> Attachments: image-20240103-092246.png
>
>
> Hi all, I applied a strict content security policy to my application using
> wicket after I tested my application using Kali Linux to check for
> vulnerabilities. The tool provides the report with an info message "Nonces
> should only use the base64 charset" regarding the info message needed to
> configure any properties in CSP. I attached the report screenshot
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (WICKET-7090) Files in release jars do not have a modification timestamp set
Emond Papegaaij created WICKET-7090:
---
Summary: Files in release jars do not have a modification
timestamp set
Key: WICKET-7090
URL: https://issues.apache.org/jira/browse/WICKET-7090
Project: Wicket
Issue Type: Bug
Components: release
Affects Versions: 9.16.0, 9.15.0, 9.14.0, 9.13.0, 9.12.0, 9.11.0, 9.10.0,
9.9.0, 9.8.0
Reporter: Emond Papegaaij
Starting with 9.8.0, the release jars are built with file entries without a
last modification timestamp. This can cause issues if
{{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}.
The browser may be using an older version of the resource, even if a newer
version is available. This strategy is normally only used in development mode,
but even then this can cause unexpected behavior.
As discussed on the dev list, the best we can do is to set the last
modification timestamp to fixed time during the release, as git doesn't track
this. A suggestion is to use the project.build.outputTimestamp property:
https://maven.apache.org/guides/mini/guide-reproducible-builds.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (WICKET-7043) Bug report - enter button doesn't submit form on Safari
[ https://issues.apache.org/jira/browse/WICKET-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713956#comment-17713956 ] Emond Papegaaij commented on WICKET-7043: - This is a known bug in safari, which probably cannot be fixed in wicket. > Bug report - enter button doesn't submit form on Safari > --- > > Key: WICKET-7043 > URL: https://issues.apache.org/jira/browse/WICKET-7043 > Project: Wicket > Issue Type: Bug >Affects Versions: 9.12.0 > Environment: MacOS, Safari >Reporter: farouk khoualdia >Priority: Major > > the enter button doesn't submit form on safari , works fine with other > browsers , bug reproducible on version 9.12.0 , and it is working fine on > version 8.12.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (WICKET-7016) Support GCM-SIV for page store encryption
[ https://issues.apache.org/jira/browse/WICKET-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij updated WICKET-7016: Description: The current ICrypter implementation uses AES-256 with CBC. Although this is still secure, GCM is now considered a better alternative. The big plus for GCM is the fact that it is an authenticated form of encryption: the encrypted data is verified with the key using a MAC. This makes the encrypted data tamper-proof. The downside of GCM is that it fails catastrophically if the nonce is reused for a certain key. This makes it dangerous to use random nonces. GCM-SIV fixes this at the expense of a higher cost. Bouncy Castle has a good GCM-SIV implementation (the JDK does not). (was: The current ICrypter implementation uses AES-256 with CBC. Although this is still secure, GCM is now considered a better alternative. The big plus for GCM is the fact that it is an authenticated form of encryption: the encrypted data is verified with the key using a MAC. This makes the encrypted data tamper-proof. The downside of GCM is that it fails catastrophically if the nonce is reused for a certain key. This makes it dangerous to use random nonces. GCM-SIV fixes this at the expense of a slightly higher cost. Bouncy Castle has a good GCM-SIV implementation (the JDK does not).) > Support GCM-SIV for page store encryption > - > > Key: WICKET-7016 > URL: https://issues.apache.org/jira/browse/WICKET-7016 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.12.0 > Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > Fix For: 10.0.0, 9.13.0 > > > The current ICrypter implementation uses AES-256 with CBC. Although this is > still secure, GCM is now considered a better alternative. The big plus for > GCM is the fact that it is an authenticated form of encryption: the encrypted > data is verified with the key using a MAC. This makes the encrypted data > tamper-proof. The downside of GCM is that it fails catastrophically if the > nonce is reused for a certain key. This makes it dangerous to use random > nonces. GCM-SIV fixes this at the expense of a higher cost. Bouncy Castle has > a good GCM-SIV implementation (the JDK does not). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WICKET-7016) Support GCM-SIV for page store encryption
[ https://issues.apache.org/jira/browse/WICKET-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij resolved WICKET-7016. - Fix Version/s: 10.0.0 9.13.0 Resolution: Fixed > Support GCM-SIV for page store encryption > - > > Key: WICKET-7016 > URL: https://issues.apache.org/jira/browse/WICKET-7016 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.12.0 > Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > Fix For: 10.0.0, 9.13.0 > > > The current ICrypter implementation uses AES-256 with CBC. Although this is > still secure, GCM is now considered a better alternative. The big plus for > GCM is the fact that it is an authenticated form of encryption: the encrypted > data is verified with the key using a MAC. This makes the encrypted data > tamper-proof. The downside of GCM is that it fails catastrophically if the > nonce is reused for a certain key. This makes it dangerous to use random > nonces. GCM-SIV fixes this at the expense of a slightly higher cost. Bouncy > Castle has a good GCM-SIV implementation (the JDK does not). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[wicket] branch master updated: WICKET-7016: Add support for AES-GCM-SIV as cipher for page store encryption
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 210525f0ec WICKET-7016: Add support for AES-GCM-SIV as cipher for page
store encryption
210525f0ec is described below
commit 210525f0ecd30794532b5ebebfbe677daf244517
Author: Emond Papegaaij
AuthorDate: Fri Nov 18 11:59:31 2022 +0100
WICKET-7016: Add support for AES-GCM-SIV as cipher for page store encryption
---
pom.xml| 6 ++
wicket-core/pom.xml| 5 +
wicket-core/src/main/java/module-info.java | 1 +
.../apache/wicket/pageStore/CryptingPageStore.java | 2 +-
.../wicket/pageStore/crypt/GCMSIVCrypter.java | 107 +
.../org/apache/wicket/settings/StoreSettings.java | 29 ++
.../wicket/pageStore/CryptingPageStoreTest.java| 49 --
7 files changed, 188 insertions(+), 11 deletions(-)
diff --git a/pom.xml b/pom.xml
index d4dadc97f1..f07d75e49b 100644
--- a/pom.xml
+++ b/pom.xml
@@ -138,6 +138,7 @@
9.2
1.9.7
3.21.0
+ 1.72
1.12.2
4.1.0
3.2.2
@@ -480,6 +481,11 @@
aspectjrt
${aspectj.version}
+
+ org.bouncycastle
+ bcprov-jdk18on
+ ${bouncycastle.version}
+
org.danekja
jdk-serializable-functional
diff --git a/wicket-core/pom.xml b/wicket-core/pom.xml
index a699761976..7a606c8bf6 100644
--- a/wicket-core/pom.xml
+++ b/wicket-core/pom.xml
@@ -169,6 +169,11 @@ org.apache.wicket.validation.validator;-noimport:=true
org.apache.wicket
wicket-util
+
+ org.bouncycastle
+ bcprov-jdk18on
+ true
+
org.danekja
jdk-serializable-functional
diff --git a/wicket-core/src/main/java/module-info.java
b/wicket-core/src/main/java/module-info.java
index 3ab3c7f0ed..04cc5f45c1 100644
--- a/wicket-core/src/main/java/module-info.java
+++ b/wicket-core/src/main/java/module-info.java
@@ -29,6 +29,7 @@ module org.apache.wicket.core {
requires org.danekja.jdk.serializable.functional;
requires com.github.openjson;
requires org.junit.jupiter.api;
+requires static org.bouncycastle.provider;
provides org.apache.wicket.IInitializer with org.apache.wicket.Initializer;
provides org.apache.wicket.resource.FileSystemPathService with
org.apache.wicket.resource.FileSystemJarPathService;
diff --git
a/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
b/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
index b8e26ac9e9..32185a620b 100644
---
a/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
+++
b/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
@@ -96,7 +96,7 @@ public class CryptingPageStore extends DelegatingPageStore
*/
protected ICrypter newCrypter()
{
- return new DefaultCrypter();
+ return application.getStoreSettings().getCrypter().get();
}
@Override
diff --git
a/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
b/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
new file mode 100644
index 00..e4fff7bcc8
--- /dev/null
+++
b/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
@@ -0,0 +1,107 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.pageStore.crypt;
+
+import java.security.Algorith
[wicket] branch wicket-9.x updated: WICKET-7016: Add support for AES-GCM-SIV as cipher for page store encryption
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-9.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-9.x by this push:
new 7cb9c91f8f WICKET-7016: Add support for AES-GCM-SIV as cipher for page
store encryption
7cb9c91f8f is described below
commit 7cb9c91f8f9fbdbabab900514b4306889fae8aaa
Author: Emond Papegaaij
AuthorDate: Fri Nov 18 11:59:31 2022 +0100
WICKET-7016: Add support for AES-GCM-SIV as cipher for page store encryption
---
pom.xml| 6 ++
wicket-core/pom.xml| 5 +
wicket-core/src/main/java/module-info.java | 1 +
.../apache/wicket/pageStore/CryptingPageStore.java | 2 +-
.../wicket/pageStore/crypt/GCMSIVCrypter.java | 107 +
.../org/apache/wicket/settings/StoreSettings.java | 29 ++
.../wicket/pageStore/CryptingPageStoreTest.java| 49 --
7 files changed, 188 insertions(+), 11 deletions(-)
diff --git a/pom.xml b/pom.xml
index ba1e928ddf..ca2ad83798 100644
--- a/pom.xml
+++ b/pom.xml
@@ -137,6 +137,7 @@
9.1
1.9.6
3.19.0
+ 1.72
4.1.0
3.3.0
1.11.12
@@ -483,6 +484,11 @@
aspectjrt
${aspectj.version}
+
+ org.bouncycastle
+ bcprov-jdk18on
+ ${bouncycastle.version}
+
org.danekja
jdk-serializable-functional
diff --git a/wicket-core/pom.xml b/wicket-core/pom.xml
index 30133d97d8..e563553fcc 100644
--- a/wicket-core/pom.xml
+++ b/wicket-core/pom.xml
@@ -168,6 +168,11 @@ org.apache.wicket.validation.validator;-noimport:=true
org.apache.wicket
wicket-util
+
+ org.bouncycastle
+ bcprov-jdk18on
+ true
+
org.danekja
jdk-serializable-functional
diff --git a/wicket-core/src/main/java/module-info.java
b/wicket-core/src/main/java/module-info.java
index de5f4bb89f..d9af7a5ead 100644
--- a/wicket-core/src/main/java/module-info.java
+++ b/wicket-core/src/main/java/module-info.java
@@ -29,6 +29,7 @@ module org.apache.wicket.core {
requires org.danekja.jdk.serializable.functional;
requires com.github.openjson;
requires org.junit.jupiter.api;
+requires static org.bouncycastle.provider;
provides org.apache.wicket.IInitializer with org.apache.wicket.Initializer;
provides org.apache.wicket.resource.FileSystemPathService with
org.apache.wicket.resource.FileSystemJarPathService;
diff --git
a/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
b/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
index b8e26ac9e9..32185a620b 100644
---
a/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
+++
b/wicket-core/src/main/java/org/apache/wicket/pageStore/CryptingPageStore.java
@@ -96,7 +96,7 @@ public class CryptingPageStore extends DelegatingPageStore
*/
protected ICrypter newCrypter()
{
- return new DefaultCrypter();
+ return application.getStoreSettings().getCrypter().get();
}
@Override
diff --git
a/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
b/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
new file mode 100644
index 00..e4fff7bcc8
--- /dev/null
+++
b/wicket-core/src/main/java/org/apache/wicket/pageStore/crypt/GCMSIVCrypter.java
@@ -0,0 +1,107 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.wicket.pageStore.crypt;
+
+import java.security.Algorith
[jira] [Assigned] (WICKET-7016) Support GCM-SIV for page store encryption
[ https://issues.apache.org/jira/browse/WICKET-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij reassigned WICKET-7016: --- Assignee: Emond Papegaaij > Support GCM-SIV for page store encryption > - > > Key: WICKET-7016 > URL: https://issues.apache.org/jira/browse/WICKET-7016 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.12.0 > Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Minor > > The current ICrypter implementation uses AES-256 with CBC. Although this is > still secure, GCM is now considered a better alternative. The big plus for > GCM is the fact that it is an authenticated form of encryption: the encrypted > data is verified with the key using a MAC. This makes the encrypted data > tamper-proof. The downside of GCM is that it fails catastrophically if the > nonce is reused for a certain key. This makes it dangerous to use random > nonces. GCM-SIV fixes this at the expense of a slightly higher cost. Bouncy > Castle has a good GCM-SIV implementation (the JDK does not). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (WICKET-7016) Support GCM-SIV for page store encryption
Emond Papegaaij created WICKET-7016: --- Summary: Support GCM-SIV for page store encryption Key: WICKET-7016 URL: https://issues.apache.org/jira/browse/WICKET-7016 Project: Wicket Issue Type: Improvement Components: wicket-core Affects Versions: 9.12.0 Reporter: Emond Papegaaij The current ICrypter implementation uses AES-256 with CBC. Although this is still secure, GCM is now considered a better alternative. The big plus for GCM is the fact that it is an authenticated form of encryption: the encrypted data is verified with the key using a MAC. This makes the encrypted data tamper-proof. The downside of GCM is that it fails catastrophically if the nonce is reused for a certain key. This makes it dangerous to use random nonces. GCM-SIV fixes this at the expense of a slightly higher cost. Bouncy Castle has a good GCM-SIV implementation (the JDK does not). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (WICKET-7014) Use new API for forward compatibility with CDI 4
[
https://issues.apache.org/jira/browse/WICKET-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij closed WICKET-7014.
---
> Use new API for forward compatibility with CDI 4
>
>
> Key: WICKET-7014
> URL: https://issues.apache.org/jira/browse/WICKET-7014
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-cdi
>Affects Versions: 9.12.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 10.0.0, 9.13.0
>
>
> {{org.apache.wicket.cdi.NonContextual}} uses a deprecated API
> {{BeanManager.createInjectionTarget(type)}}. This method no longer exists in
> CDI 4, but the replacement is already available since CDI 1.1. The class
> should use:
> {code}
> BeanManager.getInjectionTargetFactory(type).createInjectionTarget(null);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (WICKET-7014) Use new API for forward compatibility with CDI 4
[
https://issues.apache.org/jira/browse/WICKET-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-7014.
-
Fix Version/s: 9.13.0
10.0.0
Resolution: Fixed
> Use new API for forward compatibility with CDI 4
>
>
> Key: WICKET-7014
> URL: https://issues.apache.org/jira/browse/WICKET-7014
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-cdi
>Affects Versions: 9.12.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 9.13.0, 10.0.0
>
>
> {{org.apache.wicket.cdi.NonContextual}} uses a deprecated API
> {{BeanManager.createInjectionTarget(type)}}. This method no longer exists in
> CDI 4, but the replacement is already available since CDI 1.1. The class
> should use:
> {code}
> BeanManager.getInjectionTargetFactory(type).createInjectionTarget(null);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[wicket] branch master updated: WICKET-7014: use CDI 1.1 API to create InjectionTarget
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 3e0d16ccbc WICKET-7014: use CDI 1.1 API to create InjectionTarget
3e0d16ccbc is described below
commit 3e0d16ccbcd4df4340c12339e1319cdd4f9849fc
Author: Emond Papegaaij
AuthorDate: Fri Nov 11 13:16:52 2022 +0100
WICKET-7014: use CDI 1.1 API to create InjectionTarget
---
wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
b/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
index e57d2fb088..0bb6f154cd 100644
--- a/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
+++ b/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
@@ -125,7 +125,8 @@ public class NonContextual
{
BeanManager manager = BeanManagerLookup.lookup();
AnnotatedType type =
manager.createAnnotatedType(clazz);
- this.it =
(InjectionTarget)manager.createInjectionTarget(type);
+ this.it = (InjectionTarget)
manager.getInjectionTargetFactory(type)
+ .createInjectionTarget(null);
}
/**
[wicket] branch wicket-9.x updated: WICKET-7014: use CDI 1.1 API to create InjectionTarget
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-9.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-9.x by this push:
new a41aa15f44 WICKET-7014: use CDI 1.1 API to create InjectionTarget
a41aa15f44 is described below
commit a41aa15f44d2e05a789f62980bec518e85aef797
Author: Emond Papegaaij
AuthorDate: Fri Nov 11 13:16:52 2022 +0100
WICKET-7014: use CDI 1.1 API to create InjectionTarget
---
wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
b/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
index 4db8fb4898..2e8b11ced6 100644
--- a/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
+++ b/wicket-cdi/src/main/java/org/apache/wicket/cdi/NonContextual.java
@@ -125,7 +125,8 @@ public class NonContextual
{
BeanManager manager = BeanManagerLookup.lookup();
AnnotatedType type =
manager.createAnnotatedType(clazz);
- this.it =
(InjectionTarget)manager.createInjectionTarget(type);
+ this.it = (InjectionTarget)
manager.getInjectionTargetFactory(type)
+ .createInjectionTarget(null);
}
/**
[jira] [Created] (WICKET-7014) Use new API for forward compatibility with CDI 4
Emond Papegaaij created WICKET-7014:
---
Summary: Use new API for forward compatibility with CDI 4
Key: WICKET-7014
URL: https://issues.apache.org/jira/browse/WICKET-7014
Project: Wicket
Issue Type: Improvement
Components: wicket-cdi
Affects Versions: 9.12.0
Reporter: Emond Papegaaij
{{org.apache.wicket.cdi.NonContextual}} uses a deprecated API
{{BeanManager.createInjectionTarget(type)}}. This method no longer exists in
CDI 4, but the replacement is already available since CDI 1.1. The class should
use:
{code}
BeanManager.getInjectionTargetFactory(type).createInjectionTarget(null);
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (WICKET-7014) Use new API for forward compatibility with CDI 4
[
https://issues.apache.org/jira/browse/WICKET-7014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij reassigned WICKET-7014:
---
Assignee: Emond Papegaaij
> Use new API for forward compatibility with CDI 4
>
>
> Key: WICKET-7014
> URL: https://issues.apache.org/jira/browse/WICKET-7014
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-cdi
>Affects Versions: 9.12.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
>
> {{org.apache.wicket.cdi.NonContextual}} uses a deprecated API
> {{BeanManager.createInjectionTarget(type)}}. This method no longer exists in
> CDI 4, but the replacement is already available since CDI 1.1. The class
> should use:
> {code}
> BeanManager.getInjectionTargetFactory(type).createInjectionTarget(null);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (WICKET-7002) Application metadata access should not require synchronization
[
https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601334#comment-17601334
]
Emond Papegaaij commented on WICKET-7002:
-
It is likely that the call stack is either collapsed or inlined by the hotspot
compiler. In our application, the call comes from
{{{}CdiConfiguration.get(application){}}}, which is done from the component
injector for CDI when using the FALLBACK lookup strategy.
> Application metadata access should not require synchronization
> --
>
> Key: WICKET-7002
> URL: https://issues.apache.org/jira/browse/WICKET-7002
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
>Affects Versions: 8.14.0, 9.11.0
>Reporter: Martijn Dashorst
>Priority: Minor
> Fix For: 10.0.0, 9.12.0, 8.15.0
>
> Attachments: Screenshot 2022-09-02 at 17.18.44.png
>
>
> The methods getMetaData and setMetaData from Application have synchronized
> modifiers applied to them such that they block on the application instance.
> This can cause blocking issues. When I looked at the monitor usage in our
> application running in production the Application metadata locks are
> responsible for 57% of all monitor usage.
> I've included a screenshot of the monitor usage reverse call stacks.
> The implementation should be changed to a ConcurrentHashMap so we can remove
> the synchronization from the getter and setter, and just use the hashmap's
> O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the
> blocking and (possibly) long lookups of metadata in the Application instance.
> Note this does not involve modifying the component, session or requestcycle
> metadata implementations (yet).
> IMO this should be backported to at least 9, as this is a semver compatible
> change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (WICKET-6970) Unnecessary string building in AssociatedMarkupSourcingStrategy
[
https://issues.apache.org/jira/browse/WICKET-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-6970.
-
Fix Version/s: 10.0.0
9.10.0
Resolution: Fixed
> Unnecessary string building in AssociatedMarkupSourcingStrategy
> ---
>
> Key: WICKET-6970
> URL: https://issues.apache.org/jira/browse/WICKET-6970
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 10.0.0, 9.9.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 10.0.0, 9.10.0
>
>
> {{AssociatedMarkupSourcingStrategy.renderAssociatedMarkup}} builds a string
> just for an exception message. The method
> {{MarkupContainer.renderAssociatedMarkup}} is only called from this single
> location and is not really meant for public consumption. I suggest we inline
> the message and only build it when it's actually needed. For 9.x we must keep
> the parameter, but we can call it with {{null.}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[wicket] branch wicket-9.x updated: WICKET-6970: do not build error message for every render for every panel
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-9.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-9.x by this push:
new ec87f5f09f WICKET-6970: do not build error message for every render
for every panel
ec87f5f09f is described below
commit ec87f5f09f5a844017e81f663c07305f924d6283
Author: Emond Papegaaij
AuthorDate: Mon Apr 11 10:31:08 2022 +0200
WICKET-6970: do not build error message for every render for every panel
---
.../java/org/apache/wicket/MarkupContainer.java| 25 ++
.../panel/AssociatedMarkupSourcingStrategy.java| 3 +--
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
index 5893186a4c..44d953f096 100644
--- a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
+++ b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
@@ -762,9 +762,25 @@ public abstract class MarkupContainer extends Component
implements Iterable'");
}
// Check for required open tag name
ComponentTag associatedMarkupOpenTag = (ComponentTag)elem;
if (!(associatedMarkupOpenTag.isOpen() &&
(associatedMarkupOpenTag instanceof WicketTag)))
{
-
associatedMarkupStream.throwMarkupException(exceptionMessage);
+ associatedMarkupStream.throwMarkupException("Markup for
a " + openTagName
+ + " component must begin a tag like ''");
}
try
diff --git
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
index 3e4daced88..58d70135d1 100644
---
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
+++
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
@@ -74,8 +74,7 @@ public abstract class AssociatedMarkupSourcingStrategy
extends AbstractMarkupSou
*/
protected final void renderAssociatedMarkup(final Component component)
{
- ((MarkupContainer)component).renderAssociatedMarkup(tagName,
"Markup for a " + tagName +
- " component must begin a tag like ''");
+ ((MarkupContainer)component).renderAssociatedMarkup(tagName);
}
/**
[wicket] branch master updated: WICKET-6970: do not build error message for every render for every panel
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 2a6ae40b02 WICKET-6970: do not build error message for every render
for every panel
2a6ae40b02 is described below
commit 2a6ae40b023bc828a3c5a0d9b480040d6eab6e0e
Author: Emond Papegaaij
AuthorDate: Mon Apr 11 10:31:08 2022 +0200
WICKET-6970: do not build error message for every render for every panel
---
.../src/main/java/org/apache/wicket/MarkupContainer.java | 11 +--
.../markup/html/panel/AssociatedMarkupSourcingStrategy.java | 3 +--
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
index 3011999a28..8703c61635 100644
--- a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
+++ b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
@@ -762,10 +762,8 @@ public abstract class MarkupContainer extends Component
implements Iterable'");
}
// Check for required open tag name
ComponentTag associatedMarkupOpenTag = (ComponentTag)elem;
if (!(associatedMarkupOpenTag.isOpen() &&
(associatedMarkupOpenTag instanceof WicketTag)))
{
-
associatedMarkupStream.throwMarkupException(exceptionMessage);
+ associatedMarkupStream.throwMarkupException("Markup for
a " + openTagName
+ + " component must begin a tag like ''");
}
try
diff --git
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
index 3e4daced88..58d70135d1 100644
---
a/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
+++
b/wicket-core/src/main/java/org/apache/wicket/markup/html/panel/AssociatedMarkupSourcingStrategy.java
@@ -74,8 +74,7 @@ public abstract class AssociatedMarkupSourcingStrategy
extends AbstractMarkupSou
*/
protected final void renderAssociatedMarkup(final Component component)
{
- ((MarkupContainer)component).renderAssociatedMarkup(tagName,
"Markup for a " + tagName +
- " component must begin a tag like ''");
+ ((MarkupContainer)component).renderAssociatedMarkup(tagName);
}
/**
[jira] [Assigned] (WICKET-6970) Unnecessary string building in AssociatedMarkupSourcingStrategy
[
https://issues.apache.org/jira/browse/WICKET-6970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij reassigned WICKET-6970:
---
Assignee: Emond Papegaaij
> Unnecessary string building in AssociatedMarkupSourcingStrategy
> ---
>
> Key: WICKET-6970
> URL: https://issues.apache.org/jira/browse/WICKET-6970
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 10.0.0, 9.9.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
>
> {{AssociatedMarkupSourcingStrategy.renderAssociatedMarkup}} builds a string
> just for an exception message. The method
> {{MarkupContainer.renderAssociatedMarkup}} is only called from this single
> location and is not really meant for public consumption. I suggest we inline
> the message and only build it when it's actually needed. For 9.x we must keep
> the parameter, but we can call it with {{null.}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (WICKET-6970) Unnecessary string building in AssociatedMarkupSourcingStrategy
Emond Papegaaij created WICKET-6970:
---
Summary: Unnecessary string building in
AssociatedMarkupSourcingStrategy
Key: WICKET-6970
URL: https://issues.apache.org/jira/browse/WICKET-6970
Project: Wicket
Issue Type: Bug
Components: wicket-core
Affects Versions: 10.0.0, 9.9.0
Reporter: Emond Papegaaij
{{AssociatedMarkupSourcingStrategy.renderAssociatedMarkup}} builds a string
just for an exception message. The method
{{MarkupContainer.renderAssociatedMarkup}} is only called from this single
location and is not really meant for public consumption. I suggest we inline
the message and only build it when it's actually needed. For 9.x we must keep
the parameter, but we can call it with {{null.}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[wicket] branch master updated: Guarantee order of listener notifications
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 4d43eb5 Guarantee order of listener notifications
4d43eb5 is described below
commit 4d43eb563733c921e6256278458f0071e0a52061
Author: Emond Papegaaij
AuthorDate: Tue Mar 22 11:43:19 2022 +0100
Guarantee order of listener notifications
---
.../main/java/org/apache/wicket/util/listener/ListenerCollection.java | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/wicket-util/src/main/java/org/apache/wicket/util/listener/ListenerCollection.java
b/wicket-util/src/main/java/org/apache/wicket/util/listener/ListenerCollection.java
index 0d476bc..d774cdc 100644
---
a/wicket-util/src/main/java/org/apache/wicket/util/listener/ListenerCollection.java
+++
b/wicket-util/src/main/java/org/apache/wicket/util/listener/ListenerCollection.java
@@ -28,7 +28,8 @@ import org.slf4j.LoggerFactory;
/**
* Represents a collection of listeners. Facilitates invocation of events on
each listener.
*
- * NOTE: Ordering of listeners is not guaranteed and should not be relied upon
+ * Listeners will be invoked in the order added to the collection when using
+ * {@link #notify(INotifier)} or in reversed order when using {@link
#reversedNotify(INotifier)}.
*
*
* @author ivaynberg (Igor Vaynberg)
[wicket] branch wicket-9.x updated (9278637 -> dcf11e6)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-9.x in repository https://gitbox.apache.org/repos/asf/wicket.git. from 9278637 WICKET-6963 Use singletons for PanelMarkupSourcingStrategy (#503) add 4c67107 Guarantee order of listener notifications new dcf11e6 Merge remote-tracking branch 'papegaaij/notify-listener-doc' into wicket-9.x The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../main/java/org/apache/wicket/util/listener/ListenerCollection.java | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
[wicket] 01/01: Merge remote-tracking branch 'papegaaij/notify-listener-doc' into wicket-9.x
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch wicket-9.x in repository https://gitbox.apache.org/repos/asf/wicket.git commit dcf11e6e2f789d1589fd76cbe504190a0ef03c24 Merge: 9278637 4c67107 Author: Emond Papegaaij AuthorDate: Wed Mar 23 20:51:26 2022 +0100 Merge remote-tracking branch 'papegaaij/notify-listener-doc' into wicket-9.x .../main/java/org/apache/wicket/util/listener/ListenerCollection.java | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
[jira] [Commented] (WICKET-6959) Form#setDefaultButton does not work under Safari
[
https://issues.apache.org/jira/browse/WICKET-6959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500740#comment-17500740
]
Emond Papegaaij commented on WICKET-6959:
-
Actually, I think Safari has it wrong. This is from the HTML 5 specification
https://html.spec.whatwg.org/#the-hidden-attribute
{quote}Elements in a section hidden by the hidden attribute are still active,
e.g. scripts and form controls in such sections still execute and submit
respectively. Only their presentation to the user changes.{quote}
> Form#setDefaultButton does not work under Safari
>
>
> Key: WICKET-6959
> URL: https://issues.apache.org/jira/browse/WICKET-6959
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 9.7.0, 9.8.0
> Environment: Safari 15.3
> macOS 12.2
>Reporter: felix.rill...@cryptshare.com
>Priority: Minor
> Attachments: PoC Safari and setDefaultButton.zip
>
>
> setDefaultButton uses a hidden submit component. In most major browsers, this
> works well and allows one to submit a form by pressing 'Enter' while in a
> e.g. TextField.
> Safari seems to ignore the hidden submit component, which makes it impossible
> to submit the form by using 'Enter' if the submit button is outside the form
> (attached is a Proof of Concept).
> If instead of using the HTML 'hidden' attribute, the hidden submit component
> is made invisible by other means (e.g. moving it outside the viewport), it
> works.
>
> As the JavaDoc of setDefaultButton already state "note that this is a best
> effort only", this probably not a priority.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WICKET-6938) wicket-autocomplete.js not CSP compliant
[ https://issues.apache.org/jira/browse/WICKET-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452554#comment-17452554 ] Emond Papegaaij commented on WICKET-6938: - [~alfortin] This will need to be addressed in the component itself. I think [~mgrigorov] is working on a solution, right? If not, I can have a look, but that will be next week, as I'm a bit occupied this week. > wicket-autocomplete.js not CSP compliant > > > Key: WICKET-6938 > URL: https://issues.apache.org/jira/browse/WICKET-6938 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 9.6.0 >Reporter: Alexandre >Priority: Major > > While upgrading from wicket 8 to 9.6 we are trying to implement CSP. We also > use the autocompletebehavior. This in turn call wicket-autocomplete.js > (wicket-extensions\src\main\java\org\apache\wicket\extensions\ajax\markup\html\autocomplete). > This js file contains "handleSelection" function trying to "eval(attr.value)" > throwing a CSP 'unsafe-eval' exception. > So the autocomplete textfield will display choices, but won't handle user > selection. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (WICKET-6938) wicket-autocomplete.js not CSP compliant
[
https://issues.apache.org/jira/browse/WICKET-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452500#comment-17452500
]
Emond Papegaaij commented on WICKET-6938:
-
[~alfortin] You cannot use eval in any way without unsafe-eval, and that needs
to be set in the CSP of your page, which probably is not what you want. This
needs to be fixed by rendering the {{getOnSelectJavaScriptExpression}} in a
proper event handler, which will be part of the head of your page. There, you
should not need eval because the event handler already is executable javascript
(and not a text-value of an attribute). It's probably similar to what I did
here for links:
https://github.com/apache/wicket/commit/bcda1de49a4b3faa74d0a11e893bba9d099ea9bc
> wicket-autocomplete.js not CSP compliant
>
>
> Key: WICKET-6938
> URL: https://issues.apache.org/jira/browse/WICKET-6938
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 9.6.0
>Reporter: Alexandre
>Priority: Major
>
> While upgrading from wicket 8 to 9.6 we are trying to implement CSP. We also
> use the autocompletebehavior. This in turn call wicket-autocomplete.js
> (wicket-extensions\src\main\java\org\apache\wicket\extensions\ajax\markup\html\autocomplete).
> This js file contains "handleSelection" function trying to "eval(attr.value)"
> throwing a CSP 'unsafe-eval' exception.
> So the autocomplete textfield will display choices, but won't handle user
> selection.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WICKET-6913) Java 17 compatibility
[
https://issues.apache.org/jira/browse/WICKET-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400259#comment-17400259
]
Emond Papegaaij commented on WICKET-6913:
-
That's unfortunate, as these modules are obviously never meant to be used
together. Instead of a system property, I would then go for class detection: if
ByteBuddy is on the classpath, use that, if it's not, fallback to CGLib.
> Java 17 compatibility
> -
>
> Key: WICKET-6913
> URL: https://issues.apache.org/jira/browse/WICKET-6913
> Project: Wicket
> Issue Type: Bug
> Components: wicket-spring
>Affects Versions: 9.4.0
>Reporter: Robert Bain
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0
>
>
> Wicket's use of cglib means that as of Java 16, you need to specify
> --illegal-access=permit. As of Java 17, this is no longer possible, which
> I've verified using a JDK 17 Early-Access Build.
> See [https://github.com/cglib/cglib/issues/191]
> See
> [https://stackoverflow.com/questions/66974846/java-lang-exceptionininitializererror-with-java-16-j-l-classformaterror-access]
>
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> net.sf.cglib.proxy.EnhancerCaused by: java.lang.NoClassDefFoundError: Could
> not initialize class net.sf.cglib.proxy.Enhancer at
> org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:182)
> at
> org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:166)
> at org.apache.wicket.injection.Injector.inject(Injector.java:111) at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
> at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.onInstantiation(SpringComponentInjector.java:130)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34)
> at
> org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33)
> at org.apache.wicket.Component.(Component.java:690) at
> org.apache.wicket.MarkupContainer.(MarkupContainer.java:179) at
> org.apache.wicket.Page.(Page.java:171) at
> org.apache.wicket.Page.(Page.java:135) at
> org.apache.wicket.markup.html.WebPage.(WebPage.java:74)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6913) Java 17 compatibility
[
https://issues.apache.org/jira/browse/WICKET-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17400173#comment-17400173
]
Emond Papegaaij commented on WICKET-6913:
-
A dependency upgrade normally is fine, but we guarantee API compatibility on
upgrades within a major version. There's always a bit of a gray area when it
comes to API changes in dependencies, as this is technically speaking not the
Wicket API. However, swapping one dependency for an entirely different one can
have serious consequences when upgrading. Therefore I opt to copy the updated
module to Wicket 9.x under a new name. That way, we can stay entirely API
compatible, and still offer support for Java 17.
> Java 17 compatibility
> -
>
> Key: WICKET-6913
> URL: https://issues.apache.org/jira/browse/WICKET-6913
> Project: Wicket
> Issue Type: Bug
> Components: wicket-spring
>Affects Versions: 9.4.0
>Reporter: Robert Bain
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0
>
>
> Wicket's use of cglib means that as of Java 16, you need to specify
> --illegal-access=permit. As of Java 17, this is no longer possible, which
> I've verified using a JDK 17 Early-Access Build.
> See [https://github.com/cglib/cglib/issues/191]
> See
> [https://stackoverflow.com/questions/66974846/java-lang-exceptionininitializererror-with-java-16-j-l-classformaterror-access]
>
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> net.sf.cglib.proxy.EnhancerCaused by: java.lang.NoClassDefFoundError: Could
> not initialize class net.sf.cglib.proxy.Enhancer at
> org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:182)
> at
> org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:166)
> at org.apache.wicket.injection.Injector.inject(Injector.java:111) at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
> at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.onInstantiation(SpringComponentInjector.java:130)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34)
> at
> org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33)
> at org.apache.wicket.Component.(Component.java:690) at
> org.apache.wicket.MarkupContainer.(MarkupContainer.java:179) at
> org.apache.wicket.Page.(Page.java:171) at
> org.apache.wicket.Page.(Page.java:135) at
> org.apache.wicket.markup.html.WebPage.(WebPage.java:74)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6913) Java 17 compatibility
[
https://issues.apache.org/jira/browse/WICKET-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17399989#comment-17399989
]
Emond Papegaaij commented on WICKET-6913:
-
Or we could copy the new module from master to 9.x under a new name
(wicket-oic-bytebuddy) and provide both. I don't think we can just change the
implementation, as minor versions are supposed to be drop-in replacements, and
IMHO that's not true if the dependencies change. However, you might also argue
that this is just an implementation detail and the API doesn't change. I do
agree with Robert, that we should try to support Java 17, the next LTS, for
Wicket 9.x.
> Java 17 compatibility
> -
>
> Key: WICKET-6913
> URL: https://issues.apache.org/jira/browse/WICKET-6913
> Project: Wicket
> Issue Type: Bug
> Components: wicket-spring
>Affects Versions: 9.4.0
>Reporter: Robert Bain
>Assignee: Martin Tzvetanov Grigorov
>Priority: Major
> Fix For: 10.0.0
>
>
> Wicket's use of cglib means that as of Java 16, you need to specify
> --illegal-access=permit. As of Java 17, this is no longer possible, which
> I've verified using a JDK 17 Early-Access Build.
> See [https://github.com/cglib/cglib/issues/191]
> See
> [https://stackoverflow.com/questions/66974846/java-lang-exceptionininitializererror-with-java-16-j-l-classformaterror-access]
>
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> net.sf.cglib.proxy.EnhancerCaused by: java.lang.NoClassDefFoundError: Could
> not initialize class net.sf.cglib.proxy.Enhancer at
> org.apache.wicket.proxy.LazyInitProxyFactory.createProxy(LazyInitProxyFactory.java:182)
> at
> org.apache.wicket.spring.injection.annot.AnnotProxyFieldValueFactory.getFieldValue(AnnotProxyFieldValueFactory.java:166)
> at org.apache.wicket.injection.Injector.inject(Injector.java:111) at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.inject(SpringComponentInjector.java:124)
> at
> org.apache.wicket.spring.injection.annot.SpringComponentInjector.onInstantiation(SpringComponentInjector.java:130)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34)
> at
> org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80)
> at
> org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33)
> at org.apache.wicket.Component.(Component.java:690) at
> org.apache.wicket.MarkupContainer.(MarkupContainer.java:179) at
> org.apache.wicket.Page.(Page.java:171) at
> org.apache.wicket.Page.(Page.java:135) at
> org.apache.wicket.markup.html.WebPage.(WebPage.java:74)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[wicket] branch master updated: Remove unused logger
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new c633aca Remove unused logger
c633aca is described below
commit c633acac3c645b9ea1f41623b204dd1fb2cd02d5
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 16:01:20 2021 +0100
Remove unused logger
---
.../java/org/apache/wicket/protocol/http/request/WebClientInfo.java | 4
1 file changed, 4 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index dc3d2c4..cc4df9b 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -23,8 +23,6 @@ import org.apache.wicket.markup.html.pages.BrowserInfoPage;
import org.apache.wicket.protocol.http.ClientProperties;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
-import org.slf4j.Logger;
-import org.slf4j.LoggerFactory;
/**
@@ -36,8 +34,6 @@ public class WebClientInfo extends ClientInfo
{
private static final long serialVersionUID = 1L;
- private static final Logger log =
LoggerFactory.getLogger(WebClientInfo.class);
-
/**
* The user agent string from the User-Agent header, app.
Theoretically, this might differ from
* {@link
org.apache.wicket.protocol.http.ClientProperties#isNavigatorJavaEnabled()}
property, which is
[wicket] 02/02: Cleanup code and updated tests for new getRemoteAddr behavior
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-7.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit 7580540f9321dffe4bfb18f0ddb523a410f9ad8a
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 14:02:39 2021 +0100
Cleanup code and updated tests for new getRemoteAddr behavior
---
.../protocol/http/request/WebClientInfo.java | 5 --
.../protocol/http/request/WebClientInfoTest.java | 65 +-
2 files changed, 2 insertions(+), 68 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index c7ce9ee..0127c5e 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -16,21 +16,16 @@
*/
package org.apache.wicket.protocol.http.request;
-import java.net.InetAddress;
-import java.net.UnknownHostException;
import java.util.Locale;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
-import javax.servlet.http.HttpServletRequest;
-
import org.apache.wicket.core.request.ClientInfo;
import org.apache.wicket.markup.html.pages.BrowserInfoPage;
import org.apache.wicket.protocol.http.ClientProperties;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
import org.apache.wicket.util.string.StringValue;
-import org.apache.wicket.util.string.Strings;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
diff --git
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
index 10ed68d..de44888 100644
---
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
@@ -32,9 +32,7 @@ import javax.servlet.http.HttpServletRequest;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
import org.junit.Before;
-import org.junit.Ignore;
import org.junit.Test;
-import org.mockito.Mockito;
/**
* Tests the WebClientInfo class
@@ -885,39 +883,6 @@ public class WebClientInfoTest
}
}
-
- /**
-* Test X-Forwarded-For ip address extraction.
-*/
- @Test
- public void testExtractFromXForwardedForHeader()
- {
- String expected = "127.0.0.1";
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(expected);
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertThat(actual, is(equalTo(expected)));
- Mockito.verifyZeroInteractions(servletRequest);
- }
-
- /**
-* Test X-Forwarded-For ip address extraction with fallback when no ip
is contained.
-*
-* Note mgrigorov: this test could fail in network setups where unknown
addresses, like "blah",
-* will resolve to some DNS service saying "'blah' domain is free. Buy
it."
-*/
- @Test
- @Ignore
- public void testExtractFromContainerRequestUnknownXForwardedFor()
- {
- String expected = "10.17.37.8";
- when(servletRequest.getRemoteAddr()).thenReturn(expected);
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn("unknown");
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertThat(actual, is(equalTo(expected)));
- }
-
/**
* Test default ip address extraction for container request.
*/
@@ -925,37 +890,11 @@ public class WebClientInfoTest
public void testExtractFromContainerRequestNoXForwardedFor()
{
String expected = "10.17.37.8";
+ String invalid = "10.17.9.55";
when(servletRequest.getRemoteAddr()).thenReturn(expected);
+
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(invalid);
WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
String actual = clientInfo.getRemoteAddr(requestCycleMock);
assertThat(actual, is(equalTo(expected)));
}
-
- /**
-* Test X-Forwarded-For ip address extraction when proxy chain is given.
-*/
-
[wicket] branch wicket-7.x updated (6716a4e -> 7580540)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-7.x in repository https://gitbox.apache.org/repos/asf/wicket.git. from 6716a4e Update Spotify Dockerfile Maven plugin version to 1.4.13 new 9963d7d Do not try to resolve X-Forwarded-For header new 7580540 Cleanup code and updated tests for new getRemoteAddr behavior The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../protocol/http/request/WebClientInfo.java | 45 ++- .../protocol/http/request/WebClientInfoTest.java | 65 +- 2 files changed, 6 insertions(+), 104 deletions(-)
[wicket] 01/02: Do not try to resolve X-Forwarded-For header
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-7.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit 9963d7d6a7c737b73fcd11a30659a8d0136ab407
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 13:28:15 2021 +0100
Do not try to resolve X-Forwarded-For header
The remote address is reported by HttpServletRequest. Configuration of
this property is normally done via the application server. If this is
somehow not possible, use XForwardedRequestWrapperFactory.
---
.../protocol/http/request/WebClientInfo.java | 40 +++---
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index c00dc47..c7ce9ee 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -145,49 +145,17 @@ public class WebClientInfo extends ClientInfo
}
/**
-* When using ProxyPass, requestCycle().getHttpServletRequest().
getRemoteAddr() returns the IP
-* of the machine forwarding the request. In order to maintain the
clients ip address, the
-* server places it in the http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers;>X-Forwarded-For
-* Header.
-*
-* Proxies may also mask the original client IP with tokens like
"hidden" or "unknown".
-* If so, the last proxy ip address is returned.
+* Returns the IP address from {@code
HttpServletRequest.getRemoteAddr()}.
*
* @param requestCycle
*the request cycle
-* @return remoteAddr IP address of the client, using the
X-Forwarded-For header and defaulting
-* to: getHttpServletRequest().getRemoteAddr()
+* @return remoteAddr IP address of the client, using
+* {@code getHttpServletRequest().getRemoteAddr()}
*/
protected String getRemoteAddr(RequestCycle requestCycle)
{
ServletWebRequest request =
(ServletWebRequest)requestCycle.getRequest();
- HttpServletRequest req = request.getContainerRequest();
- String remoteAddr = request.getHeader("X-Forwarded-For");
-
- if (remoteAddr != null)
- {
- if (remoteAddr.contains(","))
- {
- // sometimes the header is of form client
ip,proxy 1 ip,proxy 2 ip,...,proxy n ip,
- // we just want the client
- remoteAddr = Strings.split(remoteAddr,
',')[0].trim();
- }
- try
- {
- // If ip4/6 address string handed over, simply
does pattern validation.
- InetAddress.getByName(remoteAddr);
- }
- catch (UnknownHostException e)
- {
- remoteAddr = req.getRemoteAddr();
- }
- }
- else
- {
- remoteAddr = req.getRemoteAddr();
- }
- return remoteAddr;
+ return request.getContainerRequest().getRemoteAddr();
}
/**
[wicket] 02/02: Cleanup code and updated tests for new getRemoteAddr behavior
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-8.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit af6dfbdff02b5f7e8a4e67d13893aa9866d211f0
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 14:02:39 2021 +0100
Cleanup code and updated tests for new getRemoteAddr behavior
---
.../protocol/http/request/WebClientInfo.java | 5 --
.../protocol/http/request/WebClientInfoTest.java | 65 +-
2 files changed, 2 insertions(+), 68 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index c7ce9ee..0127c5e 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -16,21 +16,16 @@
*/
package org.apache.wicket.protocol.http.request;
-import java.net.InetAddress;
-import java.net.UnknownHostException;
import java.util.Locale;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
-import javax.servlet.http.HttpServletRequest;
-
import org.apache.wicket.core.request.ClientInfo;
import org.apache.wicket.markup.html.pages.BrowserInfoPage;
import org.apache.wicket.protocol.http.ClientProperties;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
import org.apache.wicket.util.string.StringValue;
-import org.apache.wicket.util.string.Strings;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
diff --git
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
index 10ed68d..de44888 100644
---
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
@@ -32,9 +32,7 @@ import javax.servlet.http.HttpServletRequest;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
import org.junit.Before;
-import org.junit.Ignore;
import org.junit.Test;
-import org.mockito.Mockito;
/**
* Tests the WebClientInfo class
@@ -885,39 +883,6 @@ public class WebClientInfoTest
}
}
-
- /**
-* Test X-Forwarded-For ip address extraction.
-*/
- @Test
- public void testExtractFromXForwardedForHeader()
- {
- String expected = "127.0.0.1";
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(expected);
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertThat(actual, is(equalTo(expected)));
- Mockito.verifyZeroInteractions(servletRequest);
- }
-
- /**
-* Test X-Forwarded-For ip address extraction with fallback when no ip
is contained.
-*
-* Note mgrigorov: this test could fail in network setups where unknown
addresses, like "blah",
-* will resolve to some DNS service saying "'blah' domain is free. Buy
it."
-*/
- @Test
- @Ignore
- public void testExtractFromContainerRequestUnknownXForwardedFor()
- {
- String expected = "10.17.37.8";
- when(servletRequest.getRemoteAddr()).thenReturn(expected);
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn("unknown");
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertThat(actual, is(equalTo(expected)));
- }
-
/**
* Test default ip address extraction for container request.
*/
@@ -925,37 +890,11 @@ public class WebClientInfoTest
public void testExtractFromContainerRequestNoXForwardedFor()
{
String expected = "10.17.37.8";
+ String invalid = "10.17.9.55";
when(servletRequest.getRemoteAddr()).thenReturn(expected);
+
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(invalid);
WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
String actual = clientInfo.getRemoteAddr(requestCycleMock);
assertThat(actual, is(equalTo(expected)));
}
-
- /**
-* Test X-Forwarded-For ip address extraction when proxy chain is given.
-*/
-
[wicket] branch wicket-8.x updated (24c67b3 -> af6dfbd)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-8.x in repository https://gitbox.apache.org/repos/asf/wicket.git. from 24c67b3 WICKET-6868 ajax submit allow trigger submit on form new c2da3ad Do not try to resolve X-Forwarded-For header new af6dfbd Cleanup code and updated tests for new getRemoteAddr behavior The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../protocol/http/request/WebClientInfo.java | 45 ++- .../protocol/http/request/WebClientInfoTest.java | 65 +- 2 files changed, 6 insertions(+), 104 deletions(-)
[wicket] 01/02: Do not try to resolve X-Forwarded-For header
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-8.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
commit c2da3ade7f93abc5ec4c502401e9a6d639eb9331
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 13:28:15 2021 +0100
Do not try to resolve X-Forwarded-For header
The remote address is reported by HttpServletRequest. Configuration of
this property is normally done via the application server. If this is
somehow not possible, use XForwardedRequestWrapperFactory.
---
.../protocol/http/request/WebClientInfo.java | 40 +++---
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index c00dc47..c7ce9ee 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -145,49 +145,17 @@ public class WebClientInfo extends ClientInfo
}
/**
-* When using ProxyPass, requestCycle().getHttpServletRequest().
getRemoteAddr() returns the IP
-* of the machine forwarding the request. In order to maintain the
clients ip address, the
-* server places it in the http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers;>X-Forwarded-For
-* Header.
-*
-* Proxies may also mask the original client IP with tokens like
"hidden" or "unknown".
-* If so, the last proxy ip address is returned.
+* Returns the IP address from {@code
HttpServletRequest.getRemoteAddr()}.
*
* @param requestCycle
*the request cycle
-* @return remoteAddr IP address of the client, using the
X-Forwarded-For header and defaulting
-* to: getHttpServletRequest().getRemoteAddr()
+* @return remoteAddr IP address of the client, using
+* {@code getHttpServletRequest().getRemoteAddr()}
*/
protected String getRemoteAddr(RequestCycle requestCycle)
{
ServletWebRequest request =
(ServletWebRequest)requestCycle.getRequest();
- HttpServletRequest req = request.getContainerRequest();
- String remoteAddr = request.getHeader("X-Forwarded-For");
-
- if (remoteAddr != null)
- {
- if (remoteAddr.contains(","))
- {
- // sometimes the header is of form client
ip,proxy 1 ip,proxy 2 ip,...,proxy n ip,
- // we just want the client
- remoteAddr = Strings.split(remoteAddr,
',')[0].trim();
- }
- try
- {
- // If ip4/6 address string handed over, simply
does pattern validation.
- InetAddress.getByName(remoteAddr);
- }
- catch (UnknownHostException e)
- {
- remoteAddr = req.getRemoteAddr();
- }
- }
- else
- {
- remoteAddr = req.getRemoteAddr();
- }
- return remoteAddr;
+ return request.getContainerRequest().getRemoteAddr();
}
/**
[wicket] branch master updated: Cleanup code and updated tests for new getRemoteAddr behavior
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new a9adfe6 Cleanup code and updated tests for new getRemoteAddr behavior
a9adfe6 is described below
commit a9adfe62931c97dde55ccf21c4c91e1992aecf08
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 14:02:39 2021 +0100
Cleanup code and updated tests for new getRemoteAddr behavior
---
.../protocol/http/request/WebClientInfo.java | 5 --
.../protocol/http/request/WebClientInfoTest.java | 64 +-
2 files changed, 2 insertions(+), 67 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index d8e552c..dc3d2c4 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -16,18 +16,13 @@
*/
package org.apache.wicket.protocol.http.request;
-import java.net.InetAddress;
-import java.net.UnknownHostException;
import java.util.Locale;
-import javax.servlet.http.HttpServletRequest;
-
import org.apache.wicket.core.request.ClientInfo;
import org.apache.wicket.markup.html.pages.BrowserInfoPage;
import org.apache.wicket.protocol.http.ClientProperties;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
-import org.apache.wicket.util.string.Strings;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
diff --git
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
index 2c01d91..02b0b10 100644
---
a/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/protocol/http/request/WebClientInfoTest.java
@@ -25,9 +25,7 @@ import javax.servlet.http.HttpServletRequest;
import org.apache.wicket.protocol.http.servlet.ServletWebRequest;
import org.apache.wicket.request.cycle.RequestCycle;
import org.junit.jupiter.api.BeforeEach;
-import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
-import org.mockito.Mockito;
/**
* Tests the WebClientInfo class
@@ -54,75 +52,17 @@ class WebClientInfoTest
}
/**
-* Test X-Forwarded-For ip address extraction.
-*/
- @Test
- void testExtractFromXForwardedForHeader()
- {
- String expected = "127.0.0.1";
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(expected);
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertEquals(expected, actual);
- Mockito.verifyNoInteractions(servletRequest);
- }
-
- /**
-* Test X-Forwarded-For ip address extraction with fallback when no ip
is contained.
-*
-* Note mgrigorov: this test could fail in network setups where unknown
addresses, like "blah",
-* will resolve to some DNS service saying "'blah' domain is free. Buy
it."
-*/
- @Test
- @Disabled
- void testExtractFromContainerRequestUnknownXForwardedFor()
- {
- String expected = "10.17.37.8";
- when(servletRequest.getRemoteAddr()).thenReturn(expected);
-
when(webRequest.getHeader("X-Forwarded-For")).thenReturn("unknown");
- WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
- String actual = clientInfo.getRemoteAddr(requestCycleMock);
- assertEquals(expected, actual);
- }
-
- /**
* Test default ip address extraction for container request.
*/
@Test
void testExtractFromContainerRequestNoXForwardedFor()
{
String expected = "10.17.37.8";
+ String invalid = "10.17.9.55";
when(servletRequest.getRemoteAddr()).thenReturn(expected);
+
when(webRequest.getHeader("X-Forwarded-For")).thenReturn(invalid);
WebClientInfo clientInfo = new WebClientInfo(requestCycleMock,
"No user agent");
String actual = clientInfo.getRemoteAddr(requestCycleMock);
assertEquals(expected, actual);
}
-
- /**
-* Test X-Forwarded-For ip address extraction when proxy chain is given.
-*/
- @Test
- vo
[wicket] branch master updated: Do not try to resolve X-Forwarded-For header
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 84f62a5 Do not try to resolve X-Forwarded-For header
84f62a5 is described below
commit 84f62a5cff462eaa3bfaf171b0638c7e7feea30d
Author: Emond Papegaaij
AuthorDate: Fri Mar 5 13:28:15 2021 +0100
Do not try to resolve X-Forwarded-For header
The remote address is reported by HttpServletRequest. Configuration of
this property is normally done via the application server. If this is
somehow not possible, use XForwardedRequestWrapperFactory.
---
.../protocol/http/request/WebClientInfo.java | 40 +++---
1 file changed, 4 insertions(+), 36 deletions(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
index b5d0544..d8e552c 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/request/WebClientInfo.java
@@ -140,48 +140,16 @@ public class WebClientInfo extends ClientInfo
}
/**
-* When using ProxyPass, requestCycle().getHttpServletRequest().
getRemoteAddr() returns the IP
-* of the machine forwarding the request. In order to maintain the
clients ip address, the
-* server places it in the http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#x-headers;>X-Forwarded-For
-* Header.
-*
-* Proxies may also mask the original client IP with tokens like
"hidden" or "unknown".
-* If so, the last proxy ip address is returned.
+* Returns the IP address from {@code
HttpServletRequest.getRemoteAddr()}.
*
* @param requestCycle
*the request cycle
-* @return remoteAddr IP address of the client, using the
X-Forwarded-For header and defaulting
-* to: getHttpServletRequest().getRemoteAddr()
+* @return remoteAddr IP address of the client, using
+* {@code getHttpServletRequest().getRemoteAddr()}
*/
protected String getRemoteAddr(RequestCycle requestCycle)
{
ServletWebRequest request =
(ServletWebRequest)requestCycle.getRequest();
- HttpServletRequest req = request.getContainerRequest();
- String remoteAddr = request.getHeader("X-Forwarded-For");
-
- if (remoteAddr != null)
- {
- if (remoteAddr.contains(","))
- {
- // sometimes the header is of form client
ip,proxy 1 ip,proxy 2 ip,...,proxy n ip,
- // we just want the client
- remoteAddr = Strings.split(remoteAddr,
',')[0].trim();
- }
- try
- {
- // If ip4/6 address string handed over, simply
does pattern validation.
- InetAddress.getByName(remoteAddr);
- }
- catch (UnknownHostException e)
- {
- remoteAddr = req.getRemoteAddr();
- }
- }
- else
- {
- remoteAddr = req.getRemoteAddr();
- }
- return remoteAddr;
+ return request.getContainerRequest().getRemoteAddr();
}
}
[jira] [Closed] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij closed WICKET-6861.
---
Resolution: Won't Fix
Closing this issue. I've tried several solutions and came to the conclusion
that this one is very hard to fix in a general way. For our application, we now
set a data attribute on the document when the timer should stop and check this
attribute in a precondition. That works 100% reliable but will be impossible to
convert into a general solution for all Wicket users.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270139#comment-17270139
]
Emond Papegaaij commented on WICKET-6861:
-
Ah, you mean {{_isPresent}} in {{wicket-ajax-jquery.js}}. That might work, but
that will require quite some changes in our codebase. I still like this to be
solved in the Wicket JS, that way it will work for everyone.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270056#comment-17270056
]
Emond Papegaaij commented on WICKET-6861:
-
That won't work either. In fact, when the server receives the Ajax request, the
entire http session doesn't even exist anymore. I've added code in our
application to ignore the request, but somehow all this triggers a CSP
violation (the nonces don't match) and that causes the test to fail.
One possible solution I've come up with is to queue the {{Wicket.Timer.clear}}
on the client when an Ajax request for the timer is currently executing. I'll
see if I can get that working somewhere next week.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270011#comment-17270011
]
Emond Papegaaij commented on WICKET-6861:
-
No, that won't help. The trigger function clears the timer before it does the
Ajax call. Adding that precondition will prevent all ajax calls for that timer:
{code:javascript}
Wicket.TimerHandles[timerId] = setTimeout(function() {
Wicket.Timer.clear(timerId);
f(); // this does the ajax call and here the timer is is never in
Wicket.TimerHandles
}, delay);
{code}
Also, if we change the trigger function to not clear {{timerId}}, it will still
not work, because the Ajax response of the first timer trigger in my event
trace will set it again. I think the only way to really fix this, is to mark a
timer as stopped in {{Wicket.TimerHandles}}. For example, we could put
{{false}} in {{Wicket.TimerHandles[timerId]}} and have {{Wicket.Timer.set}}
check that. However, that will break restarting a timer. The cause of the
problem lies in the fact that the timer does not really live on the client side
while it is executing its Ajax request.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269967#comment-17269967
]
Emond Papegaaij commented on WICKET-6861:
-
We've hit the same error again, with our patched version of
{{wicket-ajax-jquery.js}}, so the proposed change does not help. However, we've
also added a lot of logging (also to {{wicket-ajax-jquery.js}}) and captured
the console logs from the browser. I think I now know what is happening:
* The page is rendered with the timer activated
* The timer triggers and sends its Ajax request. Wicket Timers only trigger
once, so at this point the timer is cleared in the browser.
* The test clicks the Ajax link
* The click handler tries to clear the timer, but it is inactive, so nothing
happens.
* The Ajax request is queued on the channel.
* The response from the timer comes in and it sets the new timeout for the next
timer trigger.
* The queued Ajax request for the click is now executed.
* Lots of processing happens at the server
* The timer triggers again, even though it was supposed not to.
This sequence of events makes sense, but I'm not sure how to actually fix it.
The fact that these timers are triggered in the browser but managed on the
server makes it very hard to cover these race conditions.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267723#comment-17267723
]
Emond Papegaaij commented on WICKET-6861:
-
We are now running our tests with a patched version of
{{wicket-ajax-jquery.js}}. I'll update this ticket with the results. That might
take a while, because the failure is very infrequent.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
> {code}
> This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit
> and should therefore prevent the timer from triggering after the Ajax submit
> is done. However, in very rare occurrences we still see the timer triggering.
> When it happens, the timer is always directly after the Ajax submit (often
> within 10ms). This makes us believe the current implementation has a race
> condition in the following way:
> * The user clicks the Ajax submit link
> * The execution of the event handlers is started in the browser
> * At this moment the {{setTimeout}} triggers, but it is suspended because JS
> is single threaded and the browser is already execution JS in response to UI
> interaction
> * The first event handler now clears the timer
> * The second event handler performs the Ajax call
> * Now the JS executor is freed and the timer function is executed
> Although I'm not entirely at home in the execution model of JS in a browser,
> this is the only explanation I could come up with. There is no way to
> reproduce it, other than run a complex test suite 1000ths of times. My
> proposed fix is to replace the timeout function in {{wicket-ajax-jquery.js}}
> in {{Wicket.Timer.set}} with this:
> {code:javascript}
> Wicket.TimerHandles[timerId] = setTimeout(function() {
> if (timerId in Wicket.TimerHandles) {
> Wicket.Timer.clear(timerId);
> f();
> }
> }, delay);
> {code}
> This should prevent the function {{f()}} to be executed after the timer has
> been cleared (Wicket.Timer.clear deletes the {{timerId}} from
> {{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
[
https://issues.apache.org/jira/browse/WICKET-6861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17266176#comment-17266176
]
Emond Papegaaij commented on WICKET-6861:
-
I've read the same in the spec and it indeed states that my explanation is not
correct. However, I still see this behavior. I'm pretty sure that I'm clearing
the correct timer. These are some snippets from the logs:
{code}
... request that renders the form
2021-01-15 05:18:50,153 DEBUG
[nl.topicus.keyhub.web.components.panel.auth.TwoFactorAuthenticationSetupPanel]
(default task-1) Adding timer to class
nl.topicus.keyhub.web.components.panel.AccountOverviewPanel:1:account with id
account28.0
2021-01-15 05:18:50,249 DEBUG
[nl.topicus.keyhub.web.components.contextpanel.TwoFactorAuthenticationConfigPanel]
(default task-1) Adding clear timer script to cancel:
OnDomReadyHeaderItem('Wicket.Event.add('cancel2f', 'click', function()
{Wicket.Timer.clear('account28.0');})')
2021-01-15 05:18:50,252 DEBUG
[nl.topicus.keyhub.web.components.contextpanel.TwoFactorAuthenticationConfigPanel]
(default task-1) Adding clear timer script to action:
OnDomReadyHeaderItem('Wicket.Event.add('action30', 'click', function()
{Wicket.Timer.clear('account28.0');})')
... form submission request on
https://keyhub-test-app:8443/console/account?1-1.0-contextPopupPanel-form-action
2021-01-15 05:18:51,563 DEBUG
[nl.topicus.keyhub.web.components.panel.auth.TwoFactorAuthenticationSetupPanel]
(default task-1) Stopping timer account28.0
2021-01-15 05:18:51,564 DEBUG
[nl.topicus.keyhub.web.components.panel.auth.TwoFactorAuthenticationSetupPanel]
(default task-1) Removing timer
... timer request
2021-01-15 05:18:51,594 INFO
[nl.topicus.cobra.app.LoggingRequestCycleListener] (default task-7) Start of
request:
sessionId=6OY6wBc7OShw8yJ8whfnmVJpU-F2jTN-e8fsfy2t,isTemporary=false,httpUrl=[https://keyhub-test-app:8443/console/account?1-1.0-account&_=1610687929268],requestedSessionId=6OY6wBc7OShw8yJ8whfnmVJpU-F2jTN-e8fsfy2t
2021-01-15 05:18:51,604 WARN [RequestCycleExtra] (default task-7)
2021-01-15 05:18:51,604 WARN [RequestCycleExtra] (default task-7) Handling the
following exception: org.apache.wicket.behavior.InvalidBehaviorIdException:
Cannot find behavior with id '0' on component
'nl.topicus.keyhub.web.components.panel.AccountOverviewPanel:account' in page
'[Page class = nl.topicus.keyhub.web.pages.AccountProfielPage, id = 1, render
count = 1]'. Perhaps the behavior did not properly implement getStatelessHint()
and returned 'true' to indicate that it is stateless instead of returning
'false' to indicate that it is stateful.
{code}
As you can see in the logs, the ids and component paths all match.
Unfortunately, I cannot easily confirm that my proposed change fixes the
problem. I'll try if I can patch the js locally, but as the error only occurs
once every 1 or 2 weeks, it will take some time to verify (at least a month,
probably longer). For now, let's leave the code in Wicket as is, until we've
verified that it actually fixes the issue.
> Possible race condition in clearing and triggering of Wicket timers
> ---
>
> Key: WICKET-6861
> URL: https://issues.apache.org/jira/browse/WICKET-6861
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.2.0
> Reporter: Emond Papegaaij
>Priority: Minor
>
> In our test suite we see some intermittent failures related to
> {{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
> background poller at a 1 sec interval that checks for an out-of-band
> submission of the form data. So the user either has to fill the form via the
> web interface or via some other route. Either route can complete the form,
> but as soon as one of the two is triggered, the other must stop. The race
> condition lies in the {{AbstractAjaxTimerBehavior}} triggering while the user
> has already submitted the form manually.
> The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
> {{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
> However, this results in a very large gap between the moment of submission
> and the actual moment the timer is stopped. To fix this, we've added the
> following code to the {{AjaxSubmitLink}}:
> {code:java}
> @Override
> public void renderHead(IHeaderResponse response) {
> super.renderHead(response);
> response.render(OnDomReadyHeaderItem.forScript(
> "Wicket.Event.add('" + getMarkupId() + "', 'click', " +
> "function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
> }
[jira] [Created] (WICKET-6861) Possible race condition in clearing and triggering of Wicket timers
Emond Papegaaij created WICKET-6861:
---
Summary: Possible race condition in clearing and triggering of
Wicket timers
Key: WICKET-6861
URL: https://issues.apache.org/jira/browse/WICKET-6861
Project: Wicket
Issue Type: Bug
Components: wicket-core
Affects Versions: 9.2.0
Reporter: Emond Papegaaij
In our test suite we see some intermittent failures related to
{{AbstractAjaxTimerBehavior}}. At a few places in our application, we use a
background poller at a 1 sec interval that checks for an out-of-band submission
of the form data. So the user either has to fill the form via the web interface
or via some other route. Either route can complete the form, but as soon as one
of the two is triggered, the other must stop. The race condition lies in the
{{AbstractAjaxTimerBehavior}} triggering while the user has already submitted
the form manually.
The naive implementation would stop {{AbstractAjaxTimerBehavior}} via
{{Wicket.Timer.clear('timer0')}} in the Ajax response of the form submit.
However, this results in a very large gap between the moment of submission and
the actual moment the timer is stopped. To fix this, we've added the following
code to the {{AjaxSubmitLink}}:
{code:java}
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.render(OnDomReadyHeaderItem.forScript(
"Wicket.Event.add('" + getMarkupId() + "', 'click', " +
"function() {Wicket.Timer.clear('" + getTimerId() + "');})"));
}
{code}
This puts the call to {{Wicket.Timer.clear}} before the actual Ajax submit and
should therefore prevent the timer from triggering after the Ajax submit is
done. However, in very rare occurrences we still see the timer triggering. When
it happens, the timer is always directly after the Ajax submit (often within
10ms). This makes us believe the current implementation has a race condition in
the following way:
* The user clicks the Ajax submit link
* The execution of the event handlers is started in the browser
* At this moment the {{setTimeout}} triggers, but it is suspended because JS is
single threaded and the browser is already execution JS in response to UI
interaction
* The first event handler now clears the timer
* The second event handler performs the Ajax call
* Now the JS executor is freed and the timer function is executed
Although I'm not entirely at home in the execution model of JS in a browser,
this is the only explanation I could come up with. There is no way to reproduce
it, other than run a complex test suite 1000ths of times. My proposed fix is to
replace the timeout function in {{wicket-ajax-jquery.js}} in
{{Wicket.Timer.set}} with this:
{code:javascript}
Wicket.TimerHandles[timerId] = setTimeout(function() {
if (timerId in Wicket.TimerHandles) {
Wicket.Timer.clear(timerId);
f();
}
}, delay);
{code}
This should prevent the function {{f()}} to be executed after the timer has
been cleared (Wicket.Timer.clear deletes the {{timerId}} from
{{Wicket.TimerHandles}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6855) Request: Provide separate wicket-api.jar for interfaces
[ https://issues.apache.org/jira/browse/WICKET-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242714#comment-17242714 ] Emond Papegaaij commented on WICKET-6855: - The example projects you mentioned use the api-package for a totally different reason: they provide various different implementations of the same API. There is no second implementation of the Wicket-API and there will never be one. The problems you indicate with transitive dependencies will not be solved by introducing another package. To use Wicket, you will still need Wicket and its transitive dependencies on the classpath at runtime. Hiding these dependencies at compile-time, will solve nothing. I'm with Martin on this one, I see no benefit for Wicket to provide an API package, unless you are planning to develop a totally new implementation of Wicket. > Request: Provide separate wicket-api.jar for interfaces > --- > > Key: WICKET-6855 > URL: https://issues.apache.org/jira/browse/WICKET-6855 > Project: Wicket > Issue Type: Improvement >Reporter: Matt Pavlovich >Priority: Minor > > Providing a separate wicket-api.jar would provide benefit for web application > developers and web frameworks that are built on top of wicket by providing a > clean separation of concerns. > # All public interfaces into a org.apache.wicket.api.* package (IPage, > IPanel, etc) > # All internal interfaces into a org.apache.wicket.spi.* package (page > stores, serializers, etc) > This allows for a single-jar dependency for Wicket's framework and extension > layers. The current packaging co-locates interfaces and implementations into > the same packages, which also prevents the ability to repackage a > distribution of Wicket that had interfaces broken out. > Similar patterns followed in other open source projects: > apache log4j2-api > apache camel-api > etc.. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[ https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232163#comment-17232163 ] Emond Papegaaij commented on WICKET-6847: - Yes, this also affects 8.x. > async page storing fails with flush before detach without session > - > > Key: WICKET-6847 > URL: https://issues.apache.org/jira/browse/WICKET-6847 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 9.1.0 >Reporter: Sven Meier >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Fix For: 9.2.0 > > > Since WICKET-6831 the response is flushed before detach. > RequestPageStore delays storing all of stateful pages until detach; at that > moment AsynchronousPageStore can no longer acquire the required session id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[ https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230140#comment-17230140 ] Emond Papegaaij commented on WICKET-6847: - Yes, please retest, this piece of code is quite difficult to get right. > async page storing fails with flush before detach without session > - > > Key: WICKET-6847 > URL: https://issues.apache.org/jira/browse/WICKET-6847 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 9.1.0 >Reporter: Sven Meier >Assignee: Martin Tzvetanov Grigorov >Priority: Minor > Fix For: 9.2.0 > > > Since WICKET-6831 the response is flushed before detach. > RequestPageStore delays storing all of stateful pages until detach; at that > moment AsynchronousPageStore can no longer acquire the required session id. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[wicket] branch WICKET-6847-onEndRequest-before-flush updated: WICKET-6847: swap listeners and RequestCycle onEndRequest
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch WICKET-6847-onEndRequest-before-flush
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to
refs/heads/WICKET-6847-onEndRequest-before-flush by this push:
new 2f49bc2 WICKET-6847: swap listeners and RequestCycle onEndRequest
2f49bc2 is described below
commit 2f49bc2826e855a0882efb1409b0ad2188c08661
Author: Emond Papegaaij
AuthorDate: Wed Nov 11 16:21:19 2020 +0100
WICKET-6847: swap listeners and RequestCycle onEndRequest
This makes sure the session is destroyed (when needed) after the page
store handles the touched pages. This latter action can create a new
session if it was destroyed before, causing logout to fail.
---
.../src/main/java/org/apache/wicket/request/cycle/RequestCycle.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
b/wicket-core/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
index 2c0a8c7..33d1335 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/cycle/RequestCycle.java
@@ -263,8 +263,8 @@ public class RequestCycle implements IRequestCycle,
IEventSink, IMetadataContext
{
try
{
- onEndRequest();
listeners.onEndRequest(this);
+ onEndRequest();
}
catch (RuntimeException e)
{
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229901#comment-17229901
]
Emond Papegaaij commented on WICKET-6848:
-
Ok, I've found the cause. [~svenmeier] on your branch, the session is
invalidated before {{RequestPageStore.end}} is called. With the page still in
the touched pages, this causes a new session to be created in the same request.
Swapping the calls to {{onEndRequest}} in {{RequestCycle.processRequest}} fixes
it.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0, 8.10.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 9.2.0, 8.11.0
>
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChai
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229895#comment-17229895
]
Emond Papegaaij commented on WICKET-6848:
-
Sorry for being a bit late to reply. I've got a very busy schedule at the
moment. I've tested your changes on my quickstart and I no longer get the
error, but it seems logout is broken now. The session is invalidated, but a new
one is started right away and the user is still logged in. I'm looking into it
to see if I can find the cause of this.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0, 8.10.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 9.2.0, 8.11.0
>
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.underto
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[
https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227385#comment-17227385
]
Emond Papegaaij commented on WICKET-6847:
-
Yes, but in this case it simply calls {{super.touchPage}}, so it does not make
a difference for the flow.
> async page storing fails with flush before detach without session
> -
>
> Key: WICKET-6847
> URL: https://issues.apache.org/jira/browse/WICKET-6847
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.1.0
>Reporter: Sven Meier
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 9.2.0
>
>
> Since WICKET-6831 the response is flushed before detach.
> RequestPageStore delays storing all of stateful pages until detach; at that
> moment AsynchronousPageStore can no longer acquire the required session id.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[
https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227336#comment-17227336
]
Emond Papegaaij commented on WICKET-6847:
-
I'm looking at the change by [~mgrigorov] once more and I think it is
incorrect. {{RequestPageStore.addPage}} is called from {{Page.onInitialize}},
which can be called from {{Page.isPageStateless}} and now
{{RequestPageStore.addPage}} calls {{Page.isPageStateless}} again. IMHO this is
bound to give problems. Here's a stack dump from our application (on 9.1.0):
{code}
RequestPageStore.addPage(IPageContext, IManageablePage) line: 62
DecoratablePageManager(PageManager).touchPage(IManageablePage) line: 67
DecoratablePageManager.touchPage(IManageablePage) line: 22
PageAccessSynchronizer$1.touchPage(IManageablePage) line: 150
ConfigApplicationPage(Page).onInitialize() line: 301
ConfigApplicationPage(AbstractKeyHubPage).onInitialize() line: 64
ConfigApplicationPage(AbstractSecureKeyHubPage).onInitialize() line: 84
ConfigApplicationPage(AbstractKeyHubAdminPage).onInitialize() line: 57
ConfigApplicationPage.onInitialize() line: 25
ConfigApplicationPage(Component).fireInitialize() line: 874
ConfigApplicationPage(MarkupContainer).internalInitialize() line: 1050
ConfigApplicationPage(Page).isPageStateless() line: 461
{code}
> async page storing fails with flush before detach without session
> -
>
> Key: WICKET-6847
> URL: https://issues.apache.org/jira/browse/WICKET-6847
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.1.0
>Reporter: Sven Meier
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 9.2.0
>
>
> Since WICKET-6831 the response is flushed before detach.
> RequestPageStore delays storing all of stateful pages until detach; at that
> moment AsynchronousPageStore can no longer acquire the required session id.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[
https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227324#comment-17227324
]
Emond Papegaaij commented on WICKET-6847:
-
I think I know the cause of the problem. The check [~mgrigorov] added in
https://github.com/apache/wicket/commit/8664176abcc6393c54b29d058c655d440500bc8d
is done at a moment when we cannot always know if the page is stateless or
not. One of the locations it is called from is {{onInitialize}}, at which point
the page very likely does not hold any components yet. On thing I do find
strange though, is that I consistently get a second call from
{{onAfterRender}}, at which point the session is also created. [~reiern70]
could it be that you are instantiating pages without actually rendering them?
> async page storing fails with flush before detach without session
> -
>
> Key: WICKET-6847
> URL: https://issues.apache.org/jira/browse/WICKET-6847
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.1.0
>Reporter: Sven Meier
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 9.2.0
>
>
> Since WICKET-6831 the response is flushed before detach.
> RequestPageStore delays storing all of stateful pages until detach; at that
> moment AsynchronousPageStore can no longer acquire the required session id.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij updated WICKET-6848:
Affects Version/s: 8.10.0
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0, 8.10.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at
> io.undertow.core@2.1.3
[jira] [Resolved] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij resolved WICKET-6848.
-
Fix Version/s: 8.11.0
9.2.0
Assignee: Emond Papegaaij
Resolution: Fixed
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0, 8.10.0
> Reporter: Emond Papegaaij
>Assignee: Emond Papegaaij
>Priority: Major
> Fix For: 9.2.0, 8.11.0
>
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.under
[jira] [Commented] (WICKET-6847) async page storing fails with flush before detach without session
[
https://issues.apache.org/jira/browse/WICKET-6847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224632#comment-17224632
]
Emond Papegaaij commented on WICKET-6847:
-
[~reiern70] in WICKET-6848 you said you are still facing this issue on current
master. However, {{RequestPageStore}} does contain a fix for this, are you sure
you tested against the latest version? Do you have a quickstart?
> async page storing fails with flush before detach without session
> -
>
> Key: WICKET-6847
> URL: https://issues.apache.org/jira/browse/WICKET-6847
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 9.1.0
>Reporter: Sven Meier
>Assignee: Martin Tzvetanov Grigorov
>Priority: Minor
> Fix For: 9.2.0
>
>
> Since WICKET-6831 the response is flushed before detach.
> RequestPageStore delays storing all of stateful pages until detach; at that
> moment AsynchronousPageStore can no longer acquire the required session id.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[wicket] branch wicket-8.x updated: WICKET-6848: Do not flush before detach when session needs invalidation
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch wicket-8.x
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/wicket-8.x by this push:
new 8150ad1 WICKET-6848: Do not flush before detach when session needs
invalidation
8150ad1 is described below
commit 8150ad19cbb3b436f8e8aed32c766269811e6c62
Author: Emond Papegaaij
AuthorDate: Mon Nov 2 13:25:18 2020 +0100
WICKET-6848: Do not flush before detach when session needs invalidation
---
.../src/main/java/org/apache/wicket/Session.java | 19 ++-
.../org/apache/wicket/protocol/http/WicketFilter.java | 9 -
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/Session.java
b/wicket-core/src/main/java/org/apache/wicket/Session.java
index cdbffbf..066c2cb 100644
--- a/wicket-core/src/main/java/org/apache/wicket/Session.java
+++ b/wicket-core/src/main/java/org/apache/wicket/Session.java
@@ -551,7 +551,24 @@ public abstract class Session implements IClusterable,
IEventSink, IFeedbackCont
*/
public final boolean isSessionInvalidated()
{
- return
Boolean.TRUE.equals(RequestCycle.get().getMetaData(SESSION_INVALIDATED));
+ RequestCycle requestCycle = RequestCycle.get();
+ return isSessionInvalidated(requestCycle);
+ }
+
+ /**
+* Whether the session is invalid now, or will be invalidated by the
end of the request. Clients
+* should rarely need to use this method if ever.
+*
+* @param requestCycle
+*The current request cycle
+* @return Whether the session is invalid when the current request is
done
+*
+* @see #invalidate()
+* @see #invalidateNow()
+*/
+ public static boolean isSessionInvalidated(RequestCycle requestCycle)
+ {
+ return
Boolean.TRUE.equals(requestCycle.getMetaData(SESSION_INVALIDATED));
}
/**
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
index c53d0cd..5eb4fc6 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
@@ -31,6 +31,7 @@ import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.wicket.Session;
import org.apache.wicket.ThreadContext;
import org.apache.wicket.WicketRuntimeException;
import org.apache.wicket.protocol.http.servlet.ResponseIOException;
@@ -270,11 +271,13 @@ public class WicketFilter implements Filter
final FilterChain chain) throws IOException, ServletException
{
boolean reqProcessed;
+ boolean respFlushed = false;
try
{
reqProcessed = requestCycle.processRequest();
- if (reqProcessed)
+ if (reqProcessed &&
!Session.isSessionInvalidated(requestCycle))
{
+ respFlushed = true;
webResponse.flush();
}
}
@@ -291,6 +294,10 @@ public class WicketFilter implements Filter
chain.doFilter(httpServletRequest,
httpServletResponse);
}
}
+ else if (!respFlushed)
+ {
+ webResponse.flush();
+ }
return reqProcessed;
}
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224630#comment-17224630
]
Emond Papegaaij commented on WICKET-6848:
-
I've committed my patch as it does fix this particular issue, but that still
leaves us with WICKET-6847, which is very much related but about session
creation rather than invalidation.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
&
[wicket] branch master updated: WICKET-6848: Do not flush before detach when session needs invalidation
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 625f9af WICKET-6848: Do not flush before detach when session needs
invalidation
625f9af is described below
commit 625f9afd88efc98e5c01c89431067385a993d94d
Author: Emond Papegaaij
AuthorDate: Mon Nov 2 13:25:18 2020 +0100
WICKET-6848: Do not flush before detach when session needs invalidation
---
.../src/main/java/org/apache/wicket/Session.java | 19 ++-
.../org/apache/wicket/protocol/http/WicketFilter.java | 9 -
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/wicket-core/src/main/java/org/apache/wicket/Session.java
b/wicket-core/src/main/java/org/apache/wicket/Session.java
index 2376267..9d76c97 100644
--- a/wicket-core/src/main/java/org/apache/wicket/Session.java
+++ b/wicket-core/src/main/java/org/apache/wicket/Session.java
@@ -557,7 +557,24 @@ public abstract class Session implements IClusterable,
IEventSink, IMetadataCont
*/
public final boolean isSessionInvalidated()
{
- return
Boolean.TRUE.equals(RequestCycle.get().getMetaData(SESSION_INVALIDATED));
+ RequestCycle requestCycle = RequestCycle.get();
+ return isSessionInvalidated(requestCycle);
+ }
+
+ /**
+* Whether the session is invalid now, or will be invalidated by the
end of the request. Clients
+* should rarely need to use this method if ever.
+*
+* @param requestCycle
+*The current request cycle
+* @return Whether the session is invalid when the current request is
done
+*
+* @see #invalidate()
+* @see #invalidateNow()
+*/
+ public static boolean isSessionInvalidated(RequestCycle requestCycle)
+ {
+ return
Boolean.TRUE.equals(requestCycle.getMetaData(SESSION_INVALIDATED));
}
/**
diff --git
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
index 35c456c..c6faaad 100644
---
a/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
+++
b/wicket-core/src/main/java/org/apache/wicket/protocol/http/WicketFilter.java
@@ -32,6 +32,7 @@ import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
+import org.apache.wicket.Session;
import org.apache.wicket.ThreadContext;
import org.apache.wicket.WicketRuntimeException;
import org.apache.wicket.protocol.http.servlet.ResponseIOException;
@@ -271,11 +272,13 @@ public class WicketFilter implements Filter
final FilterChain chain) throws IOException, ServletException
{
boolean reqProcessed;
+ boolean respFlushed = false;
try
{
reqProcessed = requestCycle.processRequest();
- if (reqProcessed)
+ if (reqProcessed &&
!Session.isSessionInvalidated(requestCycle))
{
+ respFlushed = true;
webResponse.flush();
}
}
@@ -292,6 +295,10 @@ public class WicketFilter implements Filter
chain.doFilter(httpServletRequest,
httpServletResponse);
}
}
+ else if (!respFlushed)
+ {
+ webResponse.flush();
+ }
return reqProcessed;
}
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224529#comment-17224529
]
Emond Papegaaij commented on WICKET-6848:
-
It is important for the cookie to be cleared. For example, when you are in a
load balancing setup, the cookie is often used to stick the session to a
server. When the cookies aren't cleared on logout, sessions will not be
distributed cleanly.
I also don't know why we have invalidate() and invalidateNow(), but I'm
reluctant to change that in a minor version. Keep in mind we also have to patch
this on 8, as we very likely have the same problem in 8.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments:
> WICKET-6848-invalidate-session-manager-immediately.patch, WICKET-6848.diff,
> wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223680#comment-17223680
]
Emond Papegaaij commented on WICKET-6848:
-
[~reiern70] That's a different bug: WICKET-6847. This bug is about session
invalidation, the other about creation.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: WICKET-6848.diff, wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(S
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223618#comment-17223618
]
Emond Papegaaij commented on WICKET-6848:
-
No, that does not work. At that point the {{RequestCycle}} is not set on the
{{ThreadContext}}, which will result in a {{NullPointerException}} in
{{isInvalidated()}}. Also, {{Session.get()}} will create a session if it does
not yet exist, and I'd rather avoid that at this point. I didn't check if
{{Session.get()}} even returned the correct session. It could be that it simply
created a new one because the session was also not set on the context. Luckily,
we don't need the session for the check, because the boolean is stored as
metadata in the {{RequestCycle}}.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: WICKET-6848.diff, wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.
[jira] [Resolved] (WICKET-6849) quickstart styling is broken due to CSP
[ https://issues.apache.org/jira/browse/WICKET-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij resolved WICKET-6849. - Fix Version/s: 9.2.0 Assignee: Emond Papegaaij Resolution: Fixed > quickstart styling is broken due to CSP > --- > > Key: WICKET-6849 > URL: https://issues.apache.org/jira/browse/WICKET-6849 > Project: Wicket > Issue Type: Bug > Components: wicket-quickstart >Affects Versions: 9.1.0 > Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Major > Fix For: 9.2.0 > > > The quickstart was never fixed for CSP. It has several violations, including > the entire stylesheet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[wicket] branch master updated: WICKET-6849: Fix CSP for styling in quickstart
This is an automated email from the ASF dual-hosted git repository.
papegaaij pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/wicket.git
The following commit(s) were added to refs/heads/master by this push:
new 0acc6aa WICKET-6849: Fix CSP for styling in quickstart
0acc6aa is described below
commit 0acc6aa692d3993548db0daac61212b80b931b9b
Author: Emond Papegaaij
AuthorDate: Fri Oct 30 12:11:01 2020 +0100
WICKET-6849: Fix CSP for styling in quickstart
---
.../archetype-resources/src/main/java/WicketApplication.java | 8
1 file changed, 8 insertions(+)
diff --git
a/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
b/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
index 9979761..a77f034 100644
---
a/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
+++
b/archetypes/quickstart/src/main/resources/archetype-resources/src/main/java/WicketApplication.java
@@ -1,5 +1,7 @@
package ${package};
+import org.apache.wicket.csp.CSPDirective;
+import org.apache.wicket.csp.CSPDirectiveSrcValue;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.protocol.http.WebApplication;
@@ -28,6 +30,12 @@ public class WicketApplication extends WebApplication
{
super.init();
+ // needed for the styling used by the quickstart
+ getCspSettings().blocking()
+ .add(CSPDirective.STYLE_SRC, CSPDirectiveSrcValue.SELF)
+ .add(CSPDirective.STYLE_SRC,
"https://fonts.googleapis.com/css;)
+ .add(CSPDirective.FONT_SRC,
"https://fonts.gstatic.com;);
+
// add your configuration here
}
}
[jira] [Created] (WICKET-6849) quickstart styling is broken due to CSP
Emond Papegaaij created WICKET-6849: --- Summary: quickstart styling is broken due to CSP Key: WICKET-6849 URL: https://issues.apache.org/jira/browse/WICKET-6849 Project: Wicket Issue Type: Bug Components: wicket-quickstart Affects Versions: 9.1.0 Reporter: Emond Papegaaij The quickstart was never fixed for CSP. It has several violations, including the entire stylesheet. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223545#comment-17223545
]
Emond Papegaaij commented on WICKET-6848:
-
The attached patch fixes the issue by not flushing before detach when the
session is marked for invalidation. It fixes the issue, but I do not like this
special case. However, I do not see a way to fix the issue any other way.
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: WICKET-6848.diff, wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.exten
[jira] [Updated] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij updated WICKET-6848:
Attachment: WICKET-6848.diff
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: WICKET-6848.diff, wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at
> io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223529#comment-17223529
]
Emond Papegaaij commented on WICKET-6848:
-
I've done some more debugging and the current behavior definitely is broken.
When I remove the 'distributable' element from the web.xml and run it against
Wicket 9.0.0, I see a set-cookie header in the response of the logout request
to clear the JSESSIONID cookie. With 9.1.0 and master, this set-cookie header
is missing. So even though the stacktrace is not triggered, behavior has
changed.
What is puzzling though, is that on Jetty I do not get the set-cookie header,
not even on 9.0.0. Why is Jetty not clearing the cookie on logout? Is this a
bug?
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.ha
[jira] [Commented] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223506#comment-17223506
]
Emond Papegaaij commented on WICKET-6848:
-
I've managed to produce a quickstart for this problem, but the stacktrace only
occurs on WildFly, not on Jetty. Also, the session needs to be distributable to
trigger the error. I don't understand why a distributable session has different
characteristics on this. I would expect this to fail for every session type.
This bug is not fixed on master yet.
For the quickstart: build the application, deploy it on wildfly, navigate to
http://localhost:8080/wicket6848-1.0-SNAPSHOT and click on the link that says
'Click here!'
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handl
[jira] [Updated] (WICKET-6848) Session invalidation fails because response is already committed
[
https://issues.apache.org/jira/browse/WICKET-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emond Papegaaij updated WICKET-6848:
Attachment: wicket6848.zip
> Session invalidation fails because response is already committed
>
>
> Key: WICKET-6848
> URL: https://issues.apache.org/jira/browse/WICKET-6848
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
>Affects Versions: 9.1.0
> Reporter: Emond Papegaaij
>Priority: Major
> Attachments: wicket6848.zip
>
>
> Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
> related to the changes made with WICKET-6831. We are currently checking if
> this has been fixed by the latest changes on master, but I believe this is a
> different issue.
> From the stacktrace I deduce that the session is invalidated as part of
> detach, but as detach is now called after flush, it is no longer possible to
> invalidate the HttpSession at this point (you cannot clear the JSESSIONID
> cookie).
> {code}
> 17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
> handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
> Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
> after the response was committed (e.g. after HttpServletResponse.sendRedirect
> or sendError)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
> at
> org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
> at
> deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at
> io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at
> org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at
> io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.
[jira] [Created] (WICKET-6848) Session invalidation fails because response is already committed
Emond Papegaaij created WICKET-6848:
---
Summary: Session invalidation fails because response is already
committed
Key: WICKET-6848
URL: https://issues.apache.org/jira/browse/WICKET-6848
Project: Wicket
Issue Type: Bug
Components: wicket-core
Affects Versions: 9.1.0
Reporter: Emond Papegaaij
Since Wicket 9.1.0, we are seeing the stacktrace below. It is very likely
related to the changes made with WICKET-6831. We are currently checking if this
has been fixed by the latest changes on master, but I believe this is a
different issue.
>From the stacktrace I deduce that the session is invalidated as part of
>detach, but as detach is now called after flush, it is no longer possible to
>invalidate the HttpSession at this point (you cannot clear the JSESSIONID
>cookie).
{code}
17:22:11,823 ERROR [io.undertow.request] (default task-9) UT005023: Exception
handling request to /idp/: java.lang.IllegalStateException: WFLYCLWEBUT0009:
Invalidation attempted for session JtkqV0MvzZq-RzFBSs-K6n2CcJN72IDooNHsTBm8
after the response was committed (e.g. after HttpServletResponse.sendRedirect
or sendError)
at
org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.validateBatch(DistributableSession.java:292)
at
org.wildfly.clustering.web.undertow@20.0.1.Final//org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:225)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.session.HttpSessionStore.invalidate(HttpSessionStore.java:165)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.destroy(Session.java:508)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.invalidateNow(Session.java:529)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.Session.detach(Session.java:684)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:674)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:614)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:284)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:207)
at
deployment.parnassys-portal-authenticator.war//org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:306)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
deployment.parnassys-portal-authenticator.war//nl.topicus.cobra.filter.ClickjackFilter.doFilter(ClickjackFilter.java:29)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow@20.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet@2.1.3.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.core@2.1.3.Final//io.undertow.server.handlers.PredicateHandler.h
[jira] [Commented] (WICKET-6832) CSP support in Java 8
[ https://issues.apache.org/jira/browse/WICKET-6832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17216697#comment-17216697 ] Emond Papegaaij commented on WICKET-6832: - I totally agree with Martin, Sven and Andrea here. The fact that JDK 8 still has support (read gets bug and security fixes), does not mean that a framework like Wicket needs to put effort in supporting new features on this old JDK. Wicket 8 probably will be supported (read gets bug and security fixes) for several years to come. For new features, you will have to upgrade your entire stack not just Wicket. The Wicket team has limited resources and we cannot afford to spend it on supporting many different platforms. There is nothing stopping you from forking the Wicket source code and either backport the features you need from Wicket 9 to Wicket 8 or downgrade the Java version in Wicket 9 though. > CSP support in Java 8 > - > > Key: WICKET-6832 > URL: https://issues.apache.org/jira/browse/WICKET-6832 > Project: Wicket > Issue Type: New Feature > Components: wicket >Affects Versions: 9.0.0, 8.9.0 >Reporter: Ashley Reed >Priority: Major > > Wicket needs Content-Security-Policy support in Java 8 as it is it the most > popular version of Java used in production. Wicket 9 has CSP support, but > requires Java 11. Wicket 8 runs on Java 8, but has no CSP support. Need to > either add Java 8 support to Wicket 9 or add CSP support to Wicket 8. > > Evidence that Java 8 is still very popular: > [https://blog.newrelic.com/technology/state-of-java/] > [https://www.jrebel.com/blog/2020-java-technology-report] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (WICKET-6702) AsynchronousPageStore with NotDetachedModelChecker - "Not detached model found" exception on several fast sequential Ajax calls
[ https://issues.apache.org/jira/browse/WICKET-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij resolved WICKET-6702. - Resolution: Fixed > AsynchronousPageStore with NotDetachedModelChecker - "Not detached model > found" exception on several fast sequential Ajax calls > --- > > Key: WICKET-6702 > URL: https://issues.apache.org/jira/browse/WICKET-6702 > Project: Wicket > Issue Type: Bug > Components: wicket-core >Affects Versions: 8.5.0, 9.0.0 >Reporter: Sergei Tkachuk >Priority: Major > Fix For: 9.1.0, 8.10.0 > > Attachments: QuickStart.zip > > > Preconditions: Application uses AsynchronousPageStore (as it is by default). > When there are several fast sequential Ajax calls to a component, then a > component's LoadableDetachableModel gets attached and detached several times > before real async serialization takes place. And at times the serialization > is initiated when the model has been already attached once again by a > subsequent Ajax call, and not detached yet as the request is still in > progress. This causes NotDetachedModelChecker() to throw "Not detached model > found!" exception > Disabling async serialization fixes the problem. > A test-case and a log attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (WICKET-6831) Try to flush the response before detach
[ https://issues.apache.org/jira/browse/WICKET-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emond Papegaaij resolved WICKET-6831. - Fix Version/s: 8.10.0 9.1.0 Assignee: Emond Papegaaij Resolution: Fixed > Try to flush the response before detach > --- > > Key: WICKET-6831 > URL: https://issues.apache.org/jira/browse/WICKET-6831 > Project: Wicket > Issue Type: Improvement > Components: wicket-core >Affects Versions: 9.0.0 > Reporter: Emond Papegaaij >Assignee: Emond Papegaaij >Priority: Major > Fix For: 9.1.0, 8.10.0 > > > The current behavior makes the browser wait for cleanup on the server-end. > The request is only flushed after detach and serialization of the pages. As > the processing of the request has already completed, it is not needed to let > the browser wait for the server to be cleaning up. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[wicket] branch master updated: Rebuild
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/wicket.git The following commit(s) were added to refs/heads/master by this push: new 82f911c Rebuild 82f911c is described below commit 82f911cd9fd6bbed050ac041d168654fac8d43b3 Author: Emond Papegaaij AuthorDate: Thu Oct 1 17:15:27 2020 +0200 Rebuild
[wicket] branch wicket-8.x updated: Rebuild
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a commit to branch wicket-8.x in repository https://gitbox.apache.org/repos/asf/wicket.git The following commit(s) were added to refs/heads/wicket-8.x by this push: new ca3dd51 Rebuild ca3dd51 is described below commit ca3dd5184f8ce8838ba61977d48326aac3c9a5db Author: Emond Papegaaij AuthorDate: Thu Oct 1 17:13:19 2020 +0200 Rebuild
[wicket] branch wicket-8.x updated (7cd6e18 -> bed559f)
This is an automated email from the ASF dual-hosted git repository. papegaaij pushed a change to branch wicket-8.x in repository https://gitbox.apache.org/repos/asf/wicket.git. from 7cd6e18 WICKET-6824 Replace slow `String.format` with concatenation add 14e8521 WICKET-6831: flush the request before detaching to allow the browser to move on add e5cd09b WICKET-6831: flush before detach in websocket, log detach exceptions add bed559f WICKET-6831 remove duplicate code No new revisions were added by this update. Summary of changes: .../apache/wicket/protocol/http/WicketFilter.java | 22 + .../apache/wicket/request/cycle/RequestCycle.java | 17 +--- .../wicket/protocol/ws/AbstractUpgradeFilter.java | 23 +++--- 3 files changed, 18 insertions(+), 44 deletions(-)
