[jira] [Commented] (WICKET-6438) 8.x reference guide needs a few minor improvements
[ https://issues.apache.org/jira/browse/WICKET-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16125255#comment-16125255 ] ASF GitHub Bot commented on WICKET-6438: Github user klopfdreh commented on the issue: https://github.com/apache/wicket/pull/229 The changes of the PR are integrated with commit 075d8371ef3eb2e5f3bdadf008ae904cafd222b3 > 8.x reference guide needs a few minor improvements > -- > > Key: WICKET-6438 > URL: https://issues.apache.org/jira/browse/WICKET-6438 > Project: Wicket > Issue Type: Improvement > Components: guide >Affects Versions: 8.0.0 >Reporter: Ahmet Yaşar Özer >Assignee: Andrea Del Bene >Priority: Minor > Labels: documentation > > Minor fix in helloWorld.adoc: Removed irrelevant line to avoid warning during > maven packaging phase: > WARNING: image to embed not found or not readable: > F:/wicket/wicket-user-guide/src/main/asciidoc/images/uml-component.svg > Minor fix in contributing.adoc: Revised the generated document target > directory for the user guide documentation. > Cropped top and bottom blank parts in comsysto-logo.png to have the > Introduction page fit in one page in PDF. Made minor changes in > helloWorld_2.adoc, helloWorld_3.adoc and introduction.adoc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6441) MockHttpSession doesn't call onInvalidate() on invalidate()
[
https://issues.apache.org/jira/browse/WICKET-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124918#comment-16124918
]
Kamil commented on WICKET-6441:
---
[~mgrigorov] - but you can (or actually can't) see it in source code - it's
just not being called at all
> MockHttpSession doesn't call onInvalidate() on invalidate()
> ---
>
> Key: WICKET-6441
> URL: https://issues.apache.org/jira/browse/WICKET-6441
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M6
>Reporter: Kamil
>
> org.apache.wicket.protocol.http.mock.MockHttpSession on invalidate calls just:
> {code}
> @Override
> public void invalidate()
> {
> attributes.clear();
> id = generateSessionId();
> }
> {code}
> while org.apache.wicket.session.HttpSessionStore valueUnbound calls
> {code}
> public void valueUnbound(final HttpSessionBindingEvent evt)
> {
> String sessionId = evt.getSession().getId();
> log.debug("Session unbound: {}", sessionId);
> if (wicketSession != null)
> {
> wicketSession.onInvalidate();
> }
> ...
> }
> {code}
> (valueUnbound is called on
> org.apache.catalina.session.StandardSession.invalidate)
> this causes to be impossible to properly test what happens on invalidation of
> the session.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (WICKET-6441) MockHttpSession doesn't call onInvalidate() on invalidate()
[
https://issues.apache.org/jira/browse/WICKET-6441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6441.
-
Resolution: Cannot Reproduce
Please provide a quickstart application and we will reopen this ticket.
> MockHttpSession doesn't call onInvalidate() on invalidate()
> ---
>
> Key: WICKET-6441
> URL: https://issues.apache.org/jira/browse/WICKET-6441
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 8.0.0-M6
>Reporter: Kamil
>
> org.apache.wicket.protocol.http.mock.MockHttpSession on invalidate calls just:
> {code}
> @Override
> public void invalidate()
> {
> attributes.clear();
> id = generateSessionId();
> }
> {code}
> while org.apache.wicket.session.HttpSessionStore valueUnbound calls
> {code}
> public void valueUnbound(final HttpSessionBindingEvent evt)
> {
> String sessionId = evt.getSession().getId();
> log.debug("Session unbound: {}", sessionId);
> if (wicketSession != null)
> {
> wicketSession.onInvalidate();
> }
> ...
> }
> {code}
> (valueUnbound is called on
> org.apache.catalina.session.StandardSession.invalidate)
> this causes to be impossible to properly test what happens on invalidation of
> the session.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
[
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124887#comment-16124887
]
Hendy Irawan commented on WICKET-6440:
--
Not really, but I've confirmed in my own app that making the changes I
described does result in expected behavior.
This bug is most likely a couple of unintentional typos.
> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>Priority: Minor
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3]
> ecuredRemoteAddressRequestWrapperFactory : Incoming request
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
> with originalSecure='false', remoteAddr='127.0.0.1' will be seen with
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy:
> (i.e. need to remove {{==false}})
> {code:java}
> @Override
> public boolean needsWrapper(final HttpServletRequest request)
> {
> return !request.isSecure() &&
> matchesOne(request.getRemoteAddr(),
> config.securedRemoteAddresses) == false;
> }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
> HttpServletRequest xRequest = super.getWrapper(request);
> if (log.isDebugEnabled())
> {
> log.debug("Incoming request uri=" +
> request.getRequestURI() + " with originalSecure='" +
> request.isSecure() + "', remoteAddr='" +
> request.getRemoteAddr() +
> "' will be seen with newSecure='" +
> request.isSecure() + "'");
> }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
[
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov updated WICKET-6440:
Priority: Minor (was: Major)
> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>Priority: Minor
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3]
> ecuredRemoteAddressRequestWrapperFactory : Incoming request
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
> with originalSecure='false', remoteAddr='127.0.0.1' will be seen with
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy:
> (i.e. need to remove {{==false}})
> {code:java}
> @Override
> public boolean needsWrapper(final HttpServletRequest request)
> {
> return !request.isSecure() &&
> matchesOne(request.getRemoteAddr(),
> config.securedRemoteAddresses) == false;
> }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
> HttpServletRequest xRequest = super.getWrapper(request);
> if (log.isDebugEnabled())
> {
> log.debug("Incoming request uri=" +
> request.getRequestURI() + " with originalSecure='" +
> request.isSecure() + "', remoteAddr='" +
> request.getRemoteAddr() +
> "' will be seen with newSecure='" +
> request.isSecure() + "'");
> }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6440) SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
[
https://issues.apache.org/jira/browse/WICKET-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124885#comment-16124885
]
Martin Grigorov commented on WICKET-6440:
-
Any chance for a quickstart app ?
> SecuredRemoteAddressRequestWrapperFactory doesn't make request secure
> -
>
> Key: WICKET-6440
> URL: https://issues.apache.org/jira/browse/WICKET-6440
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 7.8.0
>Reporter: Hendy Irawan
>
> I'm using SecuredRemoteAddressRequestWrapperFactory and what I get is:
> {noformat}
> 2017-08-08 09:07:53.460 DEBUG 3851 --- [nio-8080-exec-3]
> ecuredRemoteAddressRequestWrapperFactory : Incoming request
> uri=/id/cari-wanita/di/Kota%20Malang,%20Jawa%20Timur,%20Republic%20of%20Indonesia
> with originalSecure='false', remoteAddr='127.0.0.1' will be seen with
> newSecure='false'
> {noformat}
> Since remoteAddr is 127.* then it should be treated as secure, per
> documentation.
> This code in SecuredRemoteAddressRequestWrapperFactory is probably buggy:
> (i.e. need to remove {{==false}})
> {code:java}
> @Override
> public boolean needsWrapper(final HttpServletRequest request)
> {
> return !request.isSecure() &&
> matchesOne(request.getRemoteAddr(),
> config.securedRemoteAddresses) == false;
> }
> {code}
> Additionally, newSecure = should be {{xRequest.isSecure()}} :
> {code:java}
> HttpServletRequest xRequest = super.getWrapper(request);
> if (log.isDebugEnabled())
> {
> log.debug("Incoming request uri=" +
> request.getRequestURI() + " with originalSecure='" +
> request.isSecure() + "', remoteAddr='" +
> request.getRemoteAddr() +
> "' will be seen with newSecure='" +
> request.isSecure() + "'");
> }
> {code}
> Related to WICKET-3015.
> Tag [~jdonnerstag] [~pete]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (WICKET-6442) WicketTester#clickLink is not handling buttons
[
https://issues.apache.org/jira/browse/WICKET-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124884#comment-16124884
]
Martin Grigorov edited comment on WICKET-6442 at 8/13/17 11:20 AM:
---
The method name is "clickLink", so it should not deal with *Button*s.
was (Author: mgrigorov):
The method name is "clickLink", so it should not deal with *Button*s.
> WicketTester#clickLink is not handling buttons
> --
>
> Key: WICKET-6442
> URL: https://issues.apache.org/jira/browse/WICKET-6442
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Reporter: Kamil
>
> WicketTester#clickLink javadoc says:
> {code}
> When clicking an AjaxSubmitLink the form, which the AjaxSubmitLink is
> attached to is first submitted, and then the onSubmit method on
> AjaxSubmitLink is invoked. If you have changed some values in the form during
> your test, these will also be submitted. This should not be used as a
> replacement for the {@link FormTester} to test your forms. It should be used
> to test that the code in your onSubmit method in AjaxSubmitLink actually
> works.
> {code}
> And this is exactly what I want to do - just test the code in my "onSubmit"
> method.
> One difference is that I'm using IndicatingAjaxButton instead of
> AjaxSubmitLink, which causes the exception being thrown:
> {code}
> java.lang.AssertionError: Link test:saveButton is not an instance of
> AbstractLink or IAjaxLink
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.wicket.util.tester.BaseWicketTester.clickLink(BaseWicketTester.java:2031)
> at
> org.apache.wicket.util.tester.BaseWicketTester.clickLink(BaseWicketTester.java:1864)
> {code}
> I already checked that exactly the same mechanism, that clickLink is using
> works fine for the buttons:
> {code}
> Component button =
> wicketTester.getComponentFromLastRenderedPage("saveButton");
>
> wicketTester.executeBehavior(WicketTesterHelper.findAjaxEventBehavior(button,
> "click"));
> {code}
> so changing this method to work with button should be easy
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (WICKET-6442) WicketTester#clickLink is not handling buttons
[
https://issues.apache.org/jira/browse/WICKET-6442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-6442.
-
Resolution: Won't Fix
The method name is "clickLink", so it should not deal with *Button*s.
> WicketTester#clickLink is not handling buttons
> --
>
> Key: WICKET-6442
> URL: https://issues.apache.org/jira/browse/WICKET-6442
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Reporter: Kamil
>
> WicketTester#clickLink javadoc says:
> {code}
> When clicking an AjaxSubmitLink the form, which the AjaxSubmitLink is
> attached to is first submitted, and then the onSubmit method on
> AjaxSubmitLink is invoked. If you have changed some values in the form during
> your test, these will also be submitted. This should not be used as a
> replacement for the {@link FormTester} to test your forms. It should be used
> to test that the code in your onSubmit method in AjaxSubmitLink actually
> works.
> {code}
> And this is exactly what I want to do - just test the code in my "onSubmit"
> method.
> One difference is that I'm using IndicatingAjaxButton instead of
> AjaxSubmitLink, which causes the exception being thrown:
> {code}
> java.lang.AssertionError: Link test:saveButton is not an instance of
> AbstractLink or IAjaxLink
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.wicket.util.tester.BaseWicketTester.clickLink(BaseWicketTester.java:2031)
> at
> org.apache.wicket.util.tester.BaseWicketTester.clickLink(BaseWicketTester.java:1864)
> {code}
> I already checked that exactly the same mechanism, that clickLink is using
> works fine for the buttons:
> {code}
> Component button =
> wicketTester.getComponentFromLastRenderedPage("saveButton");
>
> wicketTester.executeBehavior(WicketTesterHelper.findAjaxEventBehavior(button,
> "click"));
> {code}
> so changing this method to work with button should be easy
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WICKET-6177) Introduce AsynchronousPageStore
[ https://issues.apache.org/jira/browse/WICKET-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124882#comment-16124882 ] Martin Grigorov commented on WICKET-6177: - Hi [~wschlich], Please create a new ticket for 7.x. We are going to release 8.0.0 soon so 6.x branch will be moved in maintenance mode, i.e. it will receive only security related fixes. > Introduce AsynchronousPageStore > --- > > Key: WICKET-6177 > URL: https://issues.apache.org/jira/browse/WICKET-6177 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 7.4.0 > Environment: any >Reporter: Martin Makundi >Assignee: Martin Grigorov > Labels: serialization > Fix For: 8.0.0-M6 > > Attachments: 6177.tgz, Wicket_Quickstart_7.zip > > Original Estimate: 168h > Remaining Estimate: 168h > > We have a performance issue with our Wicket app, page serialization causes > inconvenience to user because PageStoreManager.storeTouchedPages() blocks the > request until pageSerializer.serialize(page) has been handled. > Could this be solved by serializing the page in a separate thread and let the > request complete? > The problem we have is that user is making quick small ajax modifications to > the page but serialization + network latency makes the delay very > inconvenient. If serialization could be done in separate thread, user would > feel only the network delay which is bearable. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WICKET-6432) SignInPanel causes infinite redirect loop if session id is suppressed in URL
[
https://issues.apache.org/jira/browse/WICKET-6432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124879#comment-16124879
]
Martin Grigorov commented on WICKET-6432:
-
bq. I'll have to verify, but it seems Jetty is using two different sessions for
Http and HTTPS respectively.
Yes, this is expected!
If the first session is created in HTTPS request then this session cannot be
shared with HTTP requests and a new http session is created for them.
> SignInPanel causes infinite redirect loop if session id is suppressed in URL
>
>
> Key: WICKET-6432
> URL: https://issues.apache.org/jira/browse/WICKET-6432
> Project: Wicket
> Issue Type: Bug
> Components: wicket-auth-roles
>Affects Versions: 7.8.0
>Reporter: Simon Erhardt
>Assignee: Martin Grigorov
> Attachments: redirect-loop.zip
>
>
> The attached, very simple quickstart causes an infinite redirection loop. It
> consists of a _AuthenticatedPage_, which is annotated by
> _@AuthorizeInstantiation_, and a _LoginPage_, using a SingInPanel, which is
> set up as home page.
> The trouble begins if one opens the HTTP URL after signing in with HTTPS.
> It happens only if Jetty is forced to suppress the session id as URL
> parameter (see [Jetty 9.2.X
> documentation|http://www.eclipse.org/jetty/documentation/9.2.22.v20170531/session-management.html#setting-session-characteristics]):
> {code}
> WebAppContext bb = new WebAppContext();
> // The following line causes the trouble
>
> bb.setInitParameter("org.eclipse.jetty.servlet.SessionIdPathParameterName",
> "none");
> {code}
> Steps to reproduce:
> # Start the application in test/java/quickstart/Start
> # Open https://localhost:8443
> # Sign in using "user" and "password"
> # After redirected to the AuthenticatedPage, open http://localhost:8080
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
