This needed to happen in order to automatically get CSRF protection
Several changes happened while switching over:
* Relied on built in names for inputs
* Cleaned up naming
* Created password helpers for each field
* Added a translation for current password
I'm sure this is trivially obvious. :-)
Commit 6a60dac introduced `sendStatusJSON` on Nov 25, 2015; yesod-core 1.4.18 was uploaded to hackage on Dec 17.
The form helpers weren't being used which caused the CSRF tokens to not
be present. This also allows for a bit more flexability and
cleans up the code as well.
The following will now use stack:
* `stack query` succeeds from current directory instead of searching that a `stack.yaml` exists
* `STACK_YAML` or `STACK_EXE`(set by `stack exec`) environment variables are set
* Up version bounds so that `defaultCsrfParamName` is available.
* I didn't bump the yesod-form version. It seemed unnecessary to do a new release just for this.
Closes#1159
Based on reading this [StackOverflow Post](http://stackoverflow.com/questions/6412813/do-login-forms-need-tokens-against-csrf-attacks) and skimming [this paper](http://seclab.stanford.edu/websec/csrf/csrf.pdf), using CSRF protection on login forms protects against a vulnerability where an attacker submits their own username/password in the login form. Later, the user uses the real site, but doesn't realize they're logged in as the attacker. This creates vulnerabilities like:
1. If the site logs the user's activity for them (e.g. recently watched videos on YouTube, previous searches on Google), the attacker can see this information by logging in.
2. The user adds sensitive information to the account, like credit card information, the attacker can login and potentially steal that information or use it on the site.
I don't think this vulnerability applies to the `Yesod.Auth.Hardcoded` plugin because the attacker couldn't create an account of their own.
However:
* If I understand the example in `Yesod.Auth.Hardcoded`, one use case is to share one login form that works for both the Hardcoded plugin as well as normal database-backed username/password login, in which case having a CSRF token makes sense
* I don't see a downside to having the CSRF token there
* It makes the Hardcoded plugin work with the CSRF middleware
Does this sound like the right solution?
