Fixes https://github.com/yesodweb/yesod/issues/1771
This is done by adding a function to Yesod
typeclass which can match on any exception
and tell the framework if it should rethrow
or not.
I used an overridable function because it seemed
more flexible then a whitelist.
A user can now for example choose to throw
everything, or catch everything as easily.
add docs
bump
`setDescription` and `setDescriptionI` present a similar API to
`setTitle` and `setTitleI`, but unlike those functions the description
functions are not idempotent - so calling them multiple times inserts
multiple `<meta/>` tags in HTML `<head/>`.
This adds explicitly idempotent versions of those functions which are
handled in a similar way to the title, so that calling them multiple
times has the effect of taking the final value specified.
Because the non-idempotent behaviour of setDescription is not obvious,
this also adds warnings for that behaviour to make it clear what the
effect of multiple calls will be. Unfortunately, setDescriptionIdemp
can't be made a drop-in replacement because developers may have defined
their own layouts which need to take pageDescription into account.
Like setTitle, this function should really be idempotent so developers
don't add multiple conflicting meta descriptions to the page. Unlike
setTitle, the function currently fails its idempotency test.
This test sometimes fails on nix builds.
I'm not sure why, but it should be superflous with
"thread killed = 500" test anyway.
They test both for async exceptions.
Just a different one.
`parseJsonBody` and `requireJsonBody` do not require a mime type when
parsing `JSON` content. This leaves them open to CSRF. They are now
deprecated and `insecure` versions are added in their place. Consumers
are now given a proper choice between secure and insecure functions.
There is a potential attack vector in that the browser does not trigger
CORS requests for "simple requests", which includes POST requests that
are form or text content-types. An attacker can craft a form whose body
is valid JSON, and when a user visits attacker.com and submits that
form, it can be submitted to bank.com and bypass CORS.
Checking the content-type is application/json prevents this, because if
the content-type was set to application/json, then the browser would
send a CORS request—a preflight OPTIONS request to the server asking if
the current domain (and some other values) are whitelisted to send
requests to that server. If the server doesn't say attacker.com is
whitelisted, the browser will not send the real request to the server.
The `selectRep` documentation indicates that it choose the first
representation provided if no representation matches.
This was only partially correct, as `selectRep` required that no
representation matched **and** that the `Content-Type` header of the
response was empty.
This led to a problem because `defaultErrorhandler` relies on
`selectRep`, and when `selectRep` was unable to find a suitable
representation, it would "swallow" the original error that resulted in
`defaultErrorhandler` being called, and set a status 406 for all cases.
This is much more consistent than suddenly using a ReaderT for subsites.
Thanks to @jprider63 for the inspiration for this, I think it cleans
things up a lot!
* The default path of cookies is the current path making the request
* e.g. an AJAX request made from http://example.com/foo/bar would be /foo
* This causes multiple CSRF tokens to build up as you navigate a site
* This will cause errors if the CSRF tokens have different values, and an invalid token is sent.
* Closes#1247
Use CPP hackery to make it compile with ghc-8.0 and ghc 7.10. If
ghc-7.10 works, I assume earlier supported versions of GHC also
work. All tests pass with both GHC versions.
Unfortunately, the TH changes force changes in the type signature
of Yesod.Routes.TH.RenderRoute.mkRouteCons from:
mkRouteCons :: [ResourceTree Type] -> ([Con], [Dec])
to
mkRouteCons :: [ResourceTree Type] -> Q ([Con], [Dec])
and I can't see a way around that.
