subject:"URL"

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?
>
> -I

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...@l

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:mgrigo

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

2020-04-24 Thread Sven Meier

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 regar

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> specify

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-24 Thread Sven Meier

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.

https://github.com/

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 GE

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:

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.

-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).

-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:

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).

-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:

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

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-23 Thread Martin Grigorov

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 authent

Re: Form submit sends GET request, if Wicket-generated URL contains jsessionId

2020-04-23 Thread Igor Khvostenkov

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

2020-04-23 Thread Sven Meier


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

2020-04-23 Thread Igor Khvostenkov

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

2020-04-23 Thread Sven Meier


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

2020-04-23 Thread Igor Khvostenkov

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)

2019-11-13 Thread Daniel Stoch

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

2019-06-20 Thread Martin Grigorov

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

2019-06-20 Thread Francois Meillet

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

2019-04-26 Thread Joël Guelluy

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

2019-04-26 Thread Joël Guelluy

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

2019-04-26 Thread Sven Meier

 
 
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

2019-04-26 Thread gaston_l

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

2019-04-25 Thread Sven Meier

 
 
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

2019-04-25 Thread gaston_l

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

2019-03-06 Thread Calin Pavel


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

2019-03-06 Thread Martin Grigorov

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

2019-03-06 Thread Maxim Solodovnik

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

2019-03-06 Thread Calin Pavel


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

2019-02-27 Thread Martin Grigorov

<pre>Hi,

On Wed, Feb 27, 2019 at 10:00 PM Chris Colman <chr...@stepaheadsoftware.com>
wrote:

> Hi Martin,
>
> Does this patch address the loss of URL encoding when redirecting to an
> external URL or is this just to avoid the CORS error when invoking
> RedirectToUrlException from an Ajax request?
>
> I guess using SC_SEE_OTHER is an adequate workaround but it may not be
> obvious to other devs why the premature URL decoding occurs when using
> the RedirectToUrlException constructor that only takes the URL.
>

The decoding happens because of "Url.parse(CharSequence)" call.
The logic in ServletWebResponse#sendRedirect() needs to construct an
absolute url before passing it to the web container (Tomcat, Jetty).
It needs to pass an absolute url because of Microsoft Internet Explorer :-/
There is/was a bug in IE that it didn't follow relative urls in response
header "Location".
To be able to tell whether the url is absolute or relative Wicket needs to
parse it, and thus - decode it. If it is relative it makes the proper
calculations to make it an absolute one.

Only MOVED_TEMPORARILY could be relative. MOVED_PERMANENTLY and SEE_OTHER
are always considered as external/absolute urls so Wicket does not try to
encode them. Here by encoding one should understand "add ;jsessionid=asdf"
to the url if session tracking via cookies is disabled for some reason.


