Commit Graph

82 Commits

Author SHA1 Message Date
Krzysztof Kotlarek
a1d2c46d28
FIX: increase secure session for OAuth expiration time (#27674)
By default, secure sessions expire after 1 hour.
For OAuth authentication it should expire at the same time when the authentication cookie expires - `SiteSetting.maximum_session_age.hours`.

It is possible that the forum will not have persistent sessions, based on `persistent_sessions` site setting. In that case, with next username and password authentication we need to reset information about OAuth.

Bug introduced in this PR - https://github.com/discourse/discourse/pull/27547
2024-07-02 11:43:59 +10:00
Martin Brennan
706e074e6c
DEV: Check for "true" in oauth check for 2FA (#27587)
Followup to 0e1102b332

Minor followup, makes the condition check against the
boolean val, see the difference here:

```ruby
!SiteSetting.enforce_second_factor_on_external_auth && "true"
=> "true"
```

vs:

```ruby
!SiteSetting.enforce_second_factor_on_external_auth && "true" == "true"
=> true
```
2024-06-24 14:19:32 +10:00
Krzysztof Kotlarek
0e1102b332
FIX: do not force configure 2FA when OAuth and not enforced (#27547)
In this PR we introduced `enforce_second_factor_on_external_auth` setting https://github.com/discourse/discourse/pull/27506

When it is set to false and the user is authenticated via OAuth, then we should not enforce the 2fa configuration.
2024-06-20 11:49:46 +10:00
Krzysztof Kotlarek
cc4c199680
FEATURE: optional 2FA enforcement (#27506)
A new admin setting called `enforce_second_factor_on_external_auth`. It allows users to authenticate using external providers even when 2FA is forced with `enforce_second_factor` site setting.
2024-06-19 09:32:30 +10:00
Ted Johansson
32aaf2e8d3
DEV: Remove deprecated AuthProvider#enabled_setting= (#27081)
AuthProvider#enabled_setting=, used primarily by plugins, has been deprecated since version 2.9, in favour of Authenticator#enabled?. This PR confirms we are seeing no more usage and removes the method.
2024-05-20 18:10:15 +08:00
Alan Guo Xiang Tan
50bafd48cd
FIX: Flaky spec due to incorrect Rack response body (#24640)
Why was the problem?

ActiveRecord's query cache for the connection pool wasn't disabled after the
`with a fake provider runs 'other_phase' for enabled auth methods` test
in `omniauth_callbacks_controller_spec.rb` was run. This was because the
Rack response body in `FakeAuthenticator::Strategy::other_phase` did not
adhere to the expected Rack body format which is "typically an Array of
String instances". Because this expectation was broken, it cascaded the
problem down where it resulted in the ActiveRecord's query cache for the
connection pool not being disabled as it normally should when the
response body is closed.

When the query cache is left enabled, common assertions pattern in RSpec
like `expect { something }.to change { Group.count }` will fail since
the query cache is enabled and the call first call to `Group.count` will
cache the result to be reused later on.

To see the bug in action, one can run the following command:

`bundle exec rspec --seed 44747
spec/requests/omniauth_callbacks_controller_spec.rb:1150
spec/models/group_spec.rb:283`
2023-11-30 10:49:55 +08:00
David Taylor
91fe91e03b
DEV: Properly cleanup auth providers in test (#24482)
Followup to 5c38e55dc9
2023-11-21 10:45:51 +00:00
Daniel Waterworth
6e161d3e75
DEV: Allow fab! without block (#24314)
The most common thing that we do with fab! is:

    fab!(:thing) { Fabricate(:thing) }

This commit adds a shorthand for this which is just simply:

    fab!(:thing)

i.e. If you omit the block, then, by default, you'll get a `Fabricate`d object using the fabricator of the same name.
2023-11-09 16:47:59 -06:00
David Taylor
5c38e55dc9
DEV: Only run omniauth strategies for enabled authenticators (#24094)
Previously, we would build the stack of omniauth authenticators once on boot. That meant that all strategies had to be included, even if they were disabled. We then used the `before_request_phase` to ensure disabled strategies could not be used. This works well, but it means that omniauth is often doing unnecessary work running logic in disabled strategies.

This commit refactors things so that we build the stack of strategies on each request. That means we only need to include the enabled strategies in the stack - disabled strategies are totally ignored. Building the stack on-demand like this does add some overhead to auth requests, but on the majority of sites that will be significantly outweighed by the fact we're now skipping logic for disabled authenticators.

As well as the slight performance improvement, this new approach means that:

- Broken (i.e. exception-raising) strategies cannot cause issues on a site if they're disabled

- `other_phase` of disabled strategies will never appear in the backtrace of other authentication errors
2023-10-25 13:52:33 +01:00
David Taylor
cb932d6ee1
DEV: Apply syntax_tree formatting to spec/* 2023-01-09 11:49:28 +00:00
David Taylor
e0a6d12c55
Use service account credentials for fetching google hd groups (#18329)
The previous implementation would attempt to fetch groups using the end-user's Google auth token. This only worked for admin accounts, or users with 'delegated' access to the `admin.directory.group.readonly` API.

This commit changes the approach to use a single 'service account' for fetching the groups. This removes the need to add permissions to all regular user accounts. I'll be updating the [meta docs](https://meta.discourse.org/t/226850) with instructions on setting up the service account.

This is technically a breaking change in behavior, but the existing implementation was marked experimental, and is currently unusable in production google workspace environments.
2022-10-13 16:04:42 +01:00
Loïc Guitaut
3eaac56797 DEV: Use proper wording for contexts in specs 2022-08-04 11:05:02 +02:00
Daniel Waterworth
6e53f4d913
DEV: New readonly mode. Only applies to non-staff (#16243) 2022-05-17 13:06:08 -05:00
Daniel Waterworth
66a04c5cfe
FIX: Prevent all kinds of login in readonly mode (#16743) 2022-05-13 10:52:01 -05:00
David Taylor
0f772bdf5b
FEATURE: Optionally skip using full_name when suggesting usernames (#16592)
This commit introduces a new site setting: `use_name_for_username_suggestions` (default true)

Admins can disable it if they want to stop using Name values when generating usernames for users. This can be useful if you want to keep real names private-by-default or, when used in conjunction with the `use_email_for_username_and_name_suggestions` setting, you would prefer to use email-based username suggestions.
2022-04-29 14:00:13 +01:00
David Taylor
c9dab6fd08
DEV: Automatically require 'rails_helper' in all specs (#16077)
It's very easy to forget to add `require 'rails_helper'` at the top of every core/plugin spec file, and omissions can cause some very confusing/sporadic errors.

By setting this flag in `.rspec`, we can remove the need for `require 'rails_helper'` entirely.
2022-03-01 17:50:50 +00:00
Andrei Prigorshnev
404f882e5c
FEATURE: in result.rb don't use email for username suggestions until enabled in settings (#15586) 2022-02-07 16:02:26 +04:00
David Taylor
820564826e
FIX: Ensure that login does not fail for users with invite records (#15647)
In the unlikely, but possible, scenario where a user has no email_tokens, and has an invite record for their email address, login would fail. This commit fixes the `Invite` `user_doesnt_already_exist` validation so that it only applies to new invites, or when changing the email address.

This regressed in d8fe0f4199 (based on `git bisect`)
2022-01-20 10:54:38 +00:00
Andrei Prigorshnev
16d9b2755c
DEV: rename single_sign_on classes to discourse_connect (#15332) 2022-01-06 16:28:46 +04:00
David Taylor
cdf4d7156e
DEV: Introduce Auth::Result API for overrides_* (#15378)
This allows authenticators to instruct the Auth::Result to override attributes without using the general site settings. This provides an easy migration path for auth plugins which offer their own "overrides email", "overrides username" or "overrides name" settings. With this new api, they can set `overrides_*` on the result object, and the attribute will be overriden regardless of the general site setting.

ManagedAuthenticator is updated to use this new API. Plugins which consume ManagedAuthenticator will instantly take advantage of this change.
2021-12-23 10:53:17 +00:00
Andrei Prigorshnev
9365c4b364
DEV: make sure we handle staged users correctly in DiscourseConnect (#15320)
Some time ago, we made this fix to external authentication –  https://github.com/discourse/discourse/pull/13706. We didn't address Discourse Connect (https://meta.discourse.org/t/discourseconnect-official-single-sign-on-for-discourse-sso/13045) at that moment, so I wanted to fix it for Discourse Connect as well.

Turned out though that Discourse Connect doesn't contain this problem and already handles staged users correctly. This PR adds tests that confirm it. Also, I've extracted two functions in Discourse Connect implementation along the way and decided to merge this refactoring too (the refactoring is supported with tests).
2021-12-16 19:44:07 +04:00
Angus McLeod
df3886d6e5
FEATURE: Experimental support for group membership via google auth (#14835)
This commit introduces a new site setting "google_oauth2_hd_groups". If enabled, group information will be fetched from Google during authentication, and stored in the Discourse database. These 'associated groups' can be connected to a Discourse group via the "Membership" tab of the group preferences UI. 

The majority of the implementation is generic, so we will be able to add support to more authentication methods in the near future.

https://meta.discourse.org/t/managing-group-membership-via-authentication/175950
2021-12-09 12:30:27 +00:00
Andrei Prigorshnev
77cca39c2d
DEV: dry up omni_auth_callback_controller_spec (#15213) 2021-12-07 23:06:44 +04:00
Andrei Prigorshnev
f3508065a3
FIX: auth incorrectly handles duplicate usernames (#15197) 2021-12-06 20:49:04 +04:00
Andrei Prigorshnev
10cc082560
FIX: when using external auth disallowed characters weren't removed from username (#15185) 2021-12-06 15:06:35 +04:00
David Taylor
7dc8f8b794 FEATURE: Allow linking an existing account during external-auth signup
When a user signs up via an external auth method, a new link is added to the signup modal which allows them to connect an existing Discourse account. This will only happen if:

- There is at least 1 other auth method available

and

- The current auth method permits users to disconnect/reconnect their accounts themselves
2021-08-10 15:07:40 +01:00
Dan Ungureanu
49090c3524
FIX: Suggest current username for staged users (#13706)
If user had a staged account and logged in using a third party service
a different username was suggested. This change will try to use the
username given by the authentication provider first, then the current
staged username and last suggest a new one.
2021-07-13 09:15:06 +10:00
David Taylor
a1e5a6bbe0
DEV: Remove fsl cookie from specs (#13657)
This cookie has not been used for a number of years, and has no effect. This commit removes it from the specs. (diff is almost entirely whitespace)
2021-07-07 10:54:18 +01:00
David Taylor
198c960b52
FIX: Handle staged users as unregistered users for external auth (#12567)
For 'local logins', the UX for staged users is designed to be identical to unregistered users. However, staged users logging in via external auth were being automatically unstaged, and skipping the registration/invite flow. In the past this made sense because the registration/invite flows didn't work perfectly with external auth. Now, both registration and invites work well with external auth, so it's best to leave the 'unstage' logic to those endpoints.

This problem was particularly noticeable when using the 'bulk invite' feature to invite users with pre-configured User Fields. In that situation, staged user accounts are used to preserve the user field data.
2021-03-31 13:40:58 +01:00
Dan Ungureanu
dce48d8aa7
FIX: Redirect to provided origin after auth (#12558)
It used to redirect to the destination_url cookie which sometimes is set
incorrectly.
2021-03-31 10:23:12 +01:00
Alan Guo Xiang Tan
ce04db8610 FEATURE: Allow invites redemption with Omniauth providers. 2021-03-09 09:27:18 +08:00
David Taylor
821bb1e8cb
FEATURE: Rename 'Discourse SSO' to DiscourseConnect (#11978)
The 'Discourse SSO' protocol is being rebranded to DiscourseConnect. This should help to reduce confusion when 'SSO' is used in the generic sense.

This commit aims to:
- Rename `sso_` site settings. DiscourseConnect specific ones are prefixed `discourse_connect_`. Generic settings are prefixed `auth_`
- Add (server-side-only) backwards compatibility for the old setting names, with deprecation notices
- Copy `site_settings` database records to the new names
- Rename relevant translation keys
- Update relevant translations

This commit does **not** aim to:
- Rename any Ruby classes or methods. This might be done in a future commit
- Change any URLs. This would break existing integrations
- Make any changes to the protocol. This would break existing integrations
- Change any functionality. Further normalization across DiscourseConnect and other auth methods will be done separately

The risks are:
- There is no backwards compatibility for site settings on the client-side. Accessing auth-related site settings in Javascript is fairly rare, and an error on the client side would not be security-critical.
- If a plugin is monkey-patching parts of the auth process, changes to locale keys could cause broken error messages. This should also be unlikely. The old site setting names remain functional, so security-related overrides will remain working.

A follow-up commit will be made with a post-deploy migration to delete the old `site_settings` rows.
2021-02-08 10:04:33 +00:00
David Taylor
20c0da8516
FIX: Improve email validation error handling for external logins (#11307)
- Display reason for validation error when logging in via an authenticator
- Fix email validation handling for 'Discourse SSO', and add a spec

Previously, validation errors (e.g. blocked or already-taken emails) would raise a generic error with no useful information.
2020-11-23 11:06:08 +00:00
David Taylor
dc005c593e
DEV: Introduce :before_auth DiscourseEvent (#11233)
This is useful for plugins to manipulate the auth hash from OmniAuth before it is read by the Authenticator class
2020-11-13 14:41:54 +00:00
David Taylor
4351fa435e
FIX: Correctly redirect after external login on subfolder sites (#10529) 2020-08-26 15:52:21 +01:00
David Taylor
977766e7a8
FEATURE: sso_overrides_(email|username|name) for all auth methods
These settings previously applied only to discourse-sso. Now they work for all external authentication methods.
2020-07-06 10:18:45 +01:00
Jarek Radosz
781e3f5e10
DEV: Use response.parsed_body in specs (#9615)
Most of it was autofixed with rubocop-discourse 2.1.1.
2020-05-07 17:04:12 +02:00
Jeff Wong
3189dab622 FIX: correctly remove authentication_data cookie on oauth login flow
Additionally correctly handle cookie path for authentication_data

There were two bugs that exposed an interesting case where two discourse
instances hosted across two subfolder installs in the same domain
with oauth may clash and cause strange redirection on first login:

Log in to example.com/forum1. authentication_data cookie is set with path /
On the first redirection, the current authentication_data cookie is not unset.
Log in to example.com/forum2. In this case, the authentication_data cookie
is already set from forum1 - the initial page load will incorrectly redirect
the user to the redirect URL from the already-stored cookie, to /forum1.

This removes this issue by:

* Setting the cookie for the correct path, and not having it on root
* Correctly removing the cookie on first login
2020-03-21 14:34:25 -07:00
Jeff Wong
4ecc0a25ae Revert "FIX: correctly remove authentication_data cookie on oauth login flow (#9238) (#9251)"
This reverts commit beaeb0c4b2.
2020-03-20 14:37:55 -07:00
Jeff Wong
beaeb0c4b2
FIX: correctly remove authentication_data cookie on oauth login flow (#9238) (#9251)
Attempt 2, with more test.

Additionally correctly handle cookie path for authentication_data

There were two bugs that exposed an interesting case where two discourse
instances hosted across two subfolder installs in the same domain
with oauth may clash and cause strange redirection on first login:

Log in to example.com/forum1. authentication_data cookie is set with path /
On the first redirection, the current authentication_data cookie is not unset.
Log in to example.com/forum2. In this case, the authentication_data cookie
is already set from forum1 - the initial page load will incorrectly redirect
the user to the redirect URL from the already-stored cookie, to /forum1.

This removes this issue by:

Setting the cookie for the correct path, and not having it on root
Correctly removing the cookie on first login
2020-03-20 14:03:38 -07:00
Robin Ward
0d3386d255 Revert "FIX: correctly remove authentication_data cookie on oauth login flow (#9238)"
This reverts commit a1f9b1a7fc.

This might have caused a problem with social logins. We are confirming
via this revert and will follow up.
2020-03-20 15:25:10 -04:00
Jeff Wong
a1f9b1a7fc
FIX: correctly remove authentication_data cookie on oauth login flow (#9238)
Additionally correctly handle cookie path for authentication_data

There were two bugs that exposed an interesting case where two discourse
instances hosted across two subfolder installs in the same domain
with oauth may clash and cause strange redirection on first login:

Log in to example.com/forum1. authentication_data cookie is set with path /
On the first redirection, the current authentication_data cookie is not unset.
Log in to example.com/forum2. In this case, the authentication_data cookie
is already set from forum1 - the initial page load will incorrectly redirect
the user to the redirect URL from the already-stored cookie, to /forum1.

This removes this issue by:
* Setting the cookie for the correct path, and not having it on root
* Correctly removing the cookie on first login
2020-03-19 09:00:46 -07:00
Martin Brennan
97d8f19387
FIX: When admin changes another user's email auto-confirm the change (#9001)
When admin changes a user's email from the preferences page of that user:

* The user will not be sent an email to confirm that their
  email is changing. They will be sent a reset password email
  so they can set the password for their account at the new
  email address.
* The user will still be sent an email to their old email to inform
  them that it was changed.
* Admin and staff users still need to follow the same old + new
  confirm process, as do users changing their own email.
2020-02-20 09:52:21 +10:00
Martin Brennan
66f2db4ea4 SECURITY: 2FA with U2F / TOTP 2020-01-15 11:27:12 +01:00
David Taylor
5eda44f8f2 FIX: Do not redirect to /auth/* urls after authentication
When using the login confirmation screen, the referrer URL is `/auth/{provider}`. That means that the user is redirected back to the confirmation screen after logging in, even though login was successful. This is very confusing. Instead, they should be redirected to the homepage.
2020-01-08 17:06:03 +00:00
Dan Ungureanu
ae9e881333
DEV: Add test to ensure :after_auth event is triggered (#8400)
Follow-up to ee8669d778.
2019-11-25 14:31:57 +02:00
David Taylor
d2bceff133
FEATURE: Use full page redirection for all external auth methods (#8092)
Using popups is becoming increasingly rare. Full page redirects are already used on mobile, and for some providers. This commit removes all logic related to popup authentication, leaving only the full page redirect method.

For more info, see https://meta.discourse.org/t/do-we-need-popups-for-login/127988
2019-10-08 12:10:43 +01:00
Krzysztof Kotlarek
427d54b2b0 DEV: Upgrading Discourse to Zeitwerk (#8098)
Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains. 

We no longer need to use Rails "require_dependency" anywhere and instead can just use standard 
Ruby patterns to require files.

This is a far reaching change and we expect some followups here.
2019-10-02 14:01:53 +10:00
David Taylor
a5e198fa30 SECURITY: Reset password when activating an account via auth provider
Followup to d693b4e35fe0e58c5578eae4a56c06dff4756ba2
2019-08-28 14:07:07 +01:00
David Taylor
9878bc62b3 Revert "Merge pull request from GHSA-7cmh-wm9h-j63f"
This reverts commit 8e5a8d1d54. The change will be re-applied with improvements.
2019-08-28 14:07:03 +01:00