Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
Since this test was added in commit 78c6a30424 the
"current_password" was filled with an incorrect value.
This test did not fail because in previous versions of the
"devise-security" gem if this "current_password" was not valid
a "self.valid?" was performed which caused the error we are testing.
In version 0.17 (as can be seen in the following commit
https://github.com/devise-security/devise-security/pull/340/commits/41a99b67fe0)
if the "current_password" is not valid, related errors are still added
but the "self.valid?" code is removed, which is what causes the
expected error "must be different than the current password"
to appear in the "new password" field.
By adding a correct "current_password" in the test, we avoid this validation
for the "current_password" (which no longer includes the expected error)
and follow the natural flow of devise that does end up intercepting the error
for the new password entered.
One of these tests has failed once because there wasn't a user with the
right confirmation token. While I haven't been able to reproduce the
issue, there's a chance it's caused by a `visit` call to the
confirmation path which might start before the redirect request to the
successful sign up page has finished.
I'm not sure this is the case, though, but, worst case scenario, if the
test fails again we'll know it isn't because of a missing expectation.
The Google response contains an `email_verified` field instead of a
`verified_email` field, and so we weren't treating verified Google
accounts as verified.
Currently the application does not send any email to confirm the
account for already confirmed users. But we show a notice message
that may look like you will recive one:
"If your email address exists in our database, you will receive
an email with instructions for how to confirm your email address
in a few minutes."
In this commit we keep the original message, but send an email to
the user informing them that their account is now registered.
This way no one can know if someone else's account is confirmed and
we don't have to worry about GDPR either.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
When we try to register with omniauth and the email or username already exists,
we use the finish_signup and do_finish_signup actions to allow the user to choose
another email or username.
The do_finish_signup action of the registration controller calls the
send_oauth_confirmation_instructions method which is responsible for sending the
confirmation email.
In this method we were only validating the case that the email is duplicated. Now
we add one more condition that allows us to send the instructions for the case in
which we have had to change our username.
The controller provided by the `devise-security` gem which tests
password is expired does not execute the `before_action` we have in our
application controller. That means it doesn't set the current locale.
We were having issues in the tests checking this behavior if the
previous test had set the current locale to a different one. This meant
the process running the browser had one locale while the process running
the test had a different one, which resulted in a page in English (as
expected), only the flash message notifying users their password expired
was in a different language.
To reproduce this behavior, run:
```
rspec './spec/system/welcome_spec.rb[1:1:2:2:1]' spec/system/users_auth_spec.rb:623 --order defined
```
I'm not sure whether this is a bug or it's a problem with the tests. In
theory it might be possible to reproduce a similar behavior in
production due to what we mention about the controller not executing the
`set_current_locale` method. But I haven't been able to reproduce the
situation, particularly since the password expiration seems to be
checked exclusively at login time (that is, if you stay logged in for 10
years, your password doesn't seem to expire).
So for now I'm just making the tests pass by using the login form
instead of using `login_as`.
JavaScript is used by about 98% of web users, so by testing without it
enabled, we're only testing that the application works for a very
reduced number of users.
We proceeded this way in the past because CONSUL started using Rails 4.2
and truncating the database between JavaScript tests with database
cleaner, which made these tests terribly slow.
When we upgraded to Rails 5.1 and introduced system tests, we started
using database transactions in JavaScript tests, making these tests much
faster. So now we can use JavaScript tests everywhere without critically
slowing down our test suite.
ChromeDriver only supports characters in the BMP (Basic Multilingual
Plane). One test fails with ChromeDriver because it was entering emojis.
I'm using kanji characters instead, although I must admit I'm not sure
why such an unusual login was used in the first place.