> Regards,
> Chris
>
> > -Original Message-
> > From: Martin Grigorov [<a  rel="nofollow" href="mailto:mgrigo...@apache.org">mailto:mgrigo...@apache.org</a>]
> > Sent: Thursday, 28 February 2019 6:46 AM
> > To: users@wicket.apache.org
> > Subject: Re: Undesirable decoding of URL encoded external URL using
> > RedirectToUrlException
> >
> > <a  rel="nofollow" href="https://issues.apache.org/jira/browse/WICKET-6638">https://issues.apache.org/jira/browse/WICKET-6638</a>
> >
> > Wicket 6.x receives only security related fixes and this one doesn't
> count
> > as such.
> > You will have to use HttpServletResponse in your application.
> >
> > On Wed, Feb 27, 2019 at 9:09 PM Chris Colman
> > <chr...@stepaheadsoftware.com>
> > wrote:
> >
> > > The code that is removing the encoding is in ServletWebResponse:
> > >
> > > public void sendRedirect(String url) {
> > > try {
> > > this.redirect = true;
> > >
> > > >>>> 'encode' is actually performing a decode in this line <<<<
> > > url = this.encodeRedirectURL(url);
> > > this.disableCaching();
> > > if (this.webRequest.isAjax()) {
> > > this.httpServletResponse.setHeader("Ajax-Location",
> > > url);
> > >
> > >
> this.httpServletResponse.getWriter().write("<ajax-response><redirect><![
> > > CDATA[" + url + "]]></redirect></ajax-response>");
> > > this.setContentType("text/xml;charset=" +
> > > this.webRequest.getContainerRequest().getCharacterEncoding());
> > > this.disableCaching();
> > > } else {
> > >     this.httpServletResponse.sendRedirect(url);
> > > }
> > >
> > > } catch (IOException var3) {
> > > throw new WicketRuntimeException(var3);
> > > }
> > > }
> > >
> > > > -Original Message-
> > > > From: Chris Colman [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > > > Sent: Thursday, 28 February 2019 5:05 AM
> > > > To: users@wicket.apache.org
> > > > Subject: 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
> > > > displ

RE: Undesirable decoding of URL encoded external URL using RedirectToUrlException

<pre>Hi Martin,

Does this patch address the loss of URL encoding when redirecting to an
external URL or is this just to avoid the CORS error when invoking
RedirectToUrlException from an Ajax request?

I guess using SC_SEE_OTHER is an adequate workaround but it may not be
obvious to other devs why the premature URL decoding occurs when using
the RedirectToUrlException constructor that only takes the URL.

Regards,
Chris

> -Original Message-
> From: Martin Grigorov [<a  rel="nofollow" href="mailto:mgrigo...@apache.org">mailto:mgrigo...@apache.org</a>]
> Sent: Thursday, 28 February 2019 6:46 AM
> To: users@wicket.apache.org
> Subject: Re: Undesirable decoding of URL encoded external URL using
> RedirectToUrlException
> 
> <a  rel="nofollow" href="https://issues.apache.org/jira/browse/WICKET-6638">https://issues.apache.org/jira/browse/WICKET-6638</a>
> 
> Wicket 6.x receives only security related fixes and this one doesn't
count
> as such.
> You will have to use HttpServletResponse in your application.
> 
> On Wed, Feb 27, 2019 at 9:09 PM Chris Colman
> <chr...@stepaheadsoftware.com>
> wrote:
> 
> > The code that is removing the encoding is in ServletWebResponse:
> >
> > public void sendRedirect(String url) {
> > try {
> > this.redirect = true;
> >
> > >>>> 'encode' is actually performing a decode in this line <<<<
> >     url = this.encodeRedirectURL(url);
> > this.disableCaching();
> >     if (this.webRequest.isAjax()) {
> > this.httpServletResponse.setHeader("Ajax-Location",
> > url);
> >
> >
this.httpServletResponse.getWriter().write("<ajax-response><redirect><![
> > CDATA[" + url + "]]></redirect></ajax-response>");
> > this.setContentType("text/xml;charset=" +
> > this.webRequest.getContainerRequest().getCharacterEncoding());
> > this.disableCaching();
> > } else {
> > this.httpServletResponse.sendRedirect(url);
> > }
> >
> > } catch (IOException var3) {
> >     throw new WicketRuntimeException(var3);
> > }
> > }
> >
> > > -Original Message-
> > > From: Chris Colman [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > > Sent: Thursday, 28 February 2019 5:05 AM
> > > To: users@wicket.apache.org
> > > Subject: 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 [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > > > 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

Re: Undesirable decoding of URL encoded external URL using RedirectToUrlException

2019-02-27 Thread Martin Grigorov

<pre><a  rel="nofollow" href="https://issues.apache.org/jira/browse/WICKET-6638">https://issues.apache.org/jira/browse/WICKET-6638</a>

Wicket 6.x receives only security related fixes and this one doesn't count
as such.
You will have to use HttpServletResponse in your application.

On Wed, Feb 27, 2019 at 9:09 PM Chris Colman <chr...@stepaheadsoftware.com>
wrote:

> The code that is removing the encoding is in ServletWebResponse:
>
> public void sendRedirect(String url) {
> try {
> this.redirect = true;
>
> >>>> 'encode' is actually performing a decode in this line <<<<
> url = this.encodeRedirectURL(url);
> this.disableCaching();
> if (this.webRequest.isAjax()) {
> this.httpServletResponse.setHeader("Ajax-Location",
> url);
>
> this.httpServletResponse.getWriter().write("<ajax-response><redirect><![
> CDATA[" + url + "]]></redirect></ajax-response>");
> this.setContentType("text/xml;charset=" +
> this.webRequest.getContainerRequest().getCharacterEncoding());
> this.disableCaching();
> } else {
> this.httpServletResponse.sendRedirect(url);
> }
>
> } catch (IOException var3) {
> throw new WicketRuntimeException(var3);
> }
> }
>
> > -Original Message-
> > From: Chris Colman [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > Sent: Thursday, 28 February 2019 5:05 AM
> > To: users@wicket.apache.org
> > Subject: 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 [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > > 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 [<a  rel="nofollow" href="mailto:mgrigo...@apache.org">mailto:mgrigo...@apache.org</a>]
> > > > 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 fin

RE: Undesirable decoding of URL encoded external URL using RedirectToUrlException

<pre>The code that is removing the encoding is in ServletWebResponse:

public void sendRedirect(String url) {
try {
this.redirect = true;

>>>> 'encode' is actually performing a decode in this line <<<<
    url = this.encodeRedirectURL(url);
this.disableCaching();
if (this.webRequest.isAjax()) {
this.httpServletResponse.setHeader("Ajax-Location",
url);
 
this.httpServletResponse.getWriter().write("<ajax-response><redirect><![
CDATA[" + url + "]]></redirect></ajax-response>");
this.setContentType("text/xml;charset=" +
this.webRequest.getContainerRequest().getCharacterEncoding());
    this.disableCaching();
} else {
this.httpServletResponse.sendRedirect(url);
}

} catch (IOException var3) {
throw new WicketRuntimeException(var3);
}
}

> -Original Message-
> From: Chris Colman [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> Sent: Thursday, 28 February 2019 5:05 AM
> To: users@wicket.apache.org
> Subject: 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 [<a  rel="nofollow" href="mailto:chr...@stepaheadsoftware.com">mailto:chr...@stepaheadsoftware.com</a>]
> > 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 [<a  rel="nofollow" href="mailto:mgrigo...@apache.org">mailto:mgrigo...@apache.org</a>]
> > > 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
> > > <chr...@stepaheadsoftware.com>
> > > wrote:
> > >
> > > > I am using:
> > > >
> > > >
> > > >
> > > > throw new RedirectUrlException(externalUrl);
> > > >
> > > >
> > > >
> > > > to redirect to an external URL (i.e.
> > > > <a  rel="nofollow" href="https://hostname/path?param1=value1&param2=value2">https://hostname/path?param1=value1&param2=value2</a> etc.,)
> > > >
> > > >
> > > >
> > > > In constructing the URL I have used java.net.URLEncoder.encode()
> to
> > > > individual encode the values in each of the query parameters.
> > > >
> >

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=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=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

2019-02-26 Thread Martin Grigorov

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=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

2019-02-25 Thread Chris Colman

I am using:

 

throw new RedirectUrlException(externalUrl);

 

to redirect to an external URL (i.e.
https://hostname/path?param1=value1=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

2018-06-03 Thread Zala Pierre GOUPIL

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

2018-06-03 Thread Maxim Solodovnik

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

2018-06-03 Thread Zala Pierre GOUPIL

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?

2018-05-31 Thread Bas Gooren

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?

2018-05-26 Thread Martin Grigorov

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 <b...@iswd.nl> 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?

2018-05-25 Thread Bas Gooren

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?

2018-04-09 Thread Csaba Galyó

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?

2018-04-09 Thread Martin Grigorov

On Mon, Apr 9, 2018 at 2:45 PM, gcsaba2 <gcsa...@gmail.com> 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?

2018-04-09 Thread gcsaba2

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?

2018-04-08 Thread Don Ferguson

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 <gcsa...@gmail.com> 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?

2018-04-07 Thread gcsaba2

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?

2018-02-28 Thread Martin Grigorov

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 <parth.pa...@silvertouch.com> 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?

2018-02-28 Thread parth

*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

2017-09-01 Thread Marcel Barbosa Pinto

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 <tomas.klou...@embedit.cz> 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

2017-08-31 Thread tomask79

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

2017-08-31 Thread Martin Grigorov

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 <tomas.klou...@embedit.cz> 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

2017-08-31 Thread tomask79

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?

2017-07-24 Thread tomask79

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?

2017-07-24 Thread Martin Grigorov

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 <tomas.klou...@embedit.cz> 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?

2017-07-24 Thread tomask79

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

2017-05-24 Thread Martin Grigorov

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

2017-05-24 Thread Peter Henderson

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

2017-05-24 Thread Peter Henderson

On 23 May 2017 at 22:24, Martin Grigorov <mgrigo...@apache.org> 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

2017-05-23 Thread Martin Grigorov

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

2017-05-23 Thread Peter Henderson

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/#=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/#=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/#=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

2017-05-03 Thread 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/#=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/#=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

2017-04-04 Thread Martin Grigorov

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

2017-04-03 Thread Andreas Lundblad

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

2017-04-03 Thread Martin Grigorov

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

2017-04-02 Thread Andreas Lundblad

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

2017-03-27 Thread Manfred Bergmann

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

2017-03-27 Thread Sebastien

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 <m...@software-by-mabe.com>
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

2017-03-27 Thread Manfred Bergmann

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

2017-03-14 Thread Maxim Solodovnik

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
<m...@software-by-mabe.com> 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

2017-03-13 Thread Sebastien

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

2017-03-13 Thread Martin Grigorov

On Mon, Mar 13, 2017 at 6:21 PM, Manfred Bergmann <m...@software-by-mabe.com>
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

2017-03-13 Thread Martin Grigorov

Hi,

On Mon, Mar 13, 2017 at 5:37 PM, Manfred Bergmann <m...@software-by-mabe.com>
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