This triggered a "cross reaction" of sorts.
bbd4cad40 tried to fix a redirect loop by checking for the presence of
content in `flash` (assuming that this meant the presence of a text message
to be shown to the user).
0fa8b4a77 used the flash storage to forward CSP extensions so they are usable
for exactly one follow-up request. While this is an allowed usage of `flash`,
it was sufficiently far away from what it's usually used for that it threw over
expectations of the former change and consequently led to breaking the direct login
workflow.
The specs were not working as intended, because the settings-update of with_config was
effectively undone by also using with_settings in the same spec.
Previously we tested nothing in the email, not even the subject.
This means a broken implementation that always would send "can't change password"
would not have been discovered.
The new test checks the subject (comparable to the other test cases in the same file)
and also does not simply assume that the mail will contain the correct link, but rather
uses the link from the mail.
Previously we'd be hiding the "change password" dialog on the
basis of an external authentication method existing. However, that's
not enough, because (at least with user remapping enabled) it's possible
that a user that logged in via password once, gained the ability to login
through SSO afterwards. Such a user then can use both mean to authenticate,
thus they also need to be able to change a potentially compromised password.
Much more work is needed here: Users need to be aware that their password still
works, they need to be able to delete a password if they only want to use SSO and
maybe there's also a use case for deleting an SSO association and going back to
password-based logins. However, all of these things require more UI changes and
some proper product development first.
This change is a first step to improve the situation.
This is intended to be a more natural and readable way of manipulating the
identity_url of a user. It also means that if we ever decide to change
the way how the identity_url is built or how providers are attached to
a user, it should be easier to switch the majority of tests relying on it
over to the new schema.
Previously we only got the slug name of the provider
as a string, which doesn't allow to further use the provider.
Converting it back into its AR representation allows to call
further methods on it, e.g. checking support for certain capabilities.
This commit provides an alternative implementation
for storing tokens compared to the parent commit.
The idea is that we will not only need to store access
and refresh tokens obtained via Omniauth, but also the ones
to access third party services that will most likely be obtained
through OAuth 2.0 Token Exchange. This structure allows to store
all of these tokens in the same data model, while keeping the
implementation separated from the back-channel logout logic.
This results in us having to use a bit more helpers around request and feature specs
to ensure that the configured host name also matches the requested one.
Jan Sandbrink