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)
`AuthEntity` is now a type family associated to the `YesodAuthPersist`
class, so its old type alias definition has now become its default type
instance, which allows recovering the old behavior with minimal
boilerplate: an empty instance declaration for `YesodAuthPersist` makes
a Yesod application written with Persistent work just like before.
Unfortunately, this requires enabling `UndecidableInstances` in the
`Yesod.Auth` module since there is now a nested type family application
(as `AuthEntity` is now itself a type family).
This was tested with the scaffolded application with PostgreSQL, and it
works (given another small change to make it work with Persistent 2 due
to how `SqlPersistT` is now defined).
`maybeAuth` and `requireAuth` have been reverted to their original
signatures, which assume a Persistent database. `maybeAuthPair` and
`requireAuthPair` are introduced, which do the same but without that
assumption.
Pinging @gregwebs. I've backported the relevant tweaks on the yesod-1.4
branch, to allow master to compile against persistent2. Whenever you're
ready to release persistent2, we can:
1. Release persistent2.
2. Release new versions of yesod packages, which will work with
persistent 1.3 and 2.0.
3. Add an upper bound in Stackage to avoid using the new persistent
libraries until they're ready for primetime.
4. Release your blog post.
yesod-1.4 should then remove the CPP here and only work with
persistent2; the biggest "breaking change" in the 1.4 release will be
remove backwards compatibility hacks for persistent, conduit,
shakespeare, and wai.
