Quirks with GET forms
Forms can be set to GET using:
Submit buttons seem to require names, meaning they get added to the GET params on submit.
Also, I haven't found a way to remove the CSRF token on GET forms yet, so these also get added to the URL. It doesn't break anything if they're invalid (as the CSFR isn't actually checked on GET request), but it results in quite messy looking URLs.
The old help search URL looks like this:
/help/search?search=iPad
The new one looks like this:
/help/search?help_search[search]=iPad&help_search[save]=&_token=EsYx3MbFAtNhG0OAMYjiYJPMB9akRnedzwzTCto1ffsd
Something we would find a solution for ideally.
Note:
Anytime you define a "POST", "PUT", "PATCH", or "DELETE" HTML form in your application, you should include a hidden CSRF _token field in the form so that the CSRF protection middleware can validate the request. For convenience, you may use the @csrf Blade directive to generate the hidden token input field:
https://laravel.com/docs/13.x/csrf
Suggestion actions
- We should not use CSRF for GET forms.
- Can we make submit button "name" optional? (it is not technically required if we have 1 submit button in a form)
Quirks with GET forms
Forms can be set to GET using:
Submit buttons seem to require names, meaning they get added to the GET params on submit.
Also, I haven't found a way to remove the CSRF token on GET forms yet, so these also get added to the URL. It doesn't break anything if they're invalid (as the CSFR isn't actually checked on GET request), but it results in quite messy looking URLs.
The old help search URL looks like this:
/help/search?search=iPad
The new one looks like this:
/help/search?help_search[search]=iPad&help_search[save]=&_token=EsYx3MbFAtNhG0OAMYjiYJPMB9akRnedzwzTCto1ffsd
Something we would find a solution for ideally.
Note:
Suggestion actions