Return a 403 status code if the csrf tokens are matched. This currently
affects two endpoints: During registration and during password reset
forms.
This curl request demonstrates how this can be exploited to register new
email:
curl -i --header "Accept: application/json" --request POST -F
"email=sibi@psibi.in" http://localhost:3005/auth/page/email/register
With the patch applied, it will respond with this:
{"message":"Permission Denied. A valid CSRF token wasn't present in HTTP
headers or POST parameters. Because the request could have been forged,
it's been rejected altogether. Check the Yesod.Core.Handler docs of the
yesod-core package for details on CSRF protection."}
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
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.
* 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?
`LogoutTitle` is a replacement for `Logout` constructor, the latter is
inconsistent with `LoginTitle` constructor name.
Added `DEPRECATED` pragma to warn users about this change.
This allows users of the library to easily render VerUrl to use in
verification emails to new users, if the user was created outside
of the regular register functionality.
- getAuthId returns Maybe AuthId with no useful information in the
Nothing case.
- AuthenticationResult includes whether it was a User or Server error
(with an accompanying message) in the failure case.
- User errors are displayed back to the user and have a 401 status in
JSON responses. Server errors are logged and a generic error message
is presented to the user, with a 500 status in JSON responses.
Resolves#956
The existing GoogleEmail2 auth did that:
- Acquire user access token with offline access
- Use token to acquire user's profile
- Build `Creds` with user's email as `ident` and the other profile
details as stringy key-value pairs in `credsExtra`
This wasn't enough for me, for several reasons:
- Access token was not saved after authentication. If we request 'offline'
token why not to have a way of using it later.
- Stringy key-value profile is not nice and `credsExtra` can be accessed
only from `getAuthId`
- I might want to request the profile after authentication process
So I've added the needed features.
- The access token is saved in a session
- There is a `Person` type with `FromJSON` instance and `getPerson`
can be used to acquire it from `HandlerT`
Added support for `Logout` message, all translations made with Google
Translate, except: Russian translation (by hand) and Dutch translation
(do not translated)
