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.
