Omniauth-microsoft_graph correctly populates 'email' and 'name' fields used by OpenStreetMap.
It also uses updated endpoints for Microsoft identity provider.
Use email address returned by microsoft_graph provider as a verified address.
Upgrading exisiting users from windowslive to microsoft_graph:
- upon next login existing `windowslive` users will have to authorizei
OpenStreetMap application to "Read Your Profile," required for proper reading
of display name field.
The name of the identity provider in OSM is kept to 'windowslive':
- the entries in users table with `provider == 'windowslive'`
can be reused for microsoft_graph provider, since
the uid field is preserved. Users will not need to repeat the sign up process.
- OAuth2 callback is still `/auth/windowslive`, no updates to Microsoft Identity Provider portal
App registration are necessary.
The user status is a bit complex, since there are various states and
not all transitions between them make sense.
Using AASM means that we can name and restrict the transitions, which
hopefully makes them easier to reason about.
"delete" is generally used for immediate SQL deletion without running
any callbacks or other ruby code, whereas "destroy" will trigger callbacks.
Although we don't currently use any callbacks, let's rename this method to
align better with the convention.
This allows us to include a link in the flash message, without having
to use html_safe. Also refactor to avoid having html angle brackets in
the translation strings, while still allowing locale-specific urls.
When the user wants to enable an external authenticator we need
to redirect to omniauth but that now needs to be a POST so use a
redirect that preserves the POST method.
Fixes#3114
We can avoid using `html_safe` in various circumstances, through alternative approaches like i18n keys ending in `_html` or using `safe_join` to avoid converting via unsafe string types.
The `_html` keys approach only work for ActionView helper version of `t`, not the base `I18n.t` method.
It's a convention in rails to name your mailers with a Mailer suffix, and is also common to name the class after the recipient (e.g. User, Admin). So UserMailer seems a reasonable choice.
As we don't have any way to actually find the active sessions for
an account we instead store a fingerprint in the session, and refuse
to use any session with a different fingerprint.
