We are making this the only option for our login/signup
pages on April 29th, 2025, per
https://meta.discourse.org/t/introducing-our-new-fullscreen-signup-and-login-pages/340401.
This commit removes the `full_page_login` setting and any logic
around it, as well as deleting the old login and signup modals,
and removing leftover problem checks and settings from the database.
Instead of having each test go incur the overhead of having to go
through the actual user flow to register a security key, we can generate
the WebAuthn credentials on the server side and adds it to the virtual
authenticator.
There are flaky system tests that have been exhausting the 10 seconds
default max wait time which we have set previously on CI. However, I
have yet to be able to figure out why and lack the tools to be able to
figure out why. The hope here is that the upcoming playwright driver
will provide us with better tooling to debug such problems.
I've attempted to use `Capybara::Session#using_wait_time` by there is
some race condition going on where the session's default max wait time
is sometimes not set properly. I can't figure out why and have spent too
much time trying to figure out why. Instead, I will just bump up the
`default_max_wait_time` to `20`. This may the build take longer when
there are test failures but it is a trade-off we will make right now.
When `Capybara.threadsafe` has been set to `true` as in our case, we
have to use `Capybara::Session#using_wait_time` instead of
`Capybara.using_wait_time`. The latter sets `default_max_wait_time` on
`Capybara.default_max_wait_time` while the former sets
`default_max_wait_time` on the session.
This is a follow up to 59edec46a3de105e720bd2c716ae34d636794044
Test is flaky and seems to require more time to complete on CI so we
double the max wait time for now to see if it reduces the test's
flakiness.
The `using_wait_time` DSL did not work when used in the `around` context
as the Capybara's session has not been initialized.
Follow-up to afde7cc1727a751e4d87be2ceee17f2d82edf89c
I'm not sure what is causing the tests to be flaky so I need more
information to determine where the problem is. For now, I'm doubling the
wait time to rule out any server side problem.
This is to provide diagnostic information for some flaky system tests
which we are currently investigating. The previous attempt in
6f92f42eb83fea61b2712aaaefcc124e4939365d only dumped threads that
contains the `puma` gem in the backtrace but that is not enough. Since I
am now printing all thread backtraces, I added the
`dump_threads_on_failure` metadata
which will be used to determine if all the thread backtraces should be
printed out in the spec's failure output.
This commit improves said method to ensure that user is redirected to
the right page before returning.
### Reviewer notes
Example of test flakiness:
https://github.com/discourse/discourse/actions/runs/14081653020/job/39435797236
```
Failure/Error: raise capybara_timeout_error
CapybaraTimeoutExtension::CapybaraTimedOut:
This spec passed, but capybara waited for the full wait duration (10s) at least once. This will slow down the test suite. Beware of negating the result of selenium's RSpec matchers.
[Screenshot Image]: /__w/discourse/discourse/tmp/capybara/failures_r_spec_example_groups_user_resetting_password_when_desktop_when_user_has_multi_factor_authentication_configured_when_user_has_security_key_and_backup_codes_configured_should_allow_a_user_to_reset_pass_261.png
~~~~~~~ JS LOGS ~~~~~~~
~~~~~ END JS LOGS ~~~~~
Shared Example Group: "forgot password scenarios" called from ./spec/system/forgot_password_spec.rb:213
./spec/rails_helper.rb:426:in `block (3 levels) in <top (required)>'
./spec/rails_helper.rb:619:in `block (3 levels) in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/benchmark-0.4.0/lib/benchmark.rb:304:in `measure'
./spec/rails_helper.rb:619:in `block (2 levels) in <top (required)>'
./spec/rails_helper.rb:580:in `block (3 levels) in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:185:in `block in timeout'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/timeout-0.4.3/lib/timeout.rb:192:in `timeout'
./spec/rails_helper.rb:570:in `block (2 levels) in <top (required)>'
./spec/rails_helper.rb:527:in `block (2 levels) in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/webmock-3.25.1/lib/webmock/rspec.rb:39:in `block (2 levels) in <top (required)>'
```
This switches the signup/login UI to the full page experience by
default. This has been in use by many sites for multiple months and we
have ironed out many fixes in the meantime.
The `full_page_login` setting is also marked for removal in about
1.5mths, by the end of April 2025.
This commit unskips 3 flaky system tests and gives up on asserting that
redirecting is done correctly. This is because we have invested
considerable effort into this and cannot figure it out. The redirect is
tested by the client side anyway so there is still some test coverage.
This commit removes an assertion for the redirect after 2FA
authentication is success message because the message is flashed briefly
before a route transition happens. A proper fix would require us to
redesign when/how the flash message which we can address in the future.
This commit updates the 2FA token submission page to disable the submit
button when the 2FA token is not valid and to also set the submit button
to be in the loading state after the submit button has been clicked.
The UX issues were discovered while I was investigating a flaky test
which has been unskipped in this commit as well. I am not sure if this
will completely resolve the flakiness but we have to unskip it to know
if it continues to be flaky.
Both tests being unskipped here failed previosly with the following
error:
```
Failure/Error: expect(page).to have_current_path("/u/#{user.username}/preferences/account")
expected "/u/confirm-new-email/f42a416fcbca40d66788d65a8837ad49" to equal "/u/bruce306/preferences/account"
./spec/system/email_change_spec.rb:49:in `block (2 levels) in <main>'
```
The error indicates that the transition was not successful and I
suspect that it may be due to the use of the `/my` route prefix which
is just a nice to have and not necessary.
This might not reduce the failures to zero but some screenshots of the
failures clearly show we were still on the success message page.
Same fix than: https://github.com/discourse/discourse/pull/31750
We're changing the default of hide_email_address_taken to true. This is a trade-off we want to make, as it prevents account enumeration with minimal impact on legitimate users. If you forget you have an account and try to sign up again with the same e-mail you'll receive an e-mail letting you know.
This commit fixes a problem where the user will not be able to reset
their password when they only have security keys and backup codes
configured.
This commit also makes the following changes/fixes:
1. Splits password reset system tests to
`spec/system/forgot_password_spec.rb` instead of missing the system
tests in `spec/system/login_spec.rb` which is mainly used to test
the login flow.
2. Fixes a UX issue where the `Use backup codes` or `Use authenticator
app` text is shown on the reset password form when the user does
not have either backup codes or an authenticator app configured.
We are seeing a weird resolution error on Github actions with the
following backtrace:
```
Failure/Error:
visit File.join(
GlobalSetting.relative_url_root || "",
"/session/#{user.encoded_username}/become.json?redirect=false",
)
Socket::ResolutionError:
getaddrinfo: Temporary failure in name resolution
```
Switch to use `127.0.0.1` instead of forcing a name resolution.
Why this change?
`current_url` does not rely on Capybara waiters so opt to use
`have_current_path` matcher instead. Also assert for email against
element displayed on the page instead of querying the database for it
which isn't really what system tests are meant for.
When making sensitive changes to an account (adding 2FA or passkeys), we
require users to confirm their password. This is to prevent an attacker
from adding 2FA to an account they have access to.
However, on newly created accounts, we should not require this, it's an
extra step and it doesn't provide extra security (since the account was
just created). This commit makes it so that we don't require session
confirmation for accounts created less than 5 minutes ago.
CI runs on slower machines, so we need to use longer wait times. `Capybara.default_max_wait_time` is automatically reconfigured based on the environment.
These routes were previously rendered using Rails, and had a fairly fragile 2fa implementation in vanilla-js. This commit refactors the routes to be handled in the Ember app, removes the custom vanilla-js bundles, and leans on our centralized 2fa implementation. It also introduces a set of system specs for the behavior.
