Re: Password in url after page recreation
Hi Claudia, I have never seen this in our applications - we always use a form POST to submit user login details. The only reason I can think of that would lead to your case is when you set the form to submit using a GET request. That would put the fields in the URL and thus in wicket’s page parameters, which are reused when recreateBookmarkablePagesAfterExpiry is true and the page expired. Did you by any chance specify a method=“GET” attribute on your form? Met vriendelijke groet, Kind regards, Bas Gooren Op 20 juli 2021 bij 21:46:07, Claudia Hirt (claudiabec...@gmx.de) schreef: > Hi all, > > we currenlty facing some issues with the recreateBookmarkablePagesAfterExpiry option. > We set this option to true, the user visits the login page and enters username and password (""). Now the user waits for the login till the session expires. Wicket forces a page recreate and append the password into the url (e.G. http://localhost:8080/app?user:unit:textfield=user&password:password="password";). > This seems to be an security issue on our side. Unfortunately we can't disable the recreateBookmarkablePagesAfterExpiry option due some resource loading issues. > > We already thougth about what we can do to solve this issue, and it seems to be possible to remove this parameter form the page parameters (which are called for the rewrite url after an page expires). > But before we implement this workaround we want to ask you guys if you already have seen this issue and if yes, if you have any better solutions? > > Thanks for your help...
Password in url after page recreation
> Hi all, > > we currenlty facing some issues with the recreateBookmarkablePagesAfterExpiry > option. > We set this option to true, the user visits the login page and enters > username and password (""). Now the user waits > for the login till the session expires. Wicket forces a page recreate and > append the password into the url (e.G. > http://localhost:8080/app?user:unit:textfield=user&password:password="password";). > This seems to be an security issue on our side. Unfortunately we can't > disable the recreateBookmarkablePagesAfterExpiry option due some resource > loading issues. > > We already thougth about what we can do to solve this issue, and it seems to > be possible to remove this parameter form the page parameters (which are > called for the rewrite url after an page expires). > But before we implement this workaround we want to ask you guys if you > already have seen this issue and if yes, if you have any better solutions? > > Thanks for your help...
RE: [EXTERNAL] Re: URL changes from AJAX request
I will look at this, as it might have some ideas or direction to go. To further explain, it is more than just parameters, and parts of the url change for SEO. For example... https://xxx.xxx.xxx/parts/atv-parts would have changed to https://xxx.xxx.xxx/parts/street-parts based on a combobox drop down. They stay on the page, but the content is changed and the history is left as is. When the first AJAX event comes through causing the url to change, and components on the page are refreshed through the AjaxRequestTarget. When the next combobox AJAX event happens, the request has the original URL in the httpRequest because the components on the page, even though they were refreshed, they still have the wrong action url. They need to be able to be refreshed with the new url. -Original Message- From: Bergmann Manfred Sent: Saturday, May 15, 2021 2:10 AM To: users@wicket.apache.org Subject: [EXTERNAL] Re: URL changes from AJAX request WARNING: This email originated from outside the organization. Do not click links, open attachments, or enter user credentials, unless you recognize the sender and know the content is safe. Hi. We have been using wicketstuff urlfragment for something similar. https://github.com/wicketstuff/core/tree/master/urlfragment-parent I can’t remember exactly how this urlfragment worked, I believe it’s also doing some JavaScript magic. But I think it’s not using history API. Manfred > Am 14.05.2021 um 23:00 schrieb Michael Pritt > : > > I've been searching for help with this issue on the web concerning URL > modifications that we need to do from doing an AJAX request (for example > adding a sort parameter when a sort option is selected but stay on the page). > We don't want to do a redirect and have the redirect added to the history > (i.e. back button), and we are refreshing only the necessary components on > the page (see related link: > https://stackoverflow.com/questions/6576354/changing-url-via-ajax-using-wicket). > > However a couple of the components need to be refreshed with the slightly > updated url. For example the Form component on the page, the action URL > needs to be updated so when requests come from combo boxes during the > onChange() event will have the right request URL. > > What is the best way to make this work. Here is what we are doing now and > what is happening: > > > 1. Combo Box drop down causes an AJAX event (i.e. sort selection), during > the event javascript is generated to update the browser URL using the > AjaxRequestTarget. appendJavaScript(). (The javascript updates the url using > the history API). Other components are refreshed on page as needed. > 2. Another combo box on the page then is then selected causing another AJAX > event, and in this case the wrong request URL is given (it is the old > original one). Looking at the page source the action url for the form has > the old url. > > Thoughts on how to make this work? Can we do a complete page > refresh/redirect to not affect history or somehow let Wicket know during the > AJAX event that the URL will be changed and this is the one to use to refresh > the components with (especially the form action url)? > > Thanks in advance, > > Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: URL changes from AJAX request
Hi. We have been using wicketstuff urlfragment for something similar. https://github.com/wicketstuff/core/tree/master/urlfragment-parent I can’t remember exactly how this urlfragment worked, I believe it’s also doing some JavaScript magic. But I think it’s not using history API. Manfred > Am 14.05.2021 um 23:00 schrieb Michael Pritt > : > > I've been searching for help with this issue on the web concerning URL > modifications that we need to do from doing an AJAX request (for example > adding a sort parameter when a sort option is selected but stay on the page). > We don't want to do a redirect and have the redirect added to the history > (i.e. back button), and we are refreshing only the necessary components on > the page (see related link: > https://stackoverflow.com/questions/6576354/changing-url-via-ajax-using-wicket). > > However a couple of the components need to be refreshed with the slightly > updated url. For example the Form component on the page, the action URL > needs to be updated so when requests come from combo boxes during the > onChange() event will have the right request URL. > > What is the best way to make this work. Here is what we are doing now and > what is happening: > > > 1. Combo Box drop down causes an AJAX event (i.e. sort selection), during > the event javascript is generated to update the browser URL using the > AjaxRequestTarget. appendJavaScript(). (The javascript updates the url using > the history API). Other components are refreshed on page as needed. > 2. Another combo box on the page then is then selected causing another AJAX > event, and in this case the wrong request URL is given (it is the old > original one). Looking at the page source the action url for the form has > the old url. > > Thoughts on how to make this work? Can we do a complete page > refresh/redirect to not affect history or somehow let Wicket know during the > AJAX event that the URL will be changed and this is the one to use to refresh > the components with (especially the form action url)? > > Thanks in advance, > > Mike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
URL changes from AJAX request
I've been searching for help with this issue on the web concerning URL modifications that we need to do from doing an AJAX request (for example adding a sort parameter when a sort option is selected but stay on the page). We don't want to do a redirect and have the redirect added to the history (i.e. back button), and we are refreshing only the necessary components on the page (see related link: https://stackoverflow.com/questions/6576354/changing-url-via-ajax-using-wicket). However a couple of the components need to be refreshed with the slightly updated url. For example the Form component on the page, the action URL needs to be updated so when requests come from combo boxes during the onChange() event will have the right request URL. What is the best way to make this work. Here is what we are doing now and what is happening: 1. Combo Box drop down causes an AJAX event (i.e. sort selection), during the event javascript is generated to update the browser URL using the AjaxRequestTarget. appendJavaScript(). (The javascript updates the url using the history API). Other components are refreshed on page as needed. 2. Another combo box on the page then is then selected causing another AJAX event, and in this case the wrong request URL is given (it is the old original one). Looking at the page source the action url for the form has the old url. Thoughts on how to make this work? Can we do a complete page refresh/redirect to not affect history or somehow let Wicket know during the AJAX event that the URL will be changed and this is the one to use to refresh the components with (especially the form action url)? Thanks in advance, Mike
Re: How to parse URL-strings based on some template for contained parameters?
Hi, \ > I'm using Wicket as some template engine to generate reports about > tabular data as HTML-documents in a backend published using SOAP. The > called SOAP-interfaces expect what to generate pretty much as some > path/URL-like resource description: > > > alert/topic1/foo/bar > > report/topic1/foo/bar > > report/topic2/bar/foo > > I would like to have some parser for those kinds of paths/URLs, so > that I'm able to provide some template-paths and get some results by > name. > > > ${type}/${topic}/foo/${fooVal} > > You can count a resource using exactly like that https://ci.apache.org/projects/wicket/guide/6.x/guide/resources.html#resources_11 https://wicketinaction.com/2011/07/wicket-1-5-mounting-resources/ > Is something like that available in Wicket already? > > Looking at "PageParameters", Wicket does only support query strings > and indexed parameters, so no support for templates like the above. > Indexed parameters don't seem too different, though. Additionally, > "PagerParameters" doesn't seem to support parsing itself. > > So how can I parse a string only and get "PageParameters"? > > I've found "UrlRequestParametersAdapter" and > "UrlPathPageParametersEncoder", the latter supports decoding paths > like "/key1/value/key2/value" etc. And both don't seem to be bound to > an application or HTTP, which would exactly be what I need. > > Anything else to look at? Thanks! > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Regards - Ernesto Reinaldo Barreiro
How to parse URL-strings based on some template for contained parameters?
Hi all, I'm using Wicket as some template engine to generate reports about tabular data as HTML-documents in a backend published using SOAP. The called SOAP-interfaces expect what to generate pretty much as some path/URL-like resource description: > alert/topic1/foo/bar > report/topic1/foo/bar > report/topic2/bar/foo I would like to have some parser for those kinds of paths/URLs, so that I'm able to provide some template-paths and get some results by name. > ${type}/${topic}/foo/${fooVal} Is something like that available in Wicket already? Looking at "PageParameters", Wicket does only support query strings and indexed parameters, so no support for templates like the above. Indexed parameters don't seem too different, though. Additionally, "PagerParameters" doesn't seem to support parsing itself. So how can I parse a string only and get "PageParameters"? I've found "UrlRequestParametersAdapter" and "UrlPathPageParametersEncoder", the latter supports decoding paths like "/key1/value/key2/value" etc. And both don't seem to be bound to an application or HTTP, which would exactly be what I need. Anything else to look at? Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi, On Fri, Apr 24, 2020, 22:13 Igor Khvostenkov wrote: > Problem is not in the application but in the configuration put proxy which > does the redirect in front of the any application with form submit. IMHO > this change https://issues.apache.org/jira/browse/WICKET-6708 does not > keep in mind that it could be redirect call with GET request with POST > parameters. > This change is fixing a security related issue. In my opinion your proxy config is wrong. I don't understand "redirect call with GET request with POST parameters". Redirects are always GET. And their parameters are in the query string. What does your proxy do with multipart POSTs? What does it do with single part body that is too long to be in the query string? Does it truncate it? > -Igor. > > On 24. Apr 2020, at 20:57, Martin Grigorov mgrigo...@apache.org>> wrote: > > Please create a demo application so we can take a look! > > On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov > igor.khvosten...@lindenbaum.eu.invalid>> wrote: > > Sven, > > Same stuff with crypto off. Here is with debugger on getParameterValues: > > > > -Igor. > > On 24. Apr 2020, at 18:51, Sven Meier s...@meiers.net>> wrote: > > Hi, > > Request URL: > > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > Request Method: > GET > > that is a GET request with query parameters. > > Form inputs should be able to pick up the values from the query parameters. > > Maybe the problem is related to the cryptoMapper? Could you disable it for > a test? > > Have fun > Sven > > > On 24.04.20 17:43, Igor Khvostenkov wrote: > > Hi Sven, > > Yes exactly, but in fact this is POST. This is GET with POST parameters. > And then FormComponent#getParameterValues(String inputName) > > case Form.METHOD_GET: > parameters = request.getQueryParameters(); > break; > > Instead of > > case Form.METHOD_POST: > parameters = request.getPostParameters(); > break; > > And I lost my POST parameters. Nothing works after. > > -Igor. > > > On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net mailto:s...@meiers.net>>>> wrote: > > Hi Igor, > > so the browser sends the request a second time via "get". > > That shouldn't be a problem, since in that case all FormComponents will > read their parameters from the query parameters. > > So what is your actual problem? > > Have fun > Sven > > > On 24.04.20 11:34, Igor Khvostenkov wrote: > Hi Martin, > > Thanks for the hint with "Preserve log”. Looks like still this is exactly > what I described in reply to Sven. Browser does really POST request: > > > * > Request URL: > > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > POST > * > Status Code: > 302 > * > Remote Address: > xxx:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./DHB1U_x9J1dRXqDe8wegYw/DHB6d > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > And then it gets redirect from proxy-server. And next request Browser > substitutes POST to GET, as stated in RFC: > > > * > Request URL: > > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > GET > * > Status Code: > 302 > * > Remote Address: > 10.1.37.99:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./login.html?wicket-crypt=0SaMcpSjW2Y > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > Am I missing something? > &g
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Problem is not in the application but in the configuration put proxy which does the redirect in front of the any application with form submit. IMHO this change https://issues.apache.org/jira/browse/WICKET-6708 does not keep in mind that it could be redirect call with GET request with POST parameters. -Igor. On 24. Apr 2020, at 20:57, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: Please create a demo application so we can take a look! On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Sven, Same stuff with crypto off. Here is with debugger on getParameterValues: -Igor. On 24. Apr 2020, at 18:51, Sven Meier mailto:s...@meiers.net>> wrote: Hi, Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw Request Method: GET that is a GET request with query parameters. Form inputs should be able to pick up the values from the query parameters. Maybe the problem is related to the cryptoMapper? Could you disable it for a test? Have fun Sven On 24.04.20 17:43, Igor Khvostenkov wrote: Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net mailto:s...@meiers.net>>>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov wrote: Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid>>mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Please create a demo application so we can take a look! On Fri, Apr 24, 2020 at 9:31 PM Igor Khvostenkov wrote: > Sven, > > Same stuff with crypto off. Here is with debugger on getParameterValues: > > > > -Igor. > > On 24. Apr 2020, at 18:51, Sven Meier wrote: > > Hi, > > >Request URL: > > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > >Request Method: > >GET > > that is a GET request with query parameters. > > Form inputs should be able to pick up the values from the query parameters. > > Maybe the problem is related to the cryptoMapper? Could you disable it for > a test? > > Have fun > Sven > > > On 24.04.20 17:43, Igor Khvostenkov wrote: > > Hi Sven, > > Yes exactly, but in fact this is POST. This is GET with POST parameters. > And then FormComponent#getParameterValues(String inputName) > > case Form.METHOD_GET: > parameters = request.getQueryParameters(); > break; > > Instead of > > case Form.METHOD_POST: > parameters = request.getPostParameters(); > break; > > And I lost my POST parameters. Nothing works after. > > -Igor. > > > On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net >> wrote: > > Hi Igor, > > so the browser sends the request a second time via "get". > > That shouldn't be a problem, since in that case all FormComponents will > read their parameters from the query parameters. > > So what is your actual problem? > > Have fun > Sven > > > On 24.04.20 11:34, Igor Khvostenkov wrote: > Hi Martin, > > Thanks for the hint with "Preserve log”. Looks like still this is exactly > what I described in reply to Sven. Browser does really POST request: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > POST > * > Status Code: > 302 > * > Remote Address: > xxx:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./DHB1U_x9J1dRXqDe8wegYw/DHB6d > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > And then it gets redirect from proxy-server. And next request Browser > substitutes POST to GET, as stated in RFC: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > GET > * > Status Code: > 302 > * > Remote Address: > 10.1.37.99:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./login.html?wicket-crypt=0SaMcpSjW2Y > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > Am I missing something? > > -Igor. > > On 24. Apr 2020, at 09:41, Martin Grigorov mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: > > On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov > igor.khvosten...@lindenbaum.eu.invalid> igor.khvosten...@lindenbaum.eu.invalid>> wrote: > > Hi Martin, > > Yes, this is login form with special “token". > > If this is PRG should I see POST request in Browser console? I see only > GET. Exactly one I’ve posted. Meaning that Browser does the substitution. > > > Yes, you should see POST with status 302 and then GET. > But to see them both you need to check "Preserve log" in the Network tab. > Otherwise the browser shows only the requests for the last load of the page > (including the request for the page itself and all resources like > css/js/images) > > > > -Igor. > > On 24. Apr 2020, at 06:02, Martin Grigorov mgrigo...@apache.org><mailto:m
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Sven, Same stuff with crypto off. Here is with debugger on getParameterValues: [cid:D2B48B44-E9C2-4E26-A9B4-C807FE5E8E00@lbaum.eu] -Igor. On 24. Apr 2020, at 18:51, Sven Meier mailto:s...@meiers.net>> wrote: Hi, >Request URL: >https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw >Request Method: >GET that is a GET request with query parameters. Form inputs should be able to pick up the values from the query parameters. Maybe the problem is related to the cryptoMapper? Could you disable it for a test? Have fun Sven On 24.04.20 17:43, Igor Khvostenkov wrote: Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov wrote: Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>mailto:s...@meiers.net><mailto:s...@meiers.net>>mailto:s...@meiers.net><
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi, >Request URL: >https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw >Request Method: >GET that is a GET request with query parameters. Form inputs should be able to pick up the values from the query parameters. Maybe the problem is related to the cryptoMapper? Could you disable it for a test? Have fun Sven On 24.04.20 17:43, Igor Khvostenkov wrote: Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov wrote: Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>mailto:s...@meiers.net><mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Sven, Yes exactly, but in fact this is POST. This is GET with POST parameters. And then FormComponent#getParameterValues(String inputName) case Form.METHOD_GET: parameters = request.getQueryParameters(); break; Instead of case Form.METHOD_POST: parameters = request.getPostParameters(); break; And I lost my POST parameters. Nothing works after. -Igor. On 24. Apr 2020, at 15:07, Sven Meier mailto:s...@meiers.net>> wrote: Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov wrote: Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org><mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid><mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>mailto:s...@meiers.net><mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< https://tools.ietf.org/html/rfc2068> speci
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Igor, so the browser sends the request a second time via "get". That shouldn't be a problem, since in that case all FormComponents will read their parameters from the query parameters. So what is your actual problem? Have fun Sven On 24.04.20 11:34, Igor Khvostenkov wrote: Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net>mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.co
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
On Fri, Apr 24, 2020 at 12:34 PM Igor Khvostenkov wrote: > Hi Martin, > > Thanks for the hint with "Preserve log”. Looks like still this is exactly > what I described in reply to Sven. Browser does really POST request: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > POST > * > Status Code: > 302 > * > Remote Address: > xxx:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./DHB1U_x9J1dRXqDe8wegYw/DHB6d > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > And then it gets redirect from proxy-server. And next request Browser > substitutes POST to GET, as stated in RFC: > > > * > Request URL: > > https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw > * > Request Method: > GET > * > Status Code: > 302 > * > Remote Address: > 10.1.37.99:443 > * > Referrer Policy: > no-referrer-when-downgrade > 1. Response Headers > * > cache-control: > no-cache, no-store > * > content-length: > 0 > * > date: > Fri, 24 Apr 2020 09:17:33 GMT > * > expires: > Thu, 01 Jan 1970 00:00:00 GMT > * > location: > ./login.html?wicket-crypt=0SaMcpSjW2Y > * > pragma: > no-cache > * > server: > nginx > * > status: > 302 > > Am I missing something? > I don't know. You tell us :-) Is there a problem with the functionality ? As far as I understood until now the problem was that there is no POST submit. Now you see that there is such. I hope you have some log statements in your Form#onSubmit() and #onError() and you can verify either of those is called. > > -Igor. > > On 24. Apr 2020, at 09:41, Martin Grigorov mgrigo...@apache.org>> wrote: > > On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov > igor.khvosten...@lindenbaum.eu.invalid>> wrote: > > Hi Martin, > > Yes, this is login form with special “token". > > If this is PRG should I see POST request in Browser console? I see only > GET. Exactly one I’ve posted. Meaning that Browser does the substitution. > > > Yes, you should see POST with status 302 and then GET. > But to see them both you need to check "Preserve log" in the Network tab. > Otherwise the browser shows only the requests for the last load of the page > (including the request for the page itself and all resources like > css/js/images) > > > > -Igor. > > On 24. Apr 2020, at 06:02, Martin Grigorov mgrigo...@apache.org> mgrigo...@apache.org<mailto:mgrigo...@apache.org>>> wrote: > > Hi Igor, > > > > On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov > igor.khvosten...@lindenbaum.eu.invalid> igor.khvosten...@lindenbaum.eu.invalid igor.khvosten...@lindenbaum.eu.invalid>>> wrote: > > Hi Sven, > > POST is substituted with GET by the HTTP client (Browser). > > A web-server, any web-server, returns a 301 or 302 redirect then Browser, > on client side, will replace any type of request to GET. No server-side > configuration or any http headers returned will not change that. > > -Igor. > > > On 23. Apr 2020, at 22:47, Sven Meier s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>> s...@meiers.net<mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote: > > Hi Igor, > > so you think the "post" is redirected to a "get"? Why should that be the > case? > > Who issues this redirect? > > Best regards > Sven > > > On 23.04.20 22:37, Igor Khvostenkov wrote: > Hi Sven, > > Thank you for your reply. I did some deep investigation in the problem and > this is what I found: > > if the generated HTML contains method="post", the browser will send the > form as post request. > This is no exactly true. Or let’s say this is true not in all cases. The > problem could happen when your web server returns a 301 or 302 redirect > then Browser will replace any type of request to G
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Martin, Thanks for the hint with "Preserve log”. Looks like still this is exactly what I described in reply to Sven. Browser does really POST request: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: POST * Status Code: 302 * Remote Address: xxx:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./DHB1U_x9J1dRXqDe8wegYw/DHB6d * pragma: no-cache * server: nginx * status: 302 And then it gets redirect from proxy-server. And next request Browser substitutes POST to GET, as stated in RFC: * Request URL: https://xxx/conference/ng/login.html?wicket-crypt=K74urk0qnfk8F32WFqNIZ0ccIAoZmK_PRtgAUuVznyL7RVd7N2v3qyd6logyxMvfiOoODib4b4SbNSzjrurYj7CtzyDM6frC1a9kKasEFTErL7A1o8Y6qjFRX8EKFKZXfqOAAsWO01QO7MgjTsJaOkrQX-Ez-mAG5UgADs3kdXgJpJlXbS8vhw * Request Method: GET * Status Code: 302 * Remote Address: 10.1.37.99:443 * Referrer Policy: no-referrer-when-downgrade 1. Response Headers * cache-control: no-cache, no-store * content-length: 0 * date: Fri, 24 Apr 2020 09:17:33 GMT * expires: Thu, 01 Jan 1970 00:00:00 GMT * location: ./login.html?wicket-crypt=0SaMcpSjW2Y * pragma: no-cache * server: nginx * status: 302 Am I missing something? -Igor. On 24. Apr 2020, at 09:41, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org>mailto:mgrigo...@apache.org>>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>mailto:igor.khvosten...@lindenbaum.eu.invalid>>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net>mailto:s...@meiers.net>>mailto:s...@meiers.net><mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98 . Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net>><mailto:s...@meiers.net&
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov wrote: > Hi Martin, > > Yes, this is login form with special “token". > > If this is PRG should I see POST request in Browser console? I see only > GET. Exactly one I’ve posted. Meaning that Browser does the substitution. > Yes, you should see POST with status 302 and then GET. But to see them both you need to check "Preserve log" in the Network tab. Otherwise the browser shows only the requests for the last load of the page (including the request for the page itself and all resources like css/js/images) > > -Igor. > > On 24. Apr 2020, at 06:02, Martin Grigorov mgrigo...@apache.org>> wrote: > > Hi Igor, > > > > On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov > igor.khvosten...@lindenbaum.eu.invalid>> wrote: > > Hi Sven, > > POST is substituted with GET by the HTTP client (Browser). > > A web-server, any web-server, returns a 301 or 302 redirect then Browser, > on client side, will replace any type of request to GET. No server-side > configuration or any http headers returned will not change that. > > -Igor. > > > On 23. Apr 2020, at 22:47, Sven Meier s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>>> wrote: > > Hi Igor, > > so you think the "post" is redirected to a "get"? Why should that be the > case? > > Who issues this redirect? > > Best regards > Sven > > > On 23.04.20 22:37, Igor Khvostenkov wrote: > Hi Sven, > > Thank you for your reply. I did some deep investigation in the problem and > this is what I found: > > if the generated HTML contains method="post", the browser will send the > form as post request. > This is no exactly true. Or let’s say this is true not in all cases. The > problem could happen when your web server returns a 301 or 302 redirect > then Browser will replace any type of request to GET: > > > Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< > https://tools.ietf.org/html/rfc2068> specify that the client is not > allowed > to change the method on the redirected request. However, most > existing user agent implementations treat 302 as if it were a 303 > response, performing a GET on the Location field-value regardless > of the original request method. The status codes 303 and 307 have > been added for servers that wish to make unambiguously clear which > kind of reaction is expected of the client. > > This is exactly what happens in my case. And I can not really do anything > here, this is how all Browsers work. This was working good until we > upgraded to Wicket 7.16. There is one change which “broke” previously > working stuff. This change > https://issues.apache.org/jira/browse/WICKET-6708 and more precise this > code > > https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98 > . > Starting from Wicket 7.16 you distinguish between GET and POST in > FormComponent#getInputAsArray() and for the form submit this will not work > in case of redirect. > > -Igor. > > On 23. Apr 2020, at 17:15, Sven Meier s...@meiers.net> s...@meiers.net<mailto:s...@meiers.net>><mailto:s...@meiers.net>> wrote: > > Hi, > > if the generated HTML contains method="post", the browser will send the > form as post request. > > Without more detailed information, it's hard to find the error. Can you > write a quickstart? > > Have fun > Sven > > > On 23.04.20 11:59, Igor Khvostenkov wrote: > Hi *, > > I faced with the problem. When Wicket-generated URL contains jsessionId, > form submitted with GET request, and not POST. If I remove jsessionId from > URL, then normal POST request is done. I have no idea where this GET is > coming from. I ovverode getMethod() to always return POST and issue still > exist. Any ideas where I can look to figure out why GET request is done? > > Generated HTML: > > > > > wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm" > method="post" > > action="./login.html;jsessionid=8B3813A1300187D10FE8211AF47D9F7F?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm" > wicketsource="Login.java:39"> > style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden" > class="hidden-fields"> id="accessForm5_hf_0"> style="display:none"> Konferenz-Teilnehmer class="form-group"> class="form-control" value=
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Martin, Yes, this is login form with special “token". If this is PRG should I see POST request in Browser console? I see only GET. Exactly one I’ve posted. Meaning that Browser does the substitution. -Igor. On 24. Apr 2020, at 06:02, Martin Grigorov mailto:mgrigo...@apache.org>> wrote: Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov mailto:igor.khvosten...@lindenbaum.eu.invalid>> wrote: Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net>mailto:s...@meiers.net>>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net>mailto:s...@meiers.net>><mailto:s...@meiers.net>> wrote: Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://en.wikipedia.org/wiki/Post/Redirect/Get for more details. 4. :scheme: https 5. accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 6. accept-encoding: gzip, deflate, br 7. accept-language: de 8. cookie: JSESSIONID=8B3813A1300187D10FE8211AF47D9F7F 9. referer: https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Igor, On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov wrote: > Hi Sven, > > POST is substituted with GET by the HTTP client (Browser). > > A web-server, any web-server, returns a 301 or 302 redirect then Browser, > on client side, will replace any type of request to GET. No server-side > configuration or any http headers returned will not change that. > > -Igor. > > > On 23. Apr 2020, at 22:47, Sven Meier s...@meiers.net>> wrote: > > Hi Igor, > > so you think the "post" is redirected to a "get"? Why should that be the > case? > > Who issues this redirect? > > Best regards > Sven > > > On 23.04.20 22:37, Igor Khvostenkov wrote: > Hi Sven, > > Thank you for your reply. I did some deep investigation in the problem and > this is what I found: > > if the generated HTML contains method="post", the browser will send the > form as post request. > This is no exactly true. Or let’s say this is true not in all cases. The > problem could happen when your web server returns a 301 or 302 redirect > then Browser will replace any type of request to GET: > > > Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068< > https://tools.ietf.org/html/rfc2068> specify that the client is not > allowed > to change the method on the redirected request. However, most > existing user agent implementations treat 302 as if it were a 303 > response, performing a GET on the Location field-value regardless > of the original request method. The status codes 303 and 307 have > been added for servers that wish to make unambiguously clear which > kind of reaction is expected of the client. > > This is exactly what happens in my case. And I can not really do anything > here, this is how all Browsers work. This was working good until we > upgraded to Wicket 7.16. There is one change which “broke” previously > working stuff. This change > https://issues.apache.org/jira/browse/WICKET-6708 and more precise this > code > https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. > Starting from Wicket 7.16 you distinguish between GET and POST in > FormComponent#getInputAsArray() and for the form submit this will not work > in case of redirect. > > -Igor. > > On 23. Apr 2020, at 17:15, Sven Meier s...@meiers.net><mailto:s...@meiers.net>> wrote: > > Hi, > > if the generated HTML contains method="post", the browser will send the > form as post request. > > Without more detailed information, it's hard to find the error. Can you > write a quickstart? > > Have fun > Sven > > > On 23.04.20 11:59, Igor Khvostenkov wrote: > Hi *, > > I faced with the problem. When Wicket-generated URL contains jsessionId, > form submitted with GET request, and not POST. If I remove jsessionId from > URL, then normal POST request is done. I have no idea where this GET is > coming from. I ovverode getMethod() to always return POST and issue still > exist. Any ideas where I can look to figure out why GET request is done? > > Generated HTML: > > > > wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm" > method="post" > action="./login.html;jsessionid=8B3813A1300187D10FE8211AF47D9F7F?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm" > wicketsource="Login.java:39"> style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden" > class="hidden-fields"> id="accessForm5_hf_0"> style="display:none"> Konferenz-Teilnehmer class="form-group"> class="form-control" value="" name=“code" > wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_code" > placeholder=“Code" wicketsource="LoginForm.java:50"> class="input-group-btn"> wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_wicket__message__attr__6578556" > value="Teilnehmen"> > > > Request Headers: > > > 1. > :authority: > xxx > 2. > :method: > GET > 3. > :path: > > /conference/ng/login.html?0-1.IFormSubmitListener-pageBorder-pageBorder_body-mainBorder-mainBorder_body-contentBorder-contentBorder_body-content-accessForm > Is that a login form that you try to submit ? Or it is another form and the server sees that you are not au
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Sven, POST is substituted with GET by the HTTP client (Browser). A web-server, any web-server, returns a 301 or 302 redirect then Browser, on client side, will replace any type of request to GET. No server-side configuration or any http headers returned will not change that. -Igor. On 23. Apr 2020, at 22:47, Sven Meier mailto:s...@meiers.net>> wrote: Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068<https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net><mailto:s...@meiers.net>> wrote: Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto:users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto:users-h...@wicket.apache.org> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto:users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto:users-h...@wicket.apache.org>
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Igor, so you think the "post" is redirected to a "get"? Why should that be the case? Who issues this redirect? Best regards Sven On 23.04.20 22:37, Igor Khvostenkov wrote: Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068<https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net>> wrote: Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto:users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto:users-h...@wicket.apache.org> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi Sven, Thank you for your reply. I did some deep investigation in the problem and this is what I found: if the generated HTML contains method="post", the browser will send the form as post request. This is no exactly true. Or let’s say this is true not in all cases. The problem could happen when your web server returns a 301 or 302 redirect then Browser will replace any type of request to GET: Note: RFC 1945<https://tools.ietf.org/html/rfc1945> and RFC 2068<https://tools.ietf.org/html/rfc2068> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client. This is exactly what happens in my case. And I can not really do anything here, this is how all Browsers work. This was working good until we upgraded to Wicket 7.16. There is one change which “broke” previously working stuff. This change https://issues.apache.org/jira/browse/WICKET-6708 and more precise this code https://github.com/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98. Starting from Wicket 7.16 you distinguish between GET and POST in FormComponent#getInputAsArray() and for the form submit this will not work in case of redirect. -Igor. On 23. Apr 2020, at 17:15, Sven Meier mailto:s...@meiers.net>> wrote: Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org<mailto:users-unsubscr...@wicket.apache.org> For additional commands, e-mail: users-h...@wicket.apache.org<mailto:users-h...@wicket.apache.org>
Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi, if the generated HTML contains method="post", the browser will send the form as post request. Without more detailed information, it's hard to find the error. Can you write a quickstart? Have fun Sven On 23.04.20 11:59, Igor Khvostenkov wrote: Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Form submit sends GET request, if Wicket-generated URL contains jsessionId
Hi *, I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done? Generated HTML: Konferenz-Teilnehmer https://xxx/conference/ng/wicket/page?3 10. sec-fetch-dest: document 11. sec-fetch-mode: navigate 12. sec-fetch-site: same-origin 13. upgrade-insecure-requests: 1 14. user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36 -Igor.
Users can be redirected based on unvalidated input (CWE-601: URL Redirection to Untrusted Site)
Hi, Do you have a knowledge how to protect a Wicket application against such a problem: http://cwe.mitre.org/data/definitions/601.html In short: redirect request can be intercepted and the attacker can change Host header to another value. Can it be done on application (Wicket, Java Servlet) level (such Host header checking) or should it be done outside an app, on the reverse-proxy level, ...? More details: Description: The application redirects users based on the value of the Host header. As this value is not properly validated, redirects to third party domains can occur. Impact: It is possible to redirect application users to a URL outside the customer control. Such a website might be used in phishing attacks to harvest user credentials or try to exploit vulnerabilities on a user’s machine. This vulnerability might also lead to web-cache poisoning and poisoning of links that are send to an user via an e-mail functionality. Proposal: Validate all input parameters used for redirection and deny any request if the supplied value does not belong to the application’s domain. -- Daniel - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 9 migration guide : No such URL
Added it! Thanks, François! On Thu, Jun 20, 2019 at 2:02 PM Francois Meillet wrote: > There is no html data for Wicket 9 migration guide > > https://s.apache.org/wicket9migration < > https://s.apache.org/wicket9migration> : No such URL > > > François > > > >
Wicket 9 migration guide : No such URL
There is no html data for Wicket 9 migration guide https://s.apache.org/wicket9migration <https://s.apache.org/wicket9migration> : No such URL François
Re: Some Wicket components freeze app when URL rewrite
Ooups, wrong handling, I mixed my aliases in previous email :-( That was the answer to Sven about the browser requests. Sorry - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Some Wicket components freeze app when URL rewrite
WL10 : wanted URL : 302 to ;JSESSIONID= 302 to ?0 200 -> OK WL12 : wanted URL : 503 after 2-3 minutes after i try with WL12, in the IIS logs, i find http 400
Re: Some Wicket components freeze app when URL rewrite
Check your browser network console, what URL is redirected to and whether the following request succeeds. Sven > > On 26.04.2019 at 10:58,wrote: > > > That's right, but seems like this redirect doesn't arrive to browser, not > even sure it comes to IIS. I looked at the IIS logs, it says error 400. The > same redirection with the old server (WL10, Wicket 1.5.10) through the same > IIS is OK. I even just tried to deploy the older war on the WL12, it fails on > same problem. WL12 seems to cause something wrong... Do you have an idea of a > possible cause ? (non standard behaviour ? something else ?) Something else > to try ? Thanks in advance... > - To > unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional > commands, e-mail: users-h...@wicket.apache.org >
Re: Some Wicket components freeze app when URL rewrite
That's right, but seems like this redirect doesn't arrive to browser, not even sure it comes to IIS. I looked at the IIS logs, it says error 400. The same redirection with the old server (WL10, Wicket 1.5.10) through the same IIS is OK. I even just tried to deploy the older war on the WL12, it fails on same problem. WL12 seems to cause something wrong... Do you have an idea of a possible cause ? (non standard behaviour ? something else ?) Something else to try ? Thanks in advance... - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Some Wicket components freeze app when URL rewrite
By adding the link your page becomes stateful. So Wicket will issue a redirect to a second url with a number attached, e.g. ?1 You'll have to check what your url rewrite is doing to that redirect url. Hope this helps Sven > > On 25.04.2019 at 14:03,wrote: > > > Hi, I am migrating an application using wicket and a network configuration a > bit weird, and i'm facing a unexpected behaviour. The network configuration: > outside | IIS URL rewrite | Weblogic with Wicket app The snippet : I have > simplified the app, so i reproduce the code on a quickstart-based app. > --html-- > > John Doe--code-- public class HomePage extends WebPage { public > HomePage(final PageParameters parameters) { super(parameters); add(new > Label("testname", "Me")); // add(new Link("changetonl"){ // @Override // > public void onClick() { // this.getSession().setLocale(new Locale("nl")); // > } // }); } } The problem : The page as stated just higher works, but if i > uncomment the tag and the add(Link), the IIS server says "http code 400" and > i have 503 message instead of the page. Environment : -was Weblogic 10.3 with > wicket 1.5.10 -> was OK -now Weblogic 12.2 with wicket 7.11 (for now) : All > works when using URL directly on the WL server works when using the URL from > outside (through IIS url rewrite) if only Label BUT gives the problem when > using the URL from outside (through IIS url rewrite) if Link uncommented Do > you have an idea what could be the problem ? Thanks Gaston_L > - To > unsubscribe, e-mail: users-unsubscri b...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >
Some Wicket components freeze app when URL rewrite
Hi, I am migrating an application using wicket and a network configuration a bit weird, and i'm facing a unexpected behaviour. The network configuration: outside | IIS URL rewrite | Weblogic with Wicket app The snippet : I have simplified the app, so i reproduce the code on a quickstart-based app. --html-- http://wicket.apache.org";> John Doe --code-- public class HomePage extends WebPage { public HomePage(final PageParameters parameters) { super(parameters); add(new Label("testname", "Me")); // add(new Link("changetonl"){ // @Override // public void onClick() { // this.getSession().setLocale(new Locale("nl")); // } // }); } } The problem : The page as stated just higher works, but if i uncomment the tag and the add(Link), the IIS server says "http code 400" and i have 503 message instead of the page. Environment : -was Weblogic 10.3 with wicket 1.5.10 -> was OK -now Weblogic 12.2 with wicket 7.11 (for now) : All works when using URL directly on the WL server works when using the URL from outside (through IIS url rewrite) if only Label BUT gives the problem when using the URL from outside (through IIS url rewrite) if Link uncommented Do you have an idea what could be the problem ? Thanks Gaston_L - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Skip URL escape on redirect
Hi Martin, It works fine if using this status code. Thank you for your help. Calin Pavel On 3/6/2019 5:47 PM, Martin Grigorov wrote: Hi, Use RedirectToUrlException(yourUrl, HttpServletResponse.SC_SEE_OTHER) See https://markmail.org/message/bis57nb2yecdgzqx for more details. It has been discussed last week. On Wed, Mar 6, 2019 at 5:02 PM Calin Pavel wrote: Hello, I'm doing a redirect from Wicket code like* throw new RedirectToUrlException(" http://mydomain/file(1).txt?Signature=JdfsuerJQEWQA2"); *and this should redirect user to this page which is accessible if signature is valid (checks if URL did not changed). But, when doing the redirect Wicket escapes the brackets - so browser received in header location=*http://mydomain/file%281%29.txt?Signature=JdfsuerJQEWQA2 *, but the server does not accepts the request because signature does not match this URL. For this: 1. is there any other way to do the redirect without escaping URL? 2. is it a browser problem - it should unescape URL before doing redirect? have some doubts, since all (Chrome, IE, Firefox) works the same 3. would it be the responsibility of the targeted server to decode / unescape URL and then check for the signature? Thank you, Calin Pavel * * - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Skip URL escape on redirect
Hi, Use RedirectToUrlException(yourUrl, HttpServletResponse.SC_SEE_OTHER) See https://markmail.org/message/bis57nb2yecdgzqx for more details. It has been discussed last week. On Wed, Mar 6, 2019 at 5:02 PM Calin Pavel wrote: > Hello, > > I'm doing a redirect from Wicket code like* throw new > RedirectToUrlException(" > http://mydomain/file(1).txt?Signature=JdfsuerJQEWQA2"); > *and this should redirect user to this page which is accessible if > signature is valid (checks if URL did not changed). > > But, when doing the redirect Wicket escapes the brackets - so browser > received in header > location=*http://mydomain/file%281%29.txt?Signature=JdfsuerJQEWQA2 *, > but the server does not accepts the request because signature does not > match this URL. > > For this: > 1. is there any other way to do the redirect without escaping URL? > > 2. is it a browser problem - it should unescape URL before doing > redirect? have some doubts, since all (Chrome, IE, Firefox) works the same > 3. would it be the responsibility of the targeted server to decode / > unescape URL and then check for the signature? > > Thank you, > Calin Pavel > * > * >
Re: Skip URL escape on redirect
IMO better way would be to create hash for encoded URL On Wed, 6 Mar 2019 at 22:02, Calin Pavel wrote: > > Hello, > > I'm doing a redirect from Wicket code like* throw new > RedirectToUrlException("http://mydomain/file(1).txt?Signature=JdfsuerJQEWQA2"); > *and this should redirect user to this page which is accessible if > signature is valid (checks if URL did not changed). > > But, when doing the redirect Wicket escapes the brackets - so browser > received in header > location=*http://mydomain/file%281%29.txt?Signature=JdfsuerJQEWQA2 *, > but the server does not accepts the request because signature does not > match this URL. > > For this: > 1. is there any other way to do the redirect without escaping URL? > > 2. is it a browser problem - it should unescape URL before doing > redirect? have some doubts, since all (Chrome, IE, Firefox) works the same > 3. would it be the responsibility of the targeted server to decode / > unescape URL and then check for the signature? > > Thank you, > Calin Pavel > * > * -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Skip URL escape on redirect
Hello, I'm doing a redirect from Wicket code like* throw new RedirectToUrlException("http://mydomain/file(1).txt?Signature=JdfsuerJQEWQA2"); *and this should redirect user to this page which is accessible if signature is valid (checks if URL did not changed). But, when doing the redirect Wicket escapes the brackets - so browser received in header location=*http://mydomain/file%281%29.txt?Signature=JdfsuerJQEWQA2 *, but the server does not accepts the request because signature does not match this URL. For this: 1. is there any other way to do the redirect without escaping URL? 2. is it a browser problem - it should unescape URL before doing redirect? have some doubts, since all (Chrome, IE, Firefox) works the same 3. would it be the responsibility of the targeted server to decode / unescape URL and then check for the signature? Thank you, Calin Pavel * *
RE: Undesirable decoding of URL encoded external URL using RedirectToUrlException
Actually - I spoke too soon :) When I use SC_SEE_OTHER inside an AJAX invoked form submit method it works fine if the URL is for the same hostname but when it points to a different hostname (external link) the browser refuses to redirect, giving a CORS error. I could configure CORS on the external server but this is a redirect so I am wondering why is CORS an issue? Maybe the browsers treats all XMLHttpRequestS as resource accesses to display in the current page even if they are not actually requesting a resource to be displayed in the current page but invoking redirect to a completely new page? The redirect 302 doesn't have this problem but then I'm back to the undesirable premature decoding of the query parameters. It seems like the browser understands that 302 is a proper redirect (not a resource fetch for the current page) and so does not raise a CORS error. That got me thinking that may I could use SC_TEMPORARY_REDIRECT instead but that results in a: java.lang.IllegalStateException: Status must be either 301, 302 or 303, but was: 307 > -Original Message- > From: Chris Colman [mailto:chr...@stepaheadsoftware.com] > Sent: Wednesday, 27 February 2019 9:06 PM > To: users@wicket.apache.org > Subject: RE: Undesirable decoding of URL encoded external URL using > RedirectToUrlException > > That works brilliantly! > > Thanks Martin > > > -Original Message- > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > Sent: Tuesday, 26 February 2019 10:46 PM > > To: users@wicket.apache.org > > Subject: Re: Undesirable decoding of URL encoded external URL using > > RedirectToUrlException > > > > Hi, > > > > It seems you use RedirectToUrlException(String) constructor which > > internally uses statusCode=HttpServletResponse.SC_MOVED_TEMPORARILY. > > If you use RedirectToUrlException(yourUrl, > > HttpServletResponse.SC_SEE_OTHER) then Wicket will not do its extra > logic > > in > > > org.apache.wicket.protocol.http.servlet.ServletWebResponse#encodeRedirec > tU > > RL() > > and all should be fine. > > > > On Mon, Feb 25, 2019 at 8:13 PM Chris Colman > > > > wrote: > > > > > I am using: > > > > > > > > > > > > throw new RedirectUrlException(externalUrl); > > > > > > > > > > > > to redirect to an external URL (i.e. > > > https://hostname/path?param1=value1¶m2=value2 etc.,) > > > > > > > > > > > > In constructing the URL I have used java.net.URLEncoder.encode() to > > > individual encode the values in each of the query parameters. > > > > > > > > > > > > The browser shows the redirected URL with the query parameters being > > > 'decoded' not encoded. > > > > > > > > > > > > I stepped through in the debugger and saw that Wicket's > > > org.apache.wicket.util.encoding.UrlDecoder is being used to decode > the > > > URL while processing the redirect. > > > > > > > > > > > > > > > > > > I worked around problem by using the native Servlet API redirect: > > > > > > > > > > > > HttpServletResponse response = > > > > (HttpServletResponse)getRequestCycle().getResponse().getContainerRespons > > > e(); > > > > > > try > > > > > > { > > > > > > response.sendRedirect(url); > > > > > > } > > > > > > catch(IOException ioe) > > > > > > { > > > > > > logger.error("Error while attempting to > redirect > > > to: " + url); > > > > > > } > > > > > > > > > > > > However, is there a 'Wicket' way of redirecting to an external URL > > > without causing the undesired decoding? > > > > > > > > > > > > > > > > > > Note: Using Wicket 6.x > > > > > > > > > > > > Regards, > > > > > > Chris > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Undesirable decoding of URL encoded external URL using RedirectToUrlException
That works brilliantly! Thanks Martin > -Original Message- > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Tuesday, 26 February 2019 10:46 PM > To: users@wicket.apache.org > Subject: Re: Undesirable decoding of URL encoded external URL using > RedirectToUrlException > > Hi, > > It seems you use RedirectToUrlException(String) constructor which > internally uses statusCode=HttpServletResponse.SC_MOVED_TEMPORARILY. > If you use RedirectToUrlException(yourUrl, > HttpServletResponse.SC_SEE_OTHER) then Wicket will not do its extra logic > in > org.apache.wicket.protocol.http.servlet.ServletWebResponse#encodeRedirec tU > RL() > and all should be fine. > > On Mon, Feb 25, 2019 at 8:13 PM Chris Colman > > wrote: > > > I am using: > > > > > > > > throw new RedirectUrlException(externalUrl); > > > > > > > > to redirect to an external URL (i.e. > > https://hostname/path?param1=value1¶m2=value2 etc.,) > > > > > > > > In constructing the URL I have used java.net.URLEncoder.encode() to > > individual encode the values in each of the query parameters. > > > > > > > > The browser shows the redirected URL with the query parameters being > > 'decoded' not encoded. > > > > > > > > I stepped through in the debugger and saw that Wicket's > > org.apache.wicket.util.encoding.UrlDecoder is being used to decode the > > URL while processing the redirect. > > > > > > > > > > > > I worked around problem by using the native Servlet API redirect: > > > > > > > > HttpServletResponse response = > > (HttpServletResponse)getRequestCycle().getResponse().getContainerRespons > > e(); > > > > try > > > > { > > > > response.sendRedirect(url); > > > > } > > > > catch(IOException ioe) > > > > { > > > > logger.error("Error while attempting to redirect > > to: " + url); > > > > } > > > > > > > > However, is there a 'Wicket' way of redirecting to an external URL > > without causing the undesired decoding? > > > > > > > > > > > > Note: Using Wicket 6.x > > > > > > > > Regards, > > > > Chris > > > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Undesirable decoding of URL encoded external URL using RedirectToUrlException
Hi, It seems you use RedirectToUrlException(String) constructor which internally uses statusCode=HttpServletResponse.SC_MOVED_TEMPORARILY. If you use RedirectToUrlException(yourUrl, HttpServletResponse.SC_SEE_OTHER) then Wicket will not do its extra logic in org.apache.wicket.protocol.http.servlet.ServletWebResponse#encodeRedirectURL() and all should be fine. On Mon, Feb 25, 2019 at 8:13 PM Chris Colman wrote: > I am using: > > > > throw new RedirectUrlException(externalUrl); > > > > to redirect to an external URL (i.e. > https://hostname/path?param1=value1¶m2=value2 etc.,) > > > > In constructing the URL I have used java.net.URLEncoder.encode() to > individual encode the values in each of the query parameters. > > > > The browser shows the redirected URL with the query parameters being > 'decoded' not encoded. > > > > I stepped through in the debugger and saw that Wicket's > org.apache.wicket.util.encoding.UrlDecoder is being used to decode the > URL while processing the redirect. > > > > > > I worked around problem by using the native Servlet API redirect: > > > > HttpServletResponse response = > (HttpServletResponse)getRequestCycle().getResponse().getContainerRespons > e(); > > try > > { > > response.sendRedirect(url); > > } > > catch(IOException ioe) > > { > > logger.error("Error while attempting to redirect > to: " + url); > > } > > > > However, is there a 'Wicket' way of redirecting to an external URL > without causing the undesired decoding? > > > > > > Note: Using Wicket 6.x > > > > Regards, > > Chris > >
Undesirable decoding of URL encoded external URL using RedirectToUrlException
I am using: throw new RedirectUrlException(externalUrl); to redirect to an external URL (i.e. https://hostname/path?param1=value1¶m2=value2 etc.,) In constructing the URL I have used java.net.URLEncoder.encode() to individual encode the values in each of the query parameters. The browser shows the redirected URL with the query parameters being 'decoded' not encoded. I stepped through in the debugger and saw that Wicket's org.apache.wicket.util.encoding.UrlDecoder is being used to decode the URL while processing the redirect. I worked around problem by using the native Servlet API redirect: HttpServletResponse response = (HttpServletResponse)getRequestCycle().getResponse().getContainerRespons e(); try { response.sendRedirect(url); } catch(IOException ioe) { logger.error("Error while attempting to redirect to: " + url); } However, is there a 'Wicket' way of redirecting to an external URL without causing the undesired decoding? Note: Using Wicket 6.x Regards, Chris
Re: [Wicket 8] delete version number in url
It does work! Thanks! I'll update SO as well! On Sun, Jun 3, 2018 at 2:53 PM, Maxim Solodovnik wrote: > This code https://github.com/apache/openmeetings/blob/master/ > openmeetings-web/src/main/java/org/apache/openmeetings/ > web/app/Application.java#L314 > Works for me > > On Sun, Jun 3, 2018 at 7:36 PM, Zala Pierre GOUPIL > wrote: > > All, > > > > There are a number of solutions around to remove the version number part > of > > the browser URL, for instance here: > > > > https://stackoverflow.com/questions/8602489/delete-version-number-in-url > > > > Unfortunately, I haven't figured out a Wicket 8 way of doing this: my > > modification of the code doesn't do the trick for 8.0.0. The migration > > guide has helped me to compile it but it doesn't work: in particular, my > > Ajax calls are stopped. > > > > Any ideas, please? > > > > > > > > -- > > Je n'aime pas seulement ma vie, mais aussi celle des autres. > > > > (Blade Runner) > > > > -- > WBR > Maxim aka solomax > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Je n'aime pas seulement ma vie, mais aussi celle des autres. (Blade Runner)
Re: [Wicket 8] delete version number in url
This code https://github.com/apache/openmeetings/blob/master/openmeetings-web/src/main/java/org/apache/openmeetings/web/app/Application.java#L314 Works for me On Sun, Jun 3, 2018 at 7:36 PM, Zala Pierre GOUPIL wrote: > All, > > There are a number of solutions around to remove the version number part of > the browser URL, for instance here: > > https://stackoverflow.com/questions/8602489/delete-version-number-in-url > > Unfortunately, I haven't figured out a Wicket 8 way of doing this: my > modification of the code doesn't do the trick for 8.0.0. The migration > guide has helped me to compile it but it doesn't work: in particular, my > Ajax calls are stopped. > > Any ideas, please? > > > > -- > Je n'aime pas seulement ma vie, mais aussi celle des autres. > > (Blade Runner) -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[Wicket 8] delete version number in url
All, There are a number of solutions around to remove the version number part of the browser URL, for instance here: https://stackoverflow.com/questions/8602489/delete-version-number-in-url Unfortunately, I haven't figured out a Wicket 8 way of doing this: my modification of the code doesn't do the trick for 8.0.0. The migration guide has helped me to compile it but it doesn't work: in particular, my Ajax calls are stopped. Any ideas, please? -- Je n'aime pas seulement ma vie, mais aussi celle des autres. (Blade Runner)
Re: How to use language/locale from url without creating a session?
Thank you, Martin! That’s an interesting way to fix this. Didn’t think of that, and it fits quite well with our current code, too. We can put our own “requestedLocale” field in our WebSession subclass, and use that if the session is temporary. Thanks! Met vriendelijke groet, Kind regards, Bas Gooren Op 26 mei 2018 bij 13:41:25, Martin Grigorov (mgrigo...@apache.org) schreef: Hi, Here is another solution: - put the locale in RequestCycle's metadata - override Session#getLocale() and if Session#isTemporary() then use the metadata, otherwise use the session's locale On Fri, May 25, 2018 at 7:20 PM, Bas Gooren wrote: > Hi! > > We build mainly e-commerce websites on wicket, which means most pages are > publicly visible and indexable. > Since our websites are multi-language we have a custom > CompoundRequestMapper which checks if the url contains a valid locale, and > updates the session locale accordingly. > > This works great! With one small issue we would ideally like to fix: wicket > binds the session once you call setLocale on it. As a result, every > (stateless) public url that is requested leads to a session being created, > and a cookie being sent to the requester. > > Since every component (effectively) depends on Session.get().getLocale() to > get the current locale, we see no other way to handle this cleanly. > > Writing this now and having another look at the wicket source code, I > reckon we could wrap the wicket request and override its getLocale() > method. I probably hesitated to do so before because wicket expects a > ServletWebRequest in some places, so the wrapper cannot simply extend the > base Request class. > Anyone here that has a good solution for this? Otherwise we have to check > for implementations and decide on the wrapper based on that, but that’s > rather ugly code. > > Also, I realize that we don’t just want to wrap the request for request > mapping purposes (in our compound mapper). We need to wrap the request > earlier, since we need to ensure the actual request passed in to the > session constructor returns a locale that matches with the url. > > Would appreciate any thoughts you have on this. > > Thanks! > > Met vriendelijke groet, > Kind regards, > > Bas Gooren >
Re: How to use language/locale from url without creating a session?
Hi, Here is another solution: - put the locale in RequestCycle's metadata - override Session#getLocale() and if Session#isTemporary() then use the metadata, otherwise use the session's locale On Fri, May 25, 2018 at 7:20 PM, Bas Gooren wrote: > Hi! > > We build mainly e-commerce websites on wicket, which means most pages are > publicly visible and indexable. > Since our websites are multi-language we have a custom > CompoundRequestMapper which checks if the url contains a valid locale, and > updates the session locale accordingly. > > This works great! With one small issue we would ideally like to fix: wicket > binds the session once you call setLocale on it. As a result, every > (stateless) public url that is requested leads to a session being created, > and a cookie being sent to the requester. > > Since every component (effectively) depends on Session.get().getLocale() to > get the current locale, we see no other way to handle this cleanly. > > Writing this now and having another look at the wicket source code, I > reckon we could wrap the wicket request and override its getLocale() > method. I probably hesitated to do so before because wicket expects a > ServletWebRequest in some places, so the wrapper cannot simply extend the > base Request class. > Anyone here that has a good solution for this? Otherwise we have to check > for implementations and decide on the wrapper based on that, but that’s > rather ugly code. > > Also, I realize that we don’t just want to wrap the request for request > mapping purposes (in our compound mapper). We need to wrap the request > earlier, since we need to ensure the actual request passed in to the > session constructor returns a locale that matches with the url. > > Would appreciate any thoughts you have on this. > > Thanks! > > Met vriendelijke groet, > Kind regards, > > Bas Gooren >
How to use language/locale from url without creating a session?
Hi! We build mainly e-commerce websites on wicket, which means most pages are publicly visible and indexable. Since our websites are multi-language we have a custom CompoundRequestMapper which checks if the url contains a valid locale, and updates the session locale accordingly. This works great! With one small issue we would ideally like to fix: wicket binds the session once you call setLocale on it. As a result, every (stateless) public url that is requested leads to a session being created, and a cookie being sent to the requester. Since every component (effectively) depends on Session.get().getLocale() to get the current locale, we see no other way to handle this cleanly. Writing this now and having another look at the wicket source code, I reckon we could wrap the wicket request and override its getLocale() method. I probably hesitated to do so before because wicket expects a ServletWebRequest in some places, so the wrapper cannot simply extend the base Request class. Anyone here that has a good solution for this? Otherwise we have to check for implementations and decide on the wrapper based on that, but that’s rather ugly code. Also, I realize that we don’t just want to wrap the request for request mapping purposes (in our compound mapper). We need to wrap the request earlier, since we need to ensure the actual request passed in to the session constructor returns a locale that matches with the url. Would appreciate any thoughts you have on this. Thanks! Met vriendelijke groet, Kind regards, Bas Gooren
Re: How to remove jsessionid from the URL?
Hmm that's weird. I was about to reproduce the issue in private mode like you said, but this time it worked, the cookies were set. Then I tried again in normal mode, and it worked there too. Must be because I restarted Windows :) Thanks for the help!
Re: How to remove jsessionid from the URL?
On Mon, Apr 9, 2018 at 2:45 PM, gcsaba2 wrote: > This is true, when I go to http://localhost:/ it will immediately > (302) > redirect me to http://localhost:777/home.html (my home page is mounted > here). > > AFTER that, the home page will 302 redirect me to > http://localhost:777/home.html;jsessionid=xxx > > All the links on the home page will, after this, contain the ;jsessionid > part, so clicking anywhere will pass on this token in the URL, and it will > never go away. > > If I manually remove the token by typing in the URL > http://localhost:777/home.html then it will 302 redirect me to the > http://localhost:777/home.html;jsessionid=xyz URL, but the session ID will > be different. This means my previous session has been lost and a new one > has > been created. > > Looking at the HTTP headers, I can see this: > > Set-Cookie: JSESSIONID=xyz; HttpOnly > > So the website definitely tries to set the session id. But when I click on > any of the links, in the request headers I will not see the browser sending > the JSESSIONID cookie back to the server. It looks like the browser forgot > about it. > > There is no time duration in the header, which is correct since this is a > session cookie. > > Btw. isn't it a problem that the cookie name is (upper case) JSESSIONID, > while the URL has a (lower case) jsessionid? > No. The cases are correct. > > I'm using an AuthenticatedWebApplication, which has a getWebSessionClass() > class. I could be wrong, but I think the session class instance should be > created only once per session. Here, I see it is being created on every > request. > > Also, if I write request.getCookie(JSESSIONID) it will always return null. > It seems the browser doesn't send the JSESSIONID cookie. Does it send any other cookie or all are lost ? You can create a test one in the Dev Tools Console with document.cookie="name=value" > > I did some more tests, and looks like this mostly happens on Firefox. On IE > and Chrome, after a few clicks, the jsessionid disappears from the URL. So > what's wrong with Firefox? I'm using the latest version with default > settings, why wouldn't it remember the session cookie? > Start a new instance of Firefox in private mode and try again. It could be that you have some plugin that forbids cookies. > > > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: How to remove jsessionid from the URL?
This is true, when I go to http://localhost:/ it will immediately (302) redirect me to http://localhost:777/home.html (my home page is mounted here). AFTER that, the home page will 302 redirect me to http://localhost:777/home.html;jsessionid=xxx All the links on the home page will, after this, contain the ;jsessionid part, so clicking anywhere will pass on this token in the URL, and it will never go away. If I manually remove the token by typing in the URL http://localhost:777/home.html then it will 302 redirect me to the http://localhost:777/home.html;jsessionid=xyz URL, but the session ID will be different. This means my previous session has been lost and a new one has been created. Looking at the HTTP headers, I can see this: Set-Cookie: JSESSIONID=xyz; HttpOnly So the website definitely tries to set the session id. But when I click on any of the links, in the request headers I will not see the browser sending the JSESSIONID cookie back to the server. It looks like the browser forgot about it. There is no time duration in the header, which is correct since this is a session cookie. Btw. isn't it a problem that the cookie name is (upper case) JSESSIONID, while the URL has a (lower case) jsessionid? I'm using an AuthenticatedWebApplication, which has a getWebSessionClass() class. I could be wrong, but I think the session class instance should be created only once per session. Here, I see it is being created on every request. Also, if I write request.getCookie(JSESSIONID) it will always return null. I did some more tests, and looks like this mostly happens on Firefox. On IE and Chrome, after a few clicks, the jsessionid disappears from the URL. So what's wrong with Firefox? I'm using the latest version with default settings, why wouldn't it remember the session cookie? -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to remove jsessionid from the URL?
On the very first request, the server doesn't know whether or not cookies are supported, so encodes the session id in the URL in addition to setting the cookie. There is a trick that involves forcing the browser to redirect the first request so that the server can determine that cookies are supported and omit the session id in the URL. On Sat, Apr 7, 2018, 9:40 PM gcsaba2 wrote: > Hello, > > I'm using Wicket 7 with Spring Boot. I've mounted several pages, and for > example when I go to search.html, the ;jsessionid always gets attached to > the URL. > > Is there some way to remove the jsessionid from the URLs? > > In the tomcat configuration I've already set the tracking-mode to be > cookie, > but still wicket puts the jsessionid in the url. What's even worse is that > all the links in the page have the jsessionid appended to the URL, so even > if I click anywhere, it will remain there. I would maybe accept it being > there the first time I visit the website and the session gets established, > but afterwards it's really unnecessary (and ugly). > > Thanks, > Csaba > > > -- > Sent from: > http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
How to remove jsessionid from the URL?
Hello, I'm using Wicket 7 with Spring Boot. I've mounted several pages, and for example when I go to search.html, the ;jsessionid always gets attached to the URL. Is there some way to remove the jsessionid from the URLs? In the tomcat configuration I've already set the tracking-mode to be cookie, but still wicket puts the jsessionid in the url. What's even worse is that all the links in the page have the jsessionid appended to the URL, so even if I click anywhere, it will remain there. I would maybe accept it being there the first time I visit the website and the session gets established, but afterwards it's really unnecessary (and ugly). Thanks, Csaba -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to block URL in wicket?
Hi, Such kind of security related issues should be reported to priv...@wicket.apache.org or to secur...@apache.org. But in your case it is not a big deal because you use Wicket 1.2/1.3. As far as I remember JTrac is not updated since these versions of Wicket. Try by using PackageResourceGuard. Here is the documentation for Wicket 7.x [1] but it should be similar for 1.2/1.3 1. https://ci.apache.org/projects/wicket/guide/7.x/single.html#_package_resource_guard Martin Grigorov Wicket Training and Consulting Looking for a remote position with Wicket ? Contact me! https://twitter.com/mtgrigorov On Thu, Mar 1, 2018 at 7:14 AM, parth wrote: > *http://localhost:8080/my_project/app/resources/org.apache.wicket.ajax. > AbstractDefaultAjaxBehavior/* > > If user can enter this URL then he can see resouces of my project > > *Example :* > jtrac.hbm.xml > jtrac-init.properties > messages_ar.properties > messages_cs.properties > messages_de.properties > messages_el.properties > messages_en.properties > ... > > So i want to block this URL and not permit any user to show these details. > > Thank you. > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
How to block URL in wicket?
*http://localhost:8080/my_project/app/resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/* If user can enter this URL then he can see resouces of my project *Example :* jtrac.hbm.xml jtrac-init.properties messages_ar.properties messages_cs.properties messages_de.properties messages_el.properties messages_en.properties ... So i want to block this URL and not permit any user to show these details. Thank you. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
Thanks a lot Marcel for a tip. I will consult it with our DevOps guys. regards T. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
Thanks a lot Marcel for a tip, I will consult it with our DevOps guys. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
Hi, Are you using X-Forwarded headers sent by your balancer? You can to override this method in you WicketApplication class to try to debug the redirect: @Override protected WebResponse newWebResponse(final WebRequest webRequest, final HttpServletResponse httpServletResponse) { return new ServletWebResponse((ServletWebRequest) webRequest, httpServletResponse) { @Override public String encodeRedirectURL(CharSequence url) { String encodedUrl = super.encodeRedirectURL(url); if (webRequest.getUrl().getProtocol() == "https") { //https } return encodedUrl; } }; } On Fri, Sep 1, 2017 at 10:20 AM, tomask79 wrote: > After some investigation this seems to be happening > when HeapUsage at the affected node is almost 100%... > > Memory statistics by org.apache.wicket.protocol. > http.requests.RequestLogger > few moments before the mentioned redirect looping: > > > > I'm confused by the following: > > 1) Why wicket things that URL is changing when it's not!(response handler > is > RequestSettingRequestHandler)... > > 2) What triggers these requests...It has to be Wicket, because > RequestSettingRequestHandler is response. > > Thanks for any kind of hint or help. > > > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Marcel Barbosa Pinto 55 11 98255 8288
Re: 302 Redirects triggered by Wicket when URL is same
After some investigation this seems to be happening when HeapUsage at the affected node is almost 100%... Memory statistics by org.apache.wicket.protocol.http.requests.RequestLogger few moments before the mentioned redirect looping: I'm confused by the following: 1) Why wicket things that URL is changing when it's not!(response handler is RequestSettingRequestHandler)... 2) What triggers these requests...It has to be Wicket, because RequestSettingRequestHandler is response. Thanks for any kind of hint or help. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
After some investigation this seems to be happening when HeapUsage at the affected node is almost 100%... Memory statistics by org.apache.wicket.protocol.http.requests.RequestLogger few moments before the mentioned redirect looping: I'm confused by the things: 1) Why wicket things that URL is changing when it's not!(response handler is RequestSettingRequestHandler)... 2) What triggers these requests...It has to be Wicket, because RequestSettingRequestHandler is response. Thanks for any kind of hint or help. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
Strange, I edited initial question and inserted the logs again... any hint would help. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 302 Redirects triggered by Wicket when URL is same
Hi, I have the feeling that your pastes didn't make it. See for yourself at http://apache-wicket.1842946.n4.nabble.com/302-Redirects-triggered-by-Wicket-when-URL-is-same-td4678633.html Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Aug 31, 2017 at 6:41 PM, tomask79 wrote: > Hi guys, > > I desperately need help with Wicket 6.21 in the cluster > environment...Sometimes, nondeterministically, wicket redirects user > in the following loop: > > (from audit log before wicket filter) > > (page-crypt query parameter is JUST the renamed wicket-crypt parameter from > KeyInSessionSunJceCryptFactory). > > Output from Wicket's RequestLogger (URL is still the same, I don't get it, > Wicket obviously thinks that URL has changed, because responseHandler is > RequestSettingRequestHandler): > > . > . > later this loop ends in 302 redirects > (again audit log) > > > This problem is driving me nuts, do you have any idea why wicket starts > this > loop? > Any kind of hint or help where to look would help me a lot. > > Thanks in advance > > Tomas > > > > > > -- > Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum- > f1842947.html > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
302 Redirects triggered by Wicket when URL is same
Hi guys, I desperately need help with Wicket 6.21 in the cluster environment...Sometimes, nondeterministically, wicket redirects user in the following loop: (from audit log before wicket filter) (page-crypt query parameter is JUST the renamed wicket-crypt parameter from KeyInSessionSunJceCryptFactory). Output from Wicket's RequestLogger (URL is still the same, I don't get it, Wicket obviously thinks that URL has changed, because responseHandler is RequestSettingRequestHandler): . . later this loop ends in 302 redirects (again audit log) This problem is driving me nuts, do you have any idea why wicket starts this loop? Any kind of hint or help where to look would help me a lot. Thanks in advance Tomas -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When using KeyInSessionSunJceCryptFactory howto detect that requested URL is from old session?
Nice, thanks a lot, Martin. T. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/When-using-KeyInSessionSunJceCryptFactory-howto-detect-that-requested-URL-is-from-old-session-tp4678269p4678271.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: When using KeyInSessionSunJceCryptFactory howto detect that requested URL is from old session?
Hi, Another way is to extend CryptoMapper, override its #mapRequest(Url) method and do your logic there. This way you know that IllegalBlockSizeException or BadPaddingException is related to the page/resources' urls, and not to something else that uses the crypto classes. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Mon, Jul 24, 2017 at 12:38 PM, tomask79 wrote: > Hi guys, > > we use KeyInSessionSunJceCryptFactory to protected our app from CSRF, where > every user have it's own encryption key per session for URL crypting. > > Anyway,* I want to be able to detect when user uses URL from previous > session and to display some warning* or something like that. > > The only thing I can think of is to catch "IllegalBlockSizeException" in > org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe method and > rethrow > it as my ApplicationException and catch it in some RequestCycle listener... > > Is there a better way? > > Thanks in advance for your help > > regards > > Tomas > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/When-using-KeyInSessionSunJceCryptFactory > -howto-detect-that-requested-URL-is-from-old-session-tp4678269.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
When using KeyInSessionSunJceCryptFactory howto detect that requested URL is from old session?
Hi guys, we use KeyInSessionSunJceCryptFactory to protected our app from CSRF, where every user have it's own encryption key per session for URL crypting. Anyway,* I want to be able to detect when user uses URL from previous session and to display some warning* or something like that. The only thing I can think of is to catch "IllegalBlockSizeException" in org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe method and rethrow it as my ApplicationException and catch it in some RequestCycle listener... Is there a better way? Thanks in advance for your help regards Tomas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/When-using-KeyInSessionSunJceCryptFactory-howto-detect-that-requested-URL-is-from-old-session-tp4678269.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Websocket redirect wrong url
On Wed, May 24, 2017 at 12:18 PM, Peter Henderson < peter.hender...@starjar.com> wrote: > On 24 May 2017 at 11:05, Peter Henderson > wrote: > > > > > > > On 23 May 2017 at 22:24, Martin Grigorov wrote: > > > >> Hi, > >> > >> I'm afraid a quickstart would be needed to be able to tell what goes > wrong > >> there. > >> > > > > Thanks for looking, I thought you'd say that. > > Attached is a quick (ish) start. > > > > browse to > > https://localhost:/redirect/protected/path/pageA/112233 > > Press the button *boom* > > > > Removing the WebSocketBehavior on BasePage makes the page work > > (Although in a real app I need this behavior) > > > > Would it be helpful if I created this on github? > > > > > > > Sorry for the noise. > > I've just tried this on Wicket 7.7 and it seems to be fixed already. > WICKET-6342 > Sorry for the breakage! That was indeed a silly mistake! > > I don't know what's more embarrassing. Posting a dumb bug report or > spending days trying to narrow down the bug. > Now to upgrade my main app *fingers crossed* > > > -- > Peter Henderson >
Re: Websocket redirect wrong url
On 24 May 2017 at 11:05, Peter Henderson wrote: > > > On 23 May 2017 at 22:24, Martin Grigorov wrote: > >> Hi, >> >> I'm afraid a quickstart would be needed to be able to tell what goes wrong >> there. >> > > Thanks for looking, I thought you'd say that. > Attached is a quick (ish) start. > > browse to > https://localhost:/redirect/protected/path/pageA/112233 > Press the button *boom* > > Removing the WebSocketBehavior on BasePage makes the page work > (Although in a real app I need this behavior) > > Would it be helpful if I created this on github? > Sorry for the noise. I've just tried this on Wicket 7.7 and it seems to be fixed already. WICKET-6342 I don't know what's more embarrassing. Posting a dumb bug report or spending days trying to narrow down the bug. Now to upgrade my main app *fingers crossed* -- Peter Henderson
Re: Websocket redirect wrong url
On 23 May 2017 at 22:24, Martin Grigorov wrote: > Hi, > > I'm afraid a quickstart would be needed to be able to tell what goes wrong > there. > Thanks for looking, I thought you'd say that. Attached is a quick (ish) start. browse to https://localhost:/redirect/protected/path/pageA/112233 Press the button *boom* Removing the WebSocketBehavior on BasePage makes the page work (Although in a real app I need this behavior) Would it be helpful if I created this on github? > > The appearance of /wicket/ in the url looks like either BookmarkableMapper > (responsible for urls like /wicket/bookmarkable/com.example.Page) or > PageInstanceMapper (responsible for urls like /wicket/page?123) is used > instead of MountedMapper (used when the page path is configured with > WebApplication#mountPage(String, Class) method). > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, May 23, 2017 at 2:46 PM, Peter Henderson < > peter.hender...@starjar.com> wrote: > > > Hi all. > > > > > > I'm seeing a strange redirect problem which leads to a 404 > > > > > > Scenario. > > 1) User is on fat bookmarkable page [1] > > 2) Ajax onClick redirects to non bookmarkable SendMessagePage > > 3) SendMessage page uses websockets + background threads. > > 4) SendMessage page receives a websocket push event which it responds to > > with [2] or [3] > > > > When redirecting back to a really simple DummyPage all is fine. > > When redirecting back to the fat bookmarkable page I get a 404 on url > > https://local.starjar.com:25000/Starjar/protected/wicket/35883 > > > > Both DummyPage and PurchaseOrderPage are mounted the same way. > > > > > > > > What am I doing which is causing the incorrect redirect path? > > > > > > I'm (still) trying to build a quick start that reproduces this problem. > > > > > > Further testing. > > > > I created a new class called Dummy2 which is identical to > > PurchaseOrderPage. Just a different name and mount point. > > Redirecting to Dummy2 works fine . > > > > It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage > > both fail with the incorrect relative url. > > > > > > > > > > Many thanks > > > > Peter. > > > > > > > > > > > > [1] > > https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883 > > > > [2] > > // This works as expected > > // https://local.starjar.com:25000/Starjar/protected/dummy/12334 > > val pageCls = classOf[DummyDetailPage] > > val pp = new PageParameters() > > pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334) > > throw new RestartResponseException(pageCls, pp) > > > > > > [3] > > // This does not work 404 > > // https://local.starjar.com:25000/Starjar/protected/wicket/35883 > > val pageCls = classOf[PurchaseOrderDetailPage] > > val pp = new PageParameters() > > pp.set(WicketStarjarApplication.DetailPageIdParameterName, > businessId.pk) > > throw new RestartResponseException(pageCls, pp) > > > > > > > > -- > > Peter Henderson > > > -- Peter Henderson Director Starjar Ltd. www.starjar.com 0330 088 1662 redirect.tar.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Websocket redirect wrong url
Hi, I'm afraid a quickstart would be needed to be able to tell what goes wrong there. The appearance of /wicket/ in the url looks like either BookmarkableMapper (responsible for urls like /wicket/bookmarkable/com.example.Page) or PageInstanceMapper (responsible for urls like /wicket/page?123) is used instead of MountedMapper (used when the page path is configured with WebApplication#mountPage(String, Class) method). Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, May 23, 2017 at 2:46 PM, Peter Henderson < peter.hender...@starjar.com> wrote: > Hi all. > > > I'm seeing a strange redirect problem which leads to a 404 > > > Scenario. > 1) User is on fat bookmarkable page [1] > 2) Ajax onClick redirects to non bookmarkable SendMessagePage > 3) SendMessage page uses websockets + background threads. > 4) SendMessage page receives a websocket push event which it responds to > with [2] or [3] > > When redirecting back to a really simple DummyPage all is fine. > When redirecting back to the fat bookmarkable page I get a 404 on url > https://local.starjar.com:25000/Starjar/protected/wicket/35883 > > Both DummyPage and PurchaseOrderPage are mounted the same way. > > > > What am I doing which is causing the incorrect redirect path? > > > I'm (still) trying to build a quick start that reproduces this problem. > > > Further testing. > > I created a new class called Dummy2 which is identical to > PurchaseOrderPage. Just a different name and mount point. > Redirecting to Dummy2 works fine . > > It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage > both fail with the incorrect relative url. > > > > > Many thanks > > Peter. > > > > > > [1] > https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883 > > [2] > // This works as expected > // https://local.starjar.com:25000/Starjar/protected/dummy/12334 > val pageCls = classOf[DummyDetailPage] > val pp = new PageParameters() > pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334) > throw new RestartResponseException(pageCls, pp) > > > [3] > // This does not work 404 > // https://local.starjar.com:25000/Starjar/protected/wicket/35883 > val pageCls = classOf[PurchaseOrderDetailPage] > val pp = new PageParameters() > pp.set(WicketStarjarApplication.DetailPageIdParameterName, businessId.pk) > throw new RestartResponseException(pageCls, pp) > > > > -- > Peter Henderson >
Websocket redirect wrong url
Hi all. I'm seeing a strange redirect problem which leads to a 404 Scenario. 1) User is on fat bookmarkable page [1] 2) Ajax onClick redirects to non bookmarkable SendMessagePage 3) SendMessage page uses websockets + background threads. 4) SendMessage page receives a websocket push event which it responds to with [2] or [3] When redirecting back to a really simple DummyPage all is fine. When redirecting back to the fat bookmarkable page I get a 404 on url https://local.starjar.com:25000/Starjar/protected/wicket/35883 Both DummyPage and PurchaseOrderPage are mounted the same way. What am I doing which is causing the incorrect redirect path? I'm (still) trying to build a quick start that reproduces this problem. Further testing. I created a new class called Dummy2 which is identical to PurchaseOrderPage. Just a different name and mount point. Redirecting to Dummy2 works fine . It looks like Dummy2 => Dummy2 and PurchaseOrderPage => PurchaseOrderPage both fail with the incorrect relative url. Many thanks Peter. [1] https://local.starjar.com:25000/Starjar/protected/purchaseOrder/35883 [2] // This works as expected // https://local.starjar.com:25000/Starjar/protected/dummy/12334 val pageCls = classOf[DummyDetailPage] val pp = new PageParameters() pp.set(WicketStarjarApplication.DetailPageIdParameterName, 12334) throw new RestartResponseException(pageCls, pp) [3] // This does not work 404 // https://local.starjar.com:25000/Starjar/protected/wicket/35883 val pageCls = classOf[PurchaseOrderDetailPage] val pp = new PageParameters() pp.set(WicketStarjarApplication.DetailPageIdParameterName, businessId.pk) throw new RestartResponseException(pageCls, pp) -- Peter Henderson
Re: Question about ajax encoding/decoding, problem with image data url
My bad. Problem solved, accidentally this part of code was within a block of markup text where all whitespace was replaced with non breaking space. Nbsp looks the same for naked eye but a diff tool shows the difference, and obviously browser will render differently compared to https://twitter.com/mtgrigorov >>> >>> On Wed, May 3, 2017 at 4:11 PM, Martin Makundi < >>> martin.maku...@koodaripalvelut.com> wrote: >>> >>> > Here is a sample how it works in jsfiddle without problems: >>> > https://jsfiddle.net/#&togetherjs=0SQvHmm6Nj >>> > >>> > But when same content is in ajax update it breaks. Wonder what happens >>> to >>> > it before render? >>> > >>> > 2017-05-03 16:06 GMT+03:00 Martin Makundi < >>> > martin.maku...@koodaripalvelut.com>: >>> > >>> > > Hi! >>> > > >>> > > I am trying to display (wicket 1.4) an image using base64 image data >>> > > representation. >>> > > >>> > > For some reason the base64 gets garbled every time with ajax. >>> > > >>> > > For example: >>> > > >>> > > src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAA >>> > > CWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/ >>> > > BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESY >>> > > kSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen >>> > > >>> > > becomes (as viewed from firefox developer tools) >>> > > >> > > bcm5banrmiwxilcwgivil3hhc8cuybe+wfcagjwdgt8mi2xjeyja0kgysjmesy >>> > ksxlsmxhk0v1r6dpvff09h="" >>> > > jzwmhattvvae7xfnqfoen... >>> > > >>> > > You can notice lots of ="" marks ="" splitting the string. >>> > > >>> > > >>> > > Is this a wicket encoding issue or a javascript quirk? >>> > > >>> > > Thanks. >>> > > >>> > > ** >>> > > Martin >>> > > >>> > > >>> > >>> >> >> >
Re: Question about ajax encoding/decoding, problem with image data url
Really strange, works on same installation in simpler installation. No difference in http traffic... 2017-05-03 18:07 GMT+03:00 Martin Makundi < martin.maku...@koodaripalvelut.com>: > Interesting, it works in a quickstart also on v1.4. > > Need to investigate more. > > 2017-05-03 17:20 GMT+03:00 Martin Grigorov : > >> I don't see any reason why this could break. >> If you are able to reproduce it in a quickstart with 6.26/7.6 then please >> create a ticket in JIRA. >> >> Check what is in the Ajax response, not what is in the DOM. >> Also you can check with Google Chrome. Maybe Firefox does something funky. >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Wed, May 3, 2017 at 4:11 PM, Martin Makundi < >> martin.maku...@koodaripalvelut.com> wrote: >> >> > Here is a sample how it works in jsfiddle without problems: >> > https://jsfiddle.net/#&togetherjs=0SQvHmm6Nj >> > >> > But when same content is in ajax update it breaks. Wonder what happens >> to >> > it before render? >> > >> > 2017-05-03 16:06 GMT+03:00 Martin Makundi < >> > martin.maku...@koodaripalvelut.com>: >> > >> > > Hi! >> > > >> > > I am trying to display (wicket 1.4) an image using base64 image data >> > > representation. >> > > >> > > For some reason the base64 gets garbled every time with ajax. >> > > >> > > For example: >> > > >> > > src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAA >> > > CWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/ >> > > BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESY >> > > kSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen >> > > >> > > becomes (as viewed from firefox developer tools) >> > > > > > bcm5banrmiwxilcwgivil3hhc8cuybe+wfcagjwdgt8mi2xjeyja0kgysjmesy >> > ksxlsmxhk0v1r6dpvff09h="" >> > > jzwmhattvvae7xfnqfoen... >> > > >> > > You can notice lots of ="" marks ="" splitting the string. >> > > >> > > >> > > Is this a wicket encoding issue or a javascript quirk? >> > > >> > > Thanks. >> > > >> > > ** >> > > Martin >> > > >> > > >> > >> > >
Re: Question about ajax encoding/decoding, problem with image data url
Interesting, it works in a quickstart also on v1.4. Need to investigate more. 2017-05-03 17:20 GMT+03:00 Martin Grigorov : > I don't see any reason why this could break. > If you are able to reproduce it in a quickstart with 6.26/7.6 then please > create a ticket in JIRA. > > Check what is in the Ajax response, not what is in the DOM. > Also you can check with Google Chrome. Maybe Firefox does something funky. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, May 3, 2017 at 4:11 PM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > > > Here is a sample how it works in jsfiddle without problems: > > https://jsfiddle.net/#&togetherjs=0SQvHmm6Nj > > > > But when same content is in ajax update it breaks. Wonder what happens to > > it before render? > > > > 2017-05-03 16:06 GMT+03:00 Martin Makundi < > > martin.maku...@koodaripalvelut.com>: > > > > > Hi! > > > > > > I am trying to display (wicket 1.4) an image using base64 image data > > > representation. > > > > > > For some reason the base64 gets garbled every time with ajax. > > > > > > For example: > > > > > > src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAA > > > CWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/ > > > BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESY > > > kSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen > > > > > > becomes (as viewed from firefox developer tools) > > > > > bcm5banrmiwxilcwgivil3hhc8cuybe+wfcagjwdgt8mi2xjeyja0kgysjmesy > > ksxlsmxhk0v1r6dpvff09h="" > > > jzwmhattvvae7xfnqfoen... > > > > > > You can notice lots of ="" marks ="" splitting the string. > > > > > > > > > Is this a wicket encoding issue or a javascript quirk? > > > > > > Thanks. > > > > > > ** > > > Martin > > > > > > > > >
Re: Question about ajax encoding/decoding, problem with image data url
I don't see any reason why this could break. If you are able to reproduce it in a quickstart with 6.26/7.6 then please create a ticket in JIRA. Check what is in the Ajax response, not what is in the DOM. Also you can check with Google Chrome. Maybe Firefox does something funky. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, May 3, 2017 at 4:11 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Here is a sample how it works in jsfiddle without problems: > https://jsfiddle.net/#&togetherjs=0SQvHmm6Nj > > But when same content is in ajax update it breaks. Wonder what happens to > it before render? > > 2017-05-03 16:06 GMT+03:00 Martin Makundi < > martin.maku...@koodaripalvelut.com>: > > > Hi! > > > > I am trying to display (wicket 1.4) an image using base64 image data > > representation. > > > > For some reason the base64 gets garbled every time with ajax. > > > > For example: > > > > src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAA > > CWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/ > > BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESY > > kSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen > > > > becomes (as viewed from firefox developer tools) > > > bcm5banrmiwxilcwgivil3hhc8cuybe+wfcagjwdgt8mi2xjeyja0kgysjmesy > ksxlsmxhk0v1r6dpvff09h="" > > jzwmhattvvae7xfnqfoen... > > > > You can notice lots of ="" marks ="" splitting the string. > > > > > > Is this a wicket encoding issue or a javascript quirk? > > > > Thanks. > > > > ** > > Martin > > > > >
Re: Question about ajax encoding/decoding, problem with image data url
Here is a sample how it works in jsfiddle without problems: https://jsfiddle.net/#&togetherjs=0SQvHmm6Nj But when same content is in ajax update it breaks. Wonder what happens to it before render? 2017-05-03 16:06 GMT+03:00 Martin Makundi < martin.maku...@koodaripalvelut.com>: > Hi! > > I am trying to display (wicket 1.4) an image using base64 image data > representation. > > For some reason the base64 gets garbled every time with ajax. > > For example: > > src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAA > CWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/ > BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESY > kSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen > > becomes (as viewed from firefox developer tools) > bcm5banrmiwxilcwgivil3hhc8cuybe+wfcagjwdgt8mi2xjeyja0kgysjmesyksxlsmxhk0v1r6dpvff09h="" > jzwmhattvvae7xfnqfoen... > > You can notice lots of ="" marks ="" splitting the string. > > > Is this a wicket encoding issue or a javascript quirk? > > Thanks. > > ** > Martin > >
Question about ajax encoding/decoding, problem with image data url
Hi! I am trying to display (wicket 1.4) an image using base64 image data representation. For some reason the base64 gets garbled every time with ajax. For example: src="data:image/png;base64,iVBORw0KGgoNSUhEUgAAAcIAAACWCAYAAABNcIgQAAAKUklEQVR4nO3dzYoc1xkG4PcS+g5cVxDmAmzoC/BCm5BANrMIWXilCwgIvIl3hhC8CUYbe+WFcAgJWdgT8MI2xjEYjA0KGYSjmESYkSxLsmXHk0V1R6dPVff09H/JzwMHaTTVVae7xfnqfOen becomes (as viewed from firefox developer tools)
Re: Catch-all URL mapping logic
On Mon, Apr 3, 2017 at 10:49 PM, Andreas Lundblad < andreas.lundb...@gmail.com> wrote: > Excellent. Big thanks! (For any future reader, I needed to wrap the page in > a PageProvider in the return statement.) > Great! I've added few convinience constructors to RenderPageRequestHandler in Wicket 8.x! > > I also managed to render nice corresponding URLs for > BookmarkablePageRequestHandler in the mapHandler method. > > I then used the code posted at [1] to avoid redirects and keep the pretty > URLs in the address bar. > > [1] http://stackoverflow.com/a/27827875/276052 > > > On Mon, Apr 3, 2017 at 9:02 AM, Martin Grigorov > wrote: > > > Hi, > > > > You can use a custom root request mapper! > > > > In YourApplication#init(): > > old = application.getRootRequestMapper() > > application.setRootRequestMapper(new CustomRequestMapper(old)) > > > > In CustomRequestMapper#mapRequest() first use 'old' to try to return > > IRequestHandler. If it returns null then use request.getUrl() and > > request#getQueryParameters() to try to find a product in your DB. > > If you have a match then return RenderPageRequestHandler(new > > ProductPage(product)) > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Sun, Apr 2, 2017 at 10:19 AM, Andreas Lundblad < > > andreas.lundb...@gmail.com> wrote: > > > > > Searched like crazy without finding any documentation on this... > > > > > > I would like to maintain functionality of all my currently mounted > pages > > > and resources. > > > > > > In addition to this, I would like to have a "catch all" mapping logic > > that > > > picks up urls like > > > > > > http://www.example.com/product-A.html > > > http://www.example.com/product-B.html > > > ... > > > > > > And if my logic doesn't find "product-X" in the database, it should > fall > > > through to the 404-page. > > > > > > Some products gets mapped to ProductPage.class, others get mapped to > > > OtherProductPage.class. > > > > > > Further more I would like these links to be bookmarkable, and that > > > parameters gets appended with the usual ?foo=bar > > > > > > I'm on Wicket 6.24. > > > > > > cheers, > > > Andreas Lundblad > > > > > >
Re: Catch-all URL mapping logic
Excellent. Big thanks! (For any future reader, I needed to wrap the page in a PageProvider in the return statement.) I also managed to render nice corresponding URLs for BookmarkablePageRequestHandler in the mapHandler method. I then used the code posted at [1] to avoid redirects and keep the pretty URLs in the address bar. [1] http://stackoverflow.com/a/27827875/276052 On Mon, Apr 3, 2017 at 9:02 AM, Martin Grigorov wrote: > Hi, > > You can use a custom root request mapper! > > In YourApplication#init(): > old = application.getRootRequestMapper() > application.setRootRequestMapper(new CustomRequestMapper(old)) > > In CustomRequestMapper#mapRequest() first use 'old' to try to return > IRequestHandler. If it returns null then use request.getUrl() and > request#getQueryParameters() to try to find a product in your DB. > If you have a match then return RenderPageRequestHandler(new > ProductPage(product)) > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Sun, Apr 2, 2017 at 10:19 AM, Andreas Lundblad < > andreas.lundb...@gmail.com> wrote: > > > Searched like crazy without finding any documentation on this... > > > > I would like to maintain functionality of all my currently mounted pages > > and resources. > > > > In addition to this, I would like to have a "catch all" mapping logic > that > > picks up urls like > > > > http://www.example.com/product-A.html > > http://www.example.com/product-B.html > > ... > > > > And if my logic doesn't find "product-X" in the database, it should fall > > through to the 404-page. > > > > Some products gets mapped to ProductPage.class, others get mapped to > > OtherProductPage.class. > > > > Further more I would like these links to be bookmarkable, and that > > parameters gets appended with the usual ?foo=bar > > > > I'm on Wicket 6.24. > > > > cheers, > > Andreas Lundblad > > >
Re: Catch-all URL mapping logic
Hi, You can use a custom root request mapper! In YourApplication#init(): old = application.getRootRequestMapper() application.setRootRequestMapper(new CustomRequestMapper(old)) In CustomRequestMapper#mapRequest() first use 'old' to try to return IRequestHandler. If it returns null then use request.getUrl() and request#getQueryParameters() to try to find a product in your DB. If you have a match then return RenderPageRequestHandler(new ProductPage(product)) Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sun, Apr 2, 2017 at 10:19 AM, Andreas Lundblad < andreas.lundb...@gmail.com> wrote: > Searched like crazy without finding any documentation on this... > > I would like to maintain functionality of all my currently mounted pages > and resources. > > In addition to this, I would like to have a "catch all" mapping logic that > picks up urls like > > http://www.example.com/product-A.html > http://www.example.com/product-B.html > ... > > And if my logic doesn't find "product-X" in the database, it should fall > through to the 404-page. > > Some products gets mapped to ProductPage.class, others get mapped to > OtherProductPage.class. > > Further more I would like these links to be bookmarkable, and that > parameters gets appended with the usual ?foo=bar > > I'm on Wicket 6.24. > > cheers, > Andreas Lundblad >
Catch-all URL mapping logic
Searched like crazy without finding any documentation on this... I would like to maintain functionality of all my currently mounted pages and resources. In addition to this, I would like to have a "catch all" mapping logic that picks up urls like http://www.example.com/product-A.html http://www.example.com/product-B.html ... And if my logic doesn't find "product-X" in the database, it should fall through to the 404-page. Some products gets mapped to ProductPage.class, others get mapped to OtherProductPage.class. Further more I would like these links to be bookmarkable, and that parameters gets appended with the usual ?foo=bar I'm on Wicket 6.24. cheers, Andreas Lundblad
Re: Kendo UI - How to programmatically select node from URL parameter
OK, many thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Kendo-UI-How-to-programmatically-select-node-from-URL-parameter-tp4677457p4677459.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Kendo UI - How to programmatically select node from URL parameter
Hi Manfred, I guess you have to add the statement [1] yourself in #renderHead with response.render(OnDomReadyHeaderItem.forScript(statement)); [1] https://github.com/sebfz1/wicket-jquery-ui/blob/master/wicket-kendo-ui/src/main/java/com/googlecode/wicket/kendo/ui/widget/treeview/AjaxTreeView.java#L112 Best regards, Sebastien. On Mon, Mar 27, 2017 at 9:10 AM, Manfred Bergmann wrote: > Hi. > > Any idea how that could be accomplished? > It seems the tree nodes are actually not fully rendered yet in > onInitialize/onConfigure. > > > Manfred > > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Kendo-UI-How-to-programmatically-select-node- > from-URL-parameter-tp4677457.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Kendo UI - How to programmatically select node from URL parameter
Hi. Any idea how that could be accomplished? It seems the tree nodes are actually not fully rendered yet in onInitialize/onConfigure. Manfred -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Kendo-UI-How-to-programmatically-select-node-from-URL-parameter-tp4677457.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicketstuff UrlFragment - modifying URL calls onParameterArrival
Hello, I guess you are in following situation: as soon as you calling putParameter URL hash value is changes as soon as hash is modified you receiving onParameterArrival We are using following method (seems to work wihout extra onParameterArrival) UrlFragment uf = new UrlFragment(handler); uf.set(f.getArea().name(), f.getType()); Where handler is IPartialPageRequestHandler from ajax call On Mon, Mar 13, 2017 at 9:31 PM, Manfred Bergmann wrote: > Hi. > > I'm using UrlFragment Wicketstuff project to manipulate the URL. > When manipulating the URL via putParameter() call, etc. there is an > immediate callback to the page which implements onParameterArrival() > handler. > > Can this be avoided somehow? > I'd just like to have this handler being called when someone enters an URL > manually in the browser but not when manipulating the URL via code. > > > Manfred > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-UrlFragment-modifying-URL-calls-onParameterArrival-tp4677302.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- WBR Maxim aka solomax - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
I'll try that. Thanks guys. Have opened issue on GitHub. Manfred -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Kendo-UI-ToolbarButton-renders-href-which-removes-existing-URL-fragment-tp4677304p4677312.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
Hi Manfred, Hi Martin, Unfortunately this part does not rely on the integration but on kendo-ui itself, so I'm afraid we have to hack a bit :( Changing the href attribute should be done when data are loaded, the idea is to identify buttons with a special css class and update the href on databound event. Something like that: private CommandButton btnEdit = new CommandButton("_edit", Model.of("Edit")) { private static final long serialVersionUID = 1L; @Override public String getCSSClass() { return "link-to-change"; } }; class MyDataTable { protected void onInitialize() { super.onInitialize(); this.add(new DataBoundBehavior() { private static final long serialVersionUID = 1L; @Override protected String getDataBoundCallback() { return "function (e) { " + "jQuery('.link-to-change').each(" + "function(index, item) { " + "jQuery(item).attr('href', 'javascript:;'); " + "}" + ")" + "}"; } }); } } There should be a way to have a generic Behavior, like NoHashSymbolOnButtonsDataBoundBehavior (yes, I'm pretty imaginative tonight) Please open en issue on github :) Best regards, Sebastien.
Re: Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
On Mon, Mar 13, 2017 at 6:21 PM, Manfred Bergmann wrote: > Martin Grigorov-4 wrote > > If Wicket-JQuery-UI adds this "#" then I'd recommend to replace it with > > href="javascript:;". Some prefer "javascript:void(0)" but this is a bit > > longer. > > "#" has such side effects. > > OK, how would I do that. Via AttributeModifier? Because it doesn't seem to > be rendered during the component render phase. > You'll have to find who generates this piece of code - KendoUI or Wicket-JQuery-UI. I've found just https://github.com/sebfz1/wicket-jquery-ui/blob/ab7d16751b728aeb6a6652f7554861bdff743b54/wicket-kendo-ui/src/main/java/com/googlecode/wicket/kendo/ui/widget/menu/Menu.html#L41 in Wicket-JQuery-UI, so it might be KendoUI. > > > Manfred > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Kendo-UI-ToolbarButton-renders-href- > which-removes-existing-URL-fragment-tp4677304p4677308.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
Martin Grigorov-4 wrote > If Wicket-JQuery-UI adds this "#" then I'd recommend to replace it with > href="javascript:;". Some prefer "javascript:void(0)" but this is a bit > longer. > "#" has such side effects. OK, how would I do that. Via AttributeModifier? Because it doesn't seem to be rendered during the component render phase. Manfred -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Kendo-UI-ToolbarButton-renders-href-which-removes-existing-URL-fragment-tp4677304p4677308.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
Hi, On Mon, Mar 13, 2017 at 5:37 PM, Manfred Bergmann wrote: > Hi. > > The DataTable component has Toolbar-/CommandButtons which seem to be > rendered (by JavaScript) like this: > Button name <#> > > The href="#" causes a problem because once the button is clicked it deletes > the existing URL fragment which must be kept intact. > > What could be done to remove the href="#", since it seems to be rendered > after onDomReady or so? > If Wicket-JQuery-UI adds this "#" then I'd recommend to replace it with href="javascript:;". Some prefer "javascript:void(0)" but this is a bit longer. "#" has such side effects. > > > Manfred > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/Kendo-UI-ToolbarButton-renders-href- > which-removes-existing-URL-fragment-tp4677304.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Kendo UI - ToolbarButton renders href="#" which removes existing URL fragment
Hi. The DataTable component has Toolbar-/CommandButtons which seem to be rendered (by JavaScript) like this: Button name <#> The href="#" causes a problem because once the button is clicked it deletes the existing URL fragment which must be kept intact. What could be done to remove the href="#", since it seems to be rendered after onDomReady or so? Manfred -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Kendo-UI-ToolbarButton-renders-href-which-removes-existing-URL-fragment-tp4677304.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicketstuff UrlFragment - modifying URL calls onParameterArrival
Hi. I'm using UrlFragment Wicketstuff project to manipulate the URL. When manipulating the URL via putParameter() call, etc. there is an immediate callback to the page which implements onParameterArrival() handler. Can this be avoided somehow? I'd just like to have this handler being called when someone enters an URL manually in the browser but not when manipulating the URL via code. Manfred -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicketstuff-UrlFragment-modifying-URL-calls-onParameterArrival-tp4677302.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: POST request shows the parameters in the URL of result page
Actually, we are calling the UserDetailPage.java from HomePage.java. UserDetailPage.java contains the instantiation of UserForm.java which extends the Wicket Form class. This UserForm.java stores the post parameters into a model object and retrieves back whenever it is needed. HomePage.java -- public HomePage(final PageParameters parameters) { super(parameters); String lastName = getParameterValue("sn", parameters, postParams); String firstName = getParameterValue("givenname", parameters, postParams); String commonName = getParameterValue("cn", parameters, postParams); PageParameters pp = new PageParameters(); pp.add("lastName", lastName); pp.add("firstName", firstName); pp.add("commonName", commonName); throw new RestartResponseException(UserDetailPage.class, pp); } UserDetailPage.java --- public UserDetailPage(final PageParameters parameters) { String lastName = parameters.get("lastName").toString(); String firstName = parameters.get("firstName").toString(); String commonName = parameters.get("commonName").toString(); String email = parameters.get("email").toString(); add(userForm); } UserForm.java -- public UserForm(String id, PageParameters parameters) { super(id); String typeFlagValue = "COMMON"; if (parameters != null) { this.localeStr = parameters.get("localeStr").toString(); this.userDN = parameters.get("parentDN").toString(); this.userName = parameters.get("commonName").toString(); this.firstName = parameters.get("firstName").toString(); this.lastName = parameters.get("lastName").toString(); } User user = new User(); CompoundPropertyModel userModel = new CompoundPropertyModel(user); setDefaultModel(userModel); I understood the calling procedure for html, I will try this option and update the status. Thanks Senthil -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/POST-request-shows-the-parameters-in-the-URL-of-result-page-tp4675323p4675343.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: POST request shows the parameters in the URL of result page
Hi, Sorry, but you are giving us partial information and it is hard for us to guess what you are doing there. It is still not clear how you use UserForm and whether you really need it. >From your previous email I understood that you want to submit a form in HomePage and get its data in UserDetails without polluting the url with query string parameters and still keeping your pages stateless. Is this correct ? It it is then remove UserForm completely and in HomePage.html use normal HTML (i.e. no wicket:id): Submittting this form will send its data directly to UserDetails page (if it is mounted at /user/details !). There you have to use getRequest().getPostParameters() to read the submitted data, because PageParameters is only for GET requests. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Aug 19, 2016 at 11:14 AM, senlog80 wrote: > Thanks Martin.. > > Could you provide a sample code if possible or any reference for calling > the > html instead of wicket Form > > Is it like the following statement has to be replaced from HomePage.java to > HomePage.html > "throw new RestartResponseException(UserDetailPage.class, pp);" --> action="/user/details" method="POST"> > > Actually, the class "UserForm extends Form" and it has the code for setting > and retrieving the data in model object. In this class only, we have > written the code for OnSubmit() functionality for modify button. > > We have HomePage.java / HomePage.html and UserDetailPage.java / > UserDetailPage.html > > Please let me know if there is any sample code. > > Thanks > Senthil > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/POST-request-shows-the-parameters-in-the-URL-of-result-page- > tp4675323p4675340.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: POST request shows the parameters in the URL of result page
Thanks Martin.. Could you provide a sample code if possible or any reference for calling the html instead of wicket Form Is it like the following statement has to be replaced from HomePage.java to HomePage.html "throw new RestartResponseException(UserDetailPage.class, pp);" --> Actually, the class "UserForm extends Form" and it has the code for setting and retrieving the data in model object. In this class only, we have written the code for OnSubmit() functionality for modify button. We have HomePage.java / HomePage.html and UserDetailPage.java / UserDetailPage.html Please let me know if there is any sample code. Thanks Senthil -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/POST-request-shows-the-parameters-in-the-URL-of-result-page-tp4675323p4675340.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: POST request shows the parameters in the URL of result page
Hi, On Wed, Aug 17, 2016 at 2:58 PM, senlog80 wrote: > I have a form on my page, which when submitted goes the next page, but all > the form's fields appear as URL parameters in the resulting page. I want > to > hide all the parameters in the url, so that I am using POST request but > still it shows the parameters in the resulting page. > > My sample code > --- > HomePage.java > -- > PageParameters pp = new PageParameters(); > pp.add("lastName", lastName); > pp.add("firstName", firstName); > pp.add("commonName", commonName); > pp.add("localeStr", localeStr); > throw new RestartResponseException(UserDetailPage.class, pp); > The form submit POST request ends here. >From now on a new GET request is issued with url like /user/details?lastName=last&firstName=first... > > UserDetailPage > > public UserDetailPage(final PageParameters parameters) { > String lastName = parameters.get("lastName").toString(); > String firstName = parameters.get("firstName").toString(); > String commonName = parameters.get("commonName"). > toString(); > userForm = new UserForm("modifyForm", parameters); > add(userForm); > > UserForm.java > > public UserForm(String id, PageParameters parameters) { > super(id); > String typeFlagValue = "COMMON"; > if (parameters != null) > { > this.localeStr = parameters.get("localeStr"). > toString(); > this.userDN = parameters.get("parentDN"). > toString(); > this.userName = parameters.get("commonName"). > toString(); > this.firstName = parameters.get("firstName"). > toString(); > this.lastName = parameters.get("lastName"). > toString(); > } > > Actually, From the HomePage.java, the request parameters are passed to > UserDetailPage.java. This UserDetailPage.java takes the reference Userform > and shows the result in the GUI. > > So, the page parameters lastName, firstName, commonName, etc.. are shown in > the URL of result page. > We are using Bookmarakable Page. > > If I use the "throw new RestartResponseException(new UserDetailPage(pp));" > instead of "throw new RestartResponseException(UserDetailPage.class, pp);" > in HomePage.java then the URL hides the parameters in the URL. But I think > this is stateful. Is it ok?? > IMO the best for your use case if to not use Wicket Form at all in HomePage. Use a normal HTML form: . This will go directly to UserDetailsPage where you can read the parameters with getRequest().getPostParameters() > > Could you provide the suggestions.. > > -- > View this message in context: http://apache-wicket.1842946. > n4.nabble.com/POST-request-shows-the-parameters-in-the- > URL-of-result-page-tp4675323.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
POST request shows the parameters in the URL of result page
I have a form on my page, which when submitted goes the next page, but all the form's fields appear as URL parameters in the resulting page. I want to hide all the parameters in the url, so that I am using POST request but still it shows the parameters in the resulting page. My sample code --- HomePage.java -- PageParameters pp = new PageParameters(); pp.add("lastName", lastName); pp.add("firstName", firstName); pp.add("commonName", commonName); pp.add("localeStr", localeStr); throw new RestartResponseException(UserDetailPage.class, pp); UserDetailPage public UserDetailPage(final PageParameters parameters) { String lastName = parameters.get("lastName").toString(); String firstName = parameters.get("firstName").toString(); String commonName = parameters.get("commonName").toString(); userForm = new UserForm("modifyForm", parameters); add(userForm); UserForm.java public UserForm(String id, PageParameters parameters) { super(id); String typeFlagValue = "COMMON"; if (parameters != null) { this.localeStr = parameters.get("localeStr").toString(); this.userDN = parameters.get("parentDN").toString(); this.userName = parameters.get("commonName").toString(); this.firstName = parameters.get("firstName").toString(); this.lastName = parameters.get("lastName").toString(); } Actually, From the HomePage.java, the request parameters are passed to UserDetailPage.java. This UserDetailPage.java takes the reference Userform and shows the result in the GUI. So, the page parameters lastName, firstName, commonName, etc.. are shown in the URL of result page. We are using Bookmarakable Page. If I use the "throw new RestartResponseException(new UserDetailPage(pp));" instead of "throw new RestartResponseException(UserDetailPage.class, pp);" in HomePage.java then the URL hides the parameters in the URL. But I think this is stateful. Is it ok?? Could you provide the suggestions.. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/POST-request-shows-the-parameters-in-the-URL-of-result-page-tp4675323.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 6 IRequestMapper customization for mount path which is not the first url segment
Hi Marin, Thanks for replying. I've checked the CryptoMapper and the concept of compound mapper. For the compound mapper, it is hard for me to validate my keywords which actually has no format(e.g. count, prefixes, wordings, length...etc). After further testing, I am going to use the MountedMapper : new MountedMapper("/#{keyword}/#{keyword2}/#{keyword3}/" + mountPath, mountPathPageClass) It works fine as long as the number of keyword does not exist 3. Regards. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-IRequestMapper-customization-for-mount-path-which-is-not-the-first-url-segment-tp4675063p4675086.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 6 IRequestMapper customization for mount path which is not the first url segment
Hi, I think the best way would be to create a compound mapper, like CryptoMapper, that cares about the keyword segments. If the first segments are valid keywords then pass the rest of the url to the MountedMappers. It is very similar to CryptoMapper - if the url is successfully decrypted then it is passed to the inner list of IRequestMappers. On Jul 8, 2016 12:37 PM, "fatfennec" wrote: > Hi All, > > I am new to wicket. I am migrating my wicket 1.4 project to >wicket 1.5 > (wicket 6.23.0). > > IRequestTargetUrlCodingStrategy interface and all its implementations are > replaced with the IRequestMapper and its respective implementations. ref : > https://cwiki.apache.org/confluence/display/WICKET/Request+mapping > > In wicket, the mount path is assumed to be the first element after the > domain. > e.g. http://www.mydomain.com/mountpath.html/parameters > However, my site's URLs are not. They are something like > http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters > In wicket 1.4, I am using the > > org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.matches(String, > boolean) to match the mount path by 'contains' instead of 'startWiths'. > Everything is working fine. > > In wicket 6.23.0, I find that there is a suggested MountedMapper to replace > the old BookmarkablePageRequestTargetUrlCodingStrategy. > I am going to do some tricks in > > org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.parseRequest(Request) > and > > org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getCompatibilityScore(Request) > After applying the tricks in AbstractBookmarkableMapper, it works fine now. > it is a right direction for me to customize the MountedMapper to suit my > needs? > > I also find a similar case in > http://apache-wicket.1842946.n4.nabble.com/Mounting-pages-td4652091.html > I check the CryptoMapper and HttpsMapper. It seems that they are not what I > need. > By doing > mount(new MountedMapper("/#{keyword}/#{keyword2}/#{keyword3}/" + mountPath, > mountPathPageClass)); > I dont not need to do the tricks. It seems to be working fine as well. > But when the count of {keyword}s in URL exceeds three, it cannot find the > page. > > > There is another question about the Mapper in wicket 6.23.0. > After the > > org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapRequest(Request), > my /keyword1/keywordN/ is removed because of the URL recreation by > org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.UrlInfo. > The result URL becomes http://www.mydomain.com/mountpath.html/parameters > again. > > But I would like to keep my URL as > http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters > after > matching. Is there any way for my to customize the mapper for this case? > > Many thanks for reading and helping! > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-6-IRequestMapper-customization-for-mount-path-which-is-not-the-first-url-segment-tp4675063.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Wicket 6 IRequestMapper customization for mount path which is not the first url segment
Hi All, I am new to wicket. I am migrating my wicket 1.4 project to >wicket 1.5 (wicket 6.23.0). IRequestTargetUrlCodingStrategy interface and all its implementations are replaced with the IRequestMapper and its respective implementations. ref : https://cwiki.apache.org/confluence/display/WICKET/Request+mapping In wicket, the mount path is assumed to be the first element after the domain. e.g. http://www.mydomain.com/mountpath.html/parameters However, my site's URLs are not. They are something like http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters In wicket 1.4, I am using the org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.matches(String, boolean) to match the mount path by 'contains' instead of 'startWiths'. Everything is working fine. In wicket 6.23.0, I find that there is a suggested MountedMapper to replace the old BookmarkablePageRequestTargetUrlCodingStrategy. I am going to do some tricks in org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.parseRequest(Request) and org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getCompatibilityScore(Request) After applying the tricks in AbstractBookmarkableMapper, it works fine now. it is a right direction for me to customize the MountedMapper to suit my needs? I also find a similar case in http://apache-wicket.1842946.n4.nabble.com/Mounting-pages-td4652091.html I check the CryptoMapper and HttpsMapper. It seems that they are not what I need. By doing mount(new MountedMapper("/#{keyword}/#{keyword2}/#{keyword3}/" + mountPath, mountPathPageClass)); I dont not need to do the tricks. It seems to be working fine as well. But when the count of {keyword}s in URL exceeds three, it cannot find the page. There is another question about the Mapper in wicket 6.23.0. After the org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapRequest(Request), my /keyword1/keywordN/ is removed because of the URL recreation by org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.UrlInfo. The result URL becomes http://www.mydomain.com/mountpath.html/parameters again. But I would like to keep my URL as http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters after matching. Is there any way for my to customize the mapper for this case? Many thanks for reading and helping! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-IRequestMapper-customization-for-mount-path-which-is-not-the-first-url-segment-tp4675063.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 6 IRequestMapper customization for mount path which is not the first url segment
Hi All, I am new to wicket. I am migrating my wicket 1.4 project to >wicket 1.5 (wicket 6.23.0). IRequestTargetUrlCodingStrategy interface and all its implementations are replaced with the IRequestMapper and its respective implementations. ref : https://cwiki.apache.org/confluence/display/WICKET/Request+mapping In wicket, the mount path is assumed to be the first element after the domain. e.g. http://www.mydomain.com/mountpath.html/parameters However, my site's URLs are not. They are something like http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters In wicket 1.4, I am using the org.apache.wicket.request.target.coding.AbstractRequestTargetUrlCodingStrategy.matches(String, boolean) to match the mount path by 'contains' instead of 'startWiths'. Everything is working fine. In wicket 6.23.0, I find that there is a suggested MountedMapper to replace the old BookmarkablePageRequestTargetUrlCodingStrategy. I am going to do some tricks in org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.parseRequest(Request) and org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.getCompatibilityScore(Request) After applying the tricks in AbstractBookmarkableMapper, it works fine now. it is a right direction for me to customize the MountedMapper to suit my needs? I also find a similar case in http://apache-wicket.1842946.n4.nabble.com/Mounting-pages-td4652091.html I check the CryptoMapper and HttpsMapper. It seems that they are not what I need. There is another question about the Mapper in wicket 6.23.0. After the org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.mapRequest(Request), my /keyword1/keywordN/ is removed because of the URL recreation by org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper.UrlInfo. The result URL becomes http://www.mydomain.com/mountpath.html/parameters again. But I would like to keep my URL as http://www.mydomain.com/keywordOne/keywordN/mountpath.html/parameters after matching. Is there any way for my to customize the mapper for this case? Many thanks for reading and helping! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-6-IRequestMapper-customization-for-mount-path-which-is-not-the-first-url-segment-tp4675062.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org