You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@wicket.apache.org by Igor Khvostenkov <Ig...@lindenbaum.eu.INVALID> on 2020/04/23 09:59:34 UTC

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

Hi *,

I faced with the problem. When Wicket-generated URL contains jsessionId, form submitted with GET request, and not POST. If I remove jsessionId from URL, then normal POST request is done. I have no idea where this GET is coming from. I ovverode getMethod() to always return POST and issue still exist. Any ideas where I can look to figure out why GET request is done?

Generated HTML:

<pre>

<form role="form" id="accessForm5" 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"><div style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden" class="hidden-fields"><input type="hidden" name="accessForm5_hf_0" id="accessForm5_hf_0"></div> <wicket:container id="feedback6" style="display:none"></wicket:container> <h2>Konferenz-Teilnehmer</h2> <div class="form-group"> <div class="input-group"> <input id=“code" type="text" 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"> <span class="input-group-btn"> <input id="login" type="submit" class="btn btn-primary" wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_wicket__message__attr__6578556" value="Teilnehmen"> </span> </div> </div> </form>

</pre

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

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

Posted by Martin Grigorov <mg...@apache.org>.

On Fri, Apr 24, 2020 at 12:34 PM Igor Khvostenkov
<Ig...@lindenbaum.eu.invalid> 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 <mgrigorov@apache.org<mailto:
> mgrigorov@apache.org>> wrote:
>
> On Fri, Apr 24, 2020 at 10:36 AM Igor Khvostenkov
> <Igor.Khvostenkov@lindenbaum.eu.invalid<mailto:
> Igor.Khvostenkov@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 <mgrigorov@apache.org<mailto:
> mgrigorov@apache.org><mailto:
> mgrigorov@apache.org<ma...@apache.org>>> wrote:
>
> Hi Igor,
>
>
>
> On Fri, Apr 24, 2020 at 12:55 AM Igor Khvostenkov
> <Igor.Khvostenkov@lindenbaum.eu.invalid<mailto:
> Igor.Khvostenkov@lindenbaum.eu.invalid><mailto:
> Igor.Khvostenkov@lindenbaum.eu.invalid<mailto:
> Igor.Khvostenkov@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 <sven@meiers.net<mailto:
> sven@meiers.net><mailto:
> sven@meiers.net<ma...@meiers.net>><mailto:
> sven@meiers.net<ma...@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 <sven@meiers.net<mailto:
> sven@meiers.net><mailto:
> sven@meiers.net<ma...@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:
>
> <pre>
>
> <form role="form" id="accessForm5"
>
>
> 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"><div
>
>
> style="width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hidden"
> class="hidden-fields"><input type="hidden" name="accessForm5_hf_0"
> id="accessForm5_hf_0"></div> <wicket:container id="feedback6"
> style="display:none"></wicket:container> <h2>Konferenz-Teilnehmer</h2> <div
> class="form-group"> <div class="input-group"> <input id=“code" type="text"
> 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"> <span
> class="input-group-btn"> <input id="login" type="submit" class="btn
> btn-primary"
>
>
> wicketpath="pageBorder_pageBorder__body_mainBorder_mainBorder__body_contentBorder_contentBorder__body_content_accessForm_wicket__message__attr__6578556"
> value="Teilnehmen"> </span> </div> </div> </form>
>
> </pre
>
> 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 authenticated
> and this is the reason to redirect you to login.html ?
>
> Another explanation for the misterious GET could be that Wicket uses
> RedirectAfterPost pattern to prevent double submits. See
> 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-unsubscribe@wicket.apache.org<mailto:
> users-unsubscribe@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org<mailto:
> users-help@wicket.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org<mailto:
> users-unsubscribe@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org<mailto:
> users-help@wicket.apache.org>
>
>
>
>
>
>
>
>