date:20200424

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

2020-04-24 Thread Martin Grigorov

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?
>
> -Igor.
>
> On 24. Apr 2020, at 09:41, Martin Grigorov  mgrigo...@apache.org> mgrigo...@apache.org> 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 igor.khvosten...@lindenbaum.eu.invalid>> 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

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

2020-04-24 Thread Igor Khvostenkov

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>>>
 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 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>mailto:igor.khvosten...@l

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

2020-04-24 Thread Martin Grigorov

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>> 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> mgrigo...@apache.org 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 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 ret

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

2020-04-24 Thread Igor Khvostenkov

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

Hi Igor,

so you think the "post" is redirected to a "get"? Why should that be the
case?

Who issues this r

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

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

2020-04-24 Thread Igor Khvostenkov

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

[ANNOUNCE] Apache Wicket 8.8.0 released

2020-04-24 Thread Andrea Del Bene


The Apache Wicket PMC is proud to announce Apache Wicket 8.8.0!

Apache Wicket is an open source Java component oriented web application
framework that powers thousands of web applications and web sites for
governments, stores, universities, cities, banks, email providers, and
more. You can find more about Apache Wicket at https://wicket.apache.org

This release marks another minor release of Wicket 8. We
use semantic versioning for the development of Wicket, and as such no
API breaks are present breaks are present in this release compared to
8.0.0.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


    org.apache.wicket
    wicket-core
    8.8.0


Or download and build the distribution yourself, or use our
convenience binary package you can find here:

 * Download: http://wicket.apache.org/start/wicket-8.x.html#manually

Upgrading from earlier versions
---

If you upgrade from 8.y.z this release is a drop in replacement. If
you come from a version prior to 8.0.0, please read our Wicket 8
migration guide found at

 * http://s.apache.org/wicket8migrate

Have fun!

— The Wicket team




    The signatures for the source release artefacts:


Signature for apache-wicket-8.8.0.zip:

    -BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl6coLEACgkQh48B+qjT
VuFdGBAAiHikGIh0UtFE1rABkPus9Vj3OltyM7pqtAw1hyn75OXiDUXHIs00RWCJ
0h7vqKZMYDOq+syHxhEjF4m945jI+de1JMn/zXxa8lCagHk22NClHcdtFlDb+xws
sw+8bY0RkQbImA/kag/yFLpJ8Is/YrHsH76HmHvHHuHFrfXsRI7DNerhokb5BtAM
Z89D4UFzZbHm0iiv6jjExrA7gmXGBKVRI3kG8AO2zmRRfG5gKUcfRh8tQGa80JGO
CGU6peeLsodM1fw29SvT8r49SE2noqDaTuM6GicxREgo/pZVhpJkpNEKtJtM5NQ2
slcX58mpCYkTBYFoMRW1poYlDOU+vfMKYUx5EfrvA1akfg7J+NnsbiWcOM/sjw+y
h8ys7JnoW4jeVelF7xSHcDP8bWW/0ipgW8NfOOcQaMcm49ImAO0VhdFr4M3LvUpd
6Q0K07CNhluVNUk/9XNrM2V1VAovkJACz0rYriI37+zoDUfrjqc2pGZziK7ZgbaP
+NBrvIJtjuOmn5zodwVeOMhA5QSw3qIGg4Tg+jqsIealzMcguJrPPMUFzO3bnRgs
7uCQ6MQ2QXSCFTR3cXWvQh7tkSmtfNrmUz34lU9VcZLUw+6neKAOtmSwsxrATH5X
4iipMYkS81GHnFPPnNP1uQDBUA5X3JktCNa71kmmIMnOrzbjgmM=
=OZ+0
-END PGP SIGNATURE-

Signature for apache-wicket-8.8.0.tar.gz:

    -BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEE0a6YZHC1pJw+aieyh48B+qjTVuEFAl6coLAACgkQh48B+qjT
VuEZAA/7BrVnFLoLBr+XOfkvM38XM/+SU/kb7dSzAs8TaaGawyUPnpDRT/JCtjv+
7g5NvK/1vc7rKJ3ainskwUEI8zfpeegVFMBovabSy70QAF6Lj97Eoz58tLJrkpHU
qTRsBUi8a9vceRuxz/INYM3dbRNylrpFga+jab9hrqK86L1wOhTLQfq6ZJ+nChMb
POUnR8y9jLL4AzR/Me67F9VD4ucVP6xUCJen5baqC1FfXB3cLWOhVS1t46t+Y5r/
7Opv1SWAiumyPpZjcIsnydma2xKtYxMa8tCphgHesgQWpQ/uTG9uuL9k0bim1XwN
G0bewSKa6LVOrLwn2vFwSOWEjrPcK4Zs/M9J4lEA5Ak/ri5U5fT4OzvKmNkUiKUL
2mxMpcstq6UFUJf117bdSqLQ3X3ViJAORrbyqIxR+P0/pn18ybTAsLUXOvMTkM8H
UDtu4UQVFtIhD/quHgSZjMJr0m8hRnVNvZgLjXTT92cmMeCxtfTCfUbZjrwjSPM4
6fQDilKXss25CjC63cM2Ztvd/8KGU7W1vQgdiD56XuduYZ2DHwWWm2QVbazmhegV
tOZfAfYcXcNJagPSNgDLtnhgYCiNyZnvhlOSIQgD5vkVfhskf3RjZgX6J1Y7F+w0
Sb0UwH933TRrxYQBMxv6P+apBhnKCMTAk3UVC0BWzZT1dFGup4s=
=UYoM
-END PGP SIGNATURE-



    CHANGELOG for 8.8.0:


** Bug

    * [WICKET-6746] - HttpsMapper cannot deal with resources over 
websockets

    * [WICKET-6752] - Some dependencies contain CVEs
    * [WICKET-6753] - res/modal.js using aria-labelledby where it 
should be using aria-label

    * [WICKET-6754] - Iteration stops with nested containers
    * [WICKET-6755] - MockServletContext does not decode real path
    * [WICKET-6756] - Avoid URL.getFile() when actually expecting paths.
    * [WICKET-6757] - Avoid URL.getFile during mime type detection.
    * [WICKET-6758] - NPE in AbstractWebSocketProcessor after session 
times out


** Improvement

    * [WICKET-6759] - Support disabling error notification for websockets
    * [WICKET-6760] - Nested Form placeholder should preserve tag name
    * [WICKET-6761] - Support multiple connections to the same 
websocket resource from a single session
    * [WICKET-6762] - Support manual initialization of websocket 
connections



-
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-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>>> 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 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/apache/wicket/commit/0c19cf8/#diff-51cf2faf6078497df77cc6d995dd1b98
.
Starting from Wicket 7.16 you distinguish between GET and POST in
F

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

2020-04-24 Thread Martin Grigorov

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

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

2020-04-24 Thread Igor Khvostenkov

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

Hi,

if the generated HTML contains method="post", the browser will send the
form as post request.

Without more detailed

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

2020-04-24 Thread Martin Grigorov

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

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

2020-04-24 Thread Igor Khvostenkov

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

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

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

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

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

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

[ANNOUNCE] Apache Wicket 8.8.0 released

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

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

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

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

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

12 matches

Site Navigation

Mail list logo

Footer information