This function checks that a response body is JSON, and parses it into a Haskell value. Having something like this function is pretty essential to using Yesod as a JSON API server, so I think it's a good addition. You can use it to parse a Haskell record directly (usually by adding FromJSON classes to your response types), or parse a Value and pull out individual fields, maybe using something like `aeson-lens` (though probably a testing-specific library would be better).
I debated over these things:
1. The name. I was thinking of something like [assert/require/decode/parse]JSON[Response/Body]. I ultimately went with requireJSONResponse:
- decode/parse sound like the aeson functions that return Either or Maybe, and I wanted this function to throw an error if it failed
- I'm open to using `assertJSONResponse`—it matches the other functions (`assertEq`) better—but I think it reads less like English.
- I chose Response over Body because (a) It also checks the content-type header, which is not in the body (b) "Body" felt slightly in-the-weeds of HTTP; I think "response" is more approachable.
2. Should it require the JSON content type? You can definitely have a server that returns JSON without JSON content types, but I think that's a such a bad idea, it's more likely requiring it helps people if they accidentally don't add the header.
3. Should it take a String parameter to add to the error message? This would match `assertEq`, but other functions like `statusIs` don't take a message. Ultimately I went without it, because the messages felt like I was repeating myself: `(comment :: Comment) <- requireJSONResponse "the response has a comment"`
This adds `jsAttributesHandler` to run arbitrary Handler code before
building the attributes map for the script tag generated by `widgetFile`.
This is useful if you need to add a randomised nonce value to that tag.
Closes https://github.com/yesodweb/yesod/issues/1621
If someone wants their website to score a good grade on a security
vulnerability scanner like Mozilla Observatory, they will need to enable
the Content Security Policy header. When using CSP, it is possible to
explicitly allow inline JavaScript in `<script>` tags by specifying the
sha256 of the snippet. However the same is _not_ true of any JavaScript
included in a HTML attribute like `onload`.
This changes moves the JavaScript form submission out of the `onload`
HTML attribute and into a `<script>` tag so the user can add the hash of
this script to their explicitly-allowed `script-src` list, and they can
avoid using undesirable CSP rules like `unsafe-inline`.
Without explicitly allowing this script when using CSP, the script would
fail and the user would have to click the button to continue.
