* FIX: Better error when SSO fails due to blank secret
* Update spec/requests/session_controller_spec.rb
Co-Authored-By: Robin Ward <robin.ward@gmail.com>
* SECURITY: Add confirmation screen when logging in via email link
* SECURITY: Add confirmation screen when logging in via user-api OTP
* FIX: Correct translation key in session controller specs
* FIX: Use .email-login class for page
The impersonate any user by anonymous feature in dev should require a
deliberate opt-in. This way developers are better aware of the security
implications of this development only feature.
This reduces chances of errors where consumers of strings mutate inputs
and reduces memory usage of the app.
Test suite passes now, but there may be some stuff left, so we will run
a few sites on a branch prior to merging
`Upload#url` is more likely and can change from time to time. When it
does changes, we don't want to have to look through multiple tables to
ensure that the URLs are all up to date. Instead, we simply associate
uploads properly to `UserProfile` so that it does not have to replicate
the URLs in the table.
The error displayed when logging into suspended accounts via SSO never includes
the suspension reason, unlike non-SSO logins. By re-using the failed_to_login
method when generating the error message for SSO we can ensure the message is
consistent between the SSO and non-SSO paths.
In some SSO implementations we may want to issue SSO pipelines for
already logged on users
In these cases do not re-log-in a user if they are clearly logged on
This splits off the logic between SSO keys used incoming vs outgoing, it allows to far better restrict who is allowed to log in using a site.
This allows for better auditing of the SSO provider feature
implemented review items.
Blocking previous codes - valid 2-factor auth tokens can only be authenticated once/30 seconds.
I played with updating the “last used” any time the token was attempted but that seemed to be overkill, and frustrating as to why a token would fail.
Translatable texts.
Move second factor logic to a helper class.
Move second factor specific controller endpoints to its own controller.
Move serialization logic for 2-factor details in admin user views.
Add a login ember component for de-duplication
Fix up code formatting
Change verbiage of google authenticator
add controller tests:
second factor controller tests
change email tests
change password tests
admin login tests
add qunit tests - password reset, preferences
fix: check for 2factor on change email controller
fix: email controller - only show second factor errors on attempt
fix: check against 'true' to enable second factor.
Add modal for explaining what 2fa with links to Google Authenticator/FreeOTP
add two factor to email signin link
rate limit if second factor token present
add rate limiter test for second factor attempts
* Email and username are both allowed to be used for logging in.
Therefore, it is easier to just store the user's id rather than
to store the username and email in the session.
- All unsubscribes go to the exact same page
- You may unsubscribe from watching a category on that page
- You no longer need to be logged in to unsubscribe from a topic
- Simplified footer on emails
This commit introduces 3 queues for sidekiq
"critical" for urgent jobs (weighted at 4x weight)
"default" for standard jobs(weighted at 2x weight)
"low" for less important jobs
"critical jobs"
Reset Password emails has been seperated to its own job
Heartbeat which is required to keep sidekiq running
Test email which needs to return real quick
"low priority jobs"
Notify mailing list
Pull hotlinked images
Update gravatar
"default"
All the rest
Note: for people running sidekiq from command line use
bin/sidekiq -q critical,4 -q default,2 -q low
500 status codes are for unexpected server-side error scenarios. When an expired nonce is used by the client, a 4XX-level error is more appropriate because the client has submitted a bad request (by using an expired nonce). A 500 also causes Internet Explorer to show its default 500 page which does not show the error message and leads to a bad end user experience. I am choosing 400 for the new status rather than 401 or 403 because 401 requires a WWW-Authenticate header which would be difficult to generate in an SSO scenario and a 403 implies that no re-authentication will address the failure.
This security fix needs SSO to be configured, and the user has to go
through the entire auth process before being redirected to the wrong host so
it is probably lower priority for most installs.