- Jul 25, 2023
-
-
Matt Jankowski authored
-
- Jul 24, 2023
-
-
Claire authored
-
- Jul 12, 2023
-
-
Matt Jankowski authored
-
- Jul 02, 2023
- Jun 14, 2023
-
-
Eugen Rochko authored
-
- May 22, 2023
-
-
Frankie Roberto authored
-
- May 16, 2023
-
-
Claire authored
-
- Apr 30, 2023
-
-
Matt Jankowski authored
-
- Apr 19, 2023
-
-
Eugen Rochko authored
-
- Apr 16, 2023
-
-
Eugen Rochko authored
-
- Mar 31, 2023
-
-
Claire authored
-
- Mar 12, 2023
-
-
CSDUMMI authored
-
- Feb 20, 2023
-
-
Nick Schonning authored
-
- Feb 18, 2023
-
-
Nick Schonning authored
-
- Dec 15, 2022
-
-
David Vega authored
Co-authored-by:
petrokoriakin1 <116151189+petrokoriakin1@users.noreply.github.com> Co-authored-by:
petrokoriakin1 <116151189+petrokoriakin1@users.noreply.github.com> Co-authored-by:
Effy Elden <effy@effy.space>
-
Francis Murillo authored
* Clear sessions on password change * Rename User::clear_sessions to revoke_access for a clearer meaning * Add reset paassword controller test * Use User.find instead of User.find_for_authentication for reset password test * Use redirect and render for better test meaning in reset password Co-authored-by:
Effy Elden <effy@effy.space>
-
- Nov 17, 2022
-
-
Claire authored
-
- Nov 16, 2022
-
-
Daniel Axtens authored
Several controlers set quite intricate Cache-Control headers in order to hopefully not be cached by any intermediate proxies or local caches. Unfortunately, these headers are processed by ActionDispatch::HTTP::Cache in a way that squashes and discards any values set alongside no-store other than private: https://github.com/rails/rails/blob/8015c2c2cf5c8718449677570f372ceb01318a32/actionpack/lib/action_dispatch/http/cache.rb#L207-L209 We want to preserve no-store on these responses, but we might as well remove parts that are going to be dropped anyway. As many of the endpoints in these controllers are private to a particular user, we should also add "private", which will be preserved alongside no-store.
-
- Nov 07, 2022
-
-
Claire authored
Fixes #19913
-
- Oct 30, 2022
-
-
Claire authored
Fixes #19507 Fix regression from #19296
-
- Oct 05, 2022
-
-
Eugen Rochko authored
-
- Aug 24, 2022
-
-
Eugen Rochko authored
-
- Jun 21, 2022
-
-
Claire authored
* Add tests * Fix suspicious sign-in mails never being sent
-
- May 26, 2022
-
-
Eugen Rochko authored
-
- Apr 06, 2022
-
-
Eugen Rochko authored
-
- Mar 09, 2022
-
-
chandrn7 authored
* added OpenID Connect as an SSO option * minor fixes * added comments, removed an option that shouldn't be set * fixed Gemfile.lock * added newline to end of Gemfile.lock * removed tab from Gemfile.lock * remove chomp * codeclimate changes and small name change to make function's purpose clearer * codeclimate fix * added SSO buttons to /about page * minor refactor * minor style change * removed spurious change * removed unecessary conditional from ensure_valid_username and added support for auth.info.name in user_params_from_auth * minor changes
-
- Mar 01, 2022
-
-
Claire authored
* Change old moderation strikes to be displayed in a separate page Fixes #17552 This changes the moderation strikes displayed on `/auth/edit` to be those from the past 3 months, and make all moderation strikes targeting the current user available in `/disputes`. * Add short description of what the strikes page is for * Move link to list of strikes to “Account status” instead of navigation item * Normalize i18n file * Fix layout and styling of strikes link * Revert highlights_on regexp * Reintroduce account status summary - this way, “Account status” is never empty - account status is not necessarily bound to strikes, or recent strikes
-
- Feb 14, 2022
-
-
Eugen Rochko authored
* Add appeals * Add ability to reject appeals and ability to browse pending appeals in admin UI * Add strikes to account page in settings * Various fixes and improvements - Add separate notification setting for appeals, separate from reports - Fix style of links in report/strike header - Change approving an appeal to not restore statuses (due to federation complexities) - Change style of successfully appealed strikes on account settings page - Change account settings page to only show unappealed or recently appealed strikes * Change appealed_at to overruled_at * Fix missing method error
-
- Jan 23, 2022
-
-
Claire authored
* Remove support for OAUTH_REDIRECT_AT_SIGN_IN Fixes #15959 Introduced in #6540, OAUTH_REDIRECT_AT_SIGN_IN allowed skipping the log-in form to instead redirect to the external OmniAuth login provider. However, it did not prevent the log-in form on /about introduced by #10232 from appearing, and completely broke with the introduction of #15228. As I restoring that previous log-in flow without introducing a security vulnerability may require extensive care and knowledge of how OmniAuth works, this commit removes support for OAUTH_REDIRECT_AT_SIGN_IN instead for the time being. * Add OMNIAUTH_ONLY environment variable to enforce external log-in only * Disable user registration when OMNIAUTH_ONLY is set to true * Replace log-in links When OMNIAUTH_ONLY is set with exactly one OmniAuth provider
-
Claire authored
Fixes #15959 Introduced in #6540, OAUTH_REDIRECT_AT_SIGN_IN allowed skipping the log-in form to instead redirect to the external OmniAuth login provider. However, it did not prevent the log-in form on /about introduced by #10232 from appearing, and completely broke with the introduction of #15228. As I restoring that previous log-in flow without introducing a security vulnerability may require extensive care and knowledge of how OmniAuth works, this commit removes support for OAUTH_REDIRECT_AT_SIGN_IN instead for the time being.
-
- Jan 16, 2022
-
-
Eugen Rochko authored
-
- Nov 05, 2021
-
-
Claire authored
Up until now, we have used Devise's Rememberable mechanism to re-log users after the end of their browser sessions. This mechanism relies on a signed cookie containing a token. That token was stored on the user's record, meaning it was shared across all logged in browsers, meaning truly revoking a browser's ability to auto-log-in involves revoking the token itself, and revoking access from *all* logged-in browsers. We had a session mechanism that dynamically checks whether a user's session has been disabled, and would log out the user if so. However, this would only clear a session being actively used, and a new one could be respawned with the `remember_user_token` cookie. In practice, this caused two issues: - sessions could be revived after being closed from /auth/edit (security issue) - auto-log-in would be disabled for *all* browsers after logging out from one of them This PR removes the `remember_token` mechanism and treats the `_session_id` cookie/token as a browser-specific `remember_token`, fixing both issues.
-
- Sep 30, 2021
-
-
Claire authored
* Add tests * Fix webauthn secure key authentication Fixes #16769
-
- Aug 26, 2021
-
-
Truong Nguyen authored
-
- Aug 25, 2021
-
-
Claire authored
* Add tests * Add security-related tests My first (unpublished) attempt at fixing the issues introduced (extremely hard-to-exploit) security vulnerabilities, addressing them in a test. * Fix authentication failures after going halfway through a sign-in attempt * Refactor `authenticate_with_sign_in_token` and `authenticate_with_two_factor` to make the two authentication steps more obvious
-
Daniel authored
The addition of authentication history broke the omniauth login with the following error: method=GET path=/auth/auth/cas/callback format=html controller=Auth::OmniauthCallbacksController action=cas status=500 error='NameError: undefined local variable or method `user' for #<Auth::OmniauthCallbacksController:0x00000000036290> Did you mean? @user' duration=435.93 view=0.00 db=36.19 * app/controllers/auth/omniauth_callbacks_controller.rb: fix variable name to `@user`
-
- Jun 21, 2021
-
-
Eugen Rochko authored
-
- May 03, 2021
-
-
Claire authored
Clicking the confirmation link multiple times currently leads to entering account settings, which can be confusing. This commit changes that so that it redirects to the root path, so it behaves the same way as clicking only once in most cases.
-
- Dec 10, 2020
-
-
ThibG authored
* Add honeypot fields to limit non-specialized spam Add two honeypot fields: a fake website input and a fake password confirmation one. The label/placeholder/aria-label tells not to fill them, and they are hidden in CSS, so legitimate users should not fall into these. This should cut down on some non-Mastodon-specific spambots. * Require a 3 seconds delay before submitting the registration form * Fix tests * Move registration form time check to model validation * Give people a chance to clear the honeypot fields * Refactor honeypot translation strings Co-authored-by:
Claire <claire.github-309c@sitedethib.com>
-