Changes to functionality
- Removed syncing of user metadata including gender, location etc.
These are no longer available to standard Facebook applications.
- Removed the remote 'revoke' functionality. No other providers have
it, and it does not appear to be standard practice in other apps.
- The 'facebook_no_email' event is no longer logged. The system can
cope fine with a missing email address.
Data is migrated to the new user_associated_accounts table.
facebook_user_infos can be dropped once we are confident the data has
been migrated successfully.
A generic implementation of Auth::Authenticator which stores data in the
new UserAssociatedAccount model. This should help significantly reduce the duplicated
logic across different auth providers.
* When an error is raised when checking route constraints, we
can only return true/false which either lets the request
through or return a 404 error. Therefore, we just skip
rate limiting here and let the controller handle the
rate limiting.
This fix ensures that users that are signing up via google oauth are
automatically added to any groups.
A similar fix will probably need to be added to other oauth providers.
- avoid access denied on bad cookie, instead just nuke it
- avoid marking a token unseen for first minute post rotation
- log path in user auth token logs
Defaults to Lax, can be disabled or set to Strict.
Strict will only work if you require login and use SSO. Otherwise when clicking on links to your site you will appear logged out till you refresh the page.
It appears that in some cases ios queues up requests up front
and "releases" them when tab gets focus, this allows for a certain
number of cookie misses for this case. Otherwise you get logged off.
Revamped system for managing authentication tokens.
- Every user has 1 token per client (web browser)
- Tokens are rotated every 10 minutes
New system migrates the old tokens to "legacy" tokens,
so users still remain logged on.
Also introduces weekly job to expire old auth tokens.
previously we supported blanket read and write for user API, this
change amends it so we can define more limited scopes. A scope only
covers a few routes. You can not grant access to part of the site and
leave a large amount of the information hidden to API consumer.
If a site is configured for GitHub logins, _**and**_ has an email domain
whitelist, it's possible to get in a state where a new user is locked to
a non-whitelist email (their GitHub primary) even though they have an
alternate email that's on the whitelist. In all cases, the GitHub
primary email is attempted first so that previously existing behavior
will be the default.
- Add whitelist/blacklist support to GithubAuthenticator (via
EmailValidator)
- Add multiple email support GithubAuthenticator
- Add test specs for GithubAuthenticator
- Add authenticator-agnostic "none of your email addresses are allowed"
error message.
This feature ensures session cookie lifespan is extended
when user is online.
Also decreases session timeout from 90 to 60 days.
Ensures all users (including logged on ones) get expiring sessions.
Since rspec-rails 3, the default installation creates two helper files:
* `spec_helper.rb`
* `rails_helper.rb`
`spec_helper.rb` is intended as a way of running specs that do not
require Rails, whereas `rails_helper.rb` loads Rails (as Discourse's
current `spec_helper.rb` does).
For more information:
https://www.relishapp.com/rspec/rspec-rails/docs/upgrade#default-helper-files
In this commit, I've simply replaced all instances of `spec_helper` with
`rails_helper`, and renamed the original `spec_helper.rb`.
This brings the Discourse project closer to the standard usage of RSpec
in a Rails app.
At present, every spec relies on loading Rails, but there are likely
many that don't need to. In a future pull request, I hope to introduce a
separate, minimal `spec_helper.rb` which can be used in tests which
don't rely on Rails.
