This adds a middleware which, when activated, will deny any form submission which does not include a valid `authenticity_token` parameter or `http-x-csrf-token` header with the request.
The header and parameter names are identical to the ones supported by Ruby's rack-protection gem for interoperability purposes.
Sessions are stored in a non-persistent Hash. Only String values are allowed. A reaper fiber regularly removes any sessions which expire due to inactivity.
This commit adds the ability to add a closure suitable for adding
additional options. It is expected to allow someone to set global,
module or class level variables so they can pass changes/options
suitable for making decisions.
It now decouples `env.params` to `env.params.query`, `env.params.body`,
`env.params.json` and `env.params.url` and you still can access merged
values using `env.params.all`
`301` means "Moved Permanently", so browser caches this redirect, it is used when changing server URL.
`302` means "Found", it is used generally (e.g. redirect top page after
login).
Each of `301`, `302`, `303` and `307` means redict, but they are
different. We could choice those status in case.
Removed `env.redirect` in-favor of `redirect` in-order to make Kemal's
API look more like Sinatra.
Thanks @sdogruyol and @f for introducing me to macros :-).
Binding HTTP::Server to 0.0.0.0
First I tried implementing this solution in such a way that it
explicitly clears body and set `Content-Length` header to body's size.
But for some reason, if I call the URL from cURL then `Content-Length`
header was blank which defeats the very purpose of `HEAD` requests.
I then later anticipated that since `HEAD` would be by-default
implemented by `HTTP::Server` module, there is no need to explicit
clears body and setting `Content-Length` but the way we have written
our previous specs were returning body as well. We could have used some
TestServer kind of thing but if we go to that route we explicitly need
to test non-existent route which I thought would create some
inconsistency among specs.
Crystal has clearly written specs for HEAD requests to make sure body
is not read for them. See
https://github.com/manastech/crystal/commit/acd0b6afb5af438a30529c36b11b
e7954336f23f. I decided to write simple specs which are easy to
maintain in long-run.
We are adding identical HEAD route for every GET route which will make
HEAD requests available for all defined GET requests.
https://github.com/sdogruyol/kemal/issues/19
Added comment for code line which is adding HEAD routes for defined GET routes.
Following are the changes made in this commit:
- Added support for magic param `_method` just like Rails, Sinatra
etc.. Browsers which don't support `PUT`, `PATCH` and `DELETE` methods
can simulate them by sending `method` param in request body.
- The default Content-Type to parse request body submitted via forms
etc. is `application/x-www-form-urlencoded`. But if we send Ajax
request in Chrome ($.post) then by-default Content-Type is set to
`application/x-www-form-urlencoded; charset utf-8` which was not
getting matched. I changed the code from `==` to match against a
regular expression using `=~`.
- Print name and color of overridden HTTP method via Logger instead of
printing name and color or request's incoming HTTP method.
Making necessary changes as pointed by @sdogruyol
- Changed method name from`is_override_method_valid?` to
`override_method_valid?`.
- Refactored `if` condition in `override_method_valid?`.
