Skip to content
Snippets Groups Projects
  1. Nov 23, 2020
  2. Nov 19, 2020
  3. Nov 10, 2020
  4. Oct 22, 2020
  5. Oct 21, 2020
    • ThibG's avatar
      Add follower synchronization mechanism (#14510) · ca565271
      ThibG authored
      * Add support for followers synchronization on the receiving end
      
      Check the `collectionSynchronization` attribute on `Create` and `Announce`
      activities and synchronize followers from provided collection if possible.
      
      * Add tests for followers synchronization on the receiving end
      
      * Add support for follower synchronization on the sender's end
      
      * Add tests for the sending end
      
      * Switch from AS attributes to HTTP header
      
      Replace the custom `collectionSynchronization` ActivityStreams attribute by
      an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as
      the `Signature` header and the following fields:
      - `collectionId` to specify which collection to synchronize
      - `digest` for the SHA256 hex-digest of the list of followers known on the
         receiving instance (where “receiving instance” is determined by accounts
         sharing the same host name for their ActivityPub actor `id`)
      - `url` of a collection that should be fetched by the instance actor
      
      Internally, move away from the webfinger-based `domain` attribute and use
      account `uri` prefix to group accounts.
      
      * Add environment variable to disable followers synchronization
      
      Since the whole mechanism relies on some new preconditions that, in some
      extremely rare cases, might not be met, add an environment variable
      (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and
      avoid followers being incorrectly removed.
      
      The current conditions are:
      1. all managed accounts' actor `id` and inbox URL have the same URI scheme and
         netloc.
      2. all accounts whose actor `id` or inbox URL share the same URI scheme and
         netloc as a managed account must be managed by the same Mastodon instance
         as well.
      
      As far as Mastodon is concerned, breaking those preconditions require extensive
      configuration changes in the reverse proxy and might also cause other issues.
      
      Therefore, this environment variable provides a way out for people with highly
      unusual configurations, and can be safely ignored for the overwhelming majority
      of Mastodon administrators.
      
      * Only set follower synchronization header on non-public statuses
      
      This is to avoid unnecessary computations and allow Follow-related
      activities to be handled by the usual codepath instead of going through
      the synchronization mechanism (otherwise, any Follow/Undo/Accept activity
      would trigger the synchronization mechanism even if processing the activity
      itself would be enough to re-introduce synchronization)
      
      * Change how ActivityPub::SynchronizeFollowersService handles follow requests
      
      If the remote lists a local follower which we only know has sent a follow
      request, consider the follow request as accepted instead of sending an Undo.
      
      * Integrate review feeback
      
      - rename X-AS-Collection-Synchronization to Collection-Synchronization
      - various minor refactoring and code style changes
      
      * Only select required fields when computing followers_hash
      
      * Use actor URI rather than webfinger domain in synchronization endpoint
      
      * Change hash computation to be a XOR of individual hashes
      
      Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues.
      
      * Marginally improve followers_hash computation speed
      
      * Further improve hash computation performances by using pluck_each
      ca565271
  6. Oct 13, 2020
  7. Oct 07, 2020
    • Eugen Rochko's avatar
      Remove dependency on goldfinger gem (#14919) · 7d985f2a
      Eugen Rochko authored
      There are edge cases where requests to certain hosts timeout when
      using the vanilla HTTP.rb gem, which the goldfinger gem uses. Now
      that we no longer need to support OStatus servers, webfinger logic
      is so simple that there is no point encapsulating it in a gem, so
      we can just use our own Request class. With that, we benefit from
      more robust timeout code and IPv4/IPv6 resolution.
      
      Fix #14091
      7d985f2a
  8. Oct 06, 2020
  9. Sep 29, 2020
  10. Sep 22, 2020
  11. Sep 21, 2020
  12. Sep 16, 2020
  13. Sep 14, 2020
  14. Sep 07, 2020
  15. Sep 01, 2020
  16. Aug 25, 2020
  17. Aug 24, 2020
    • santiagorodriguez96's avatar
      Add WebAuthn as an alternative 2FA method (#14466) · e8d41bc2
      santiagorodriguez96 authored
      
      * feat: add possibility of adding WebAuthn security keys to use as 2FA
      
      This adds a basic UI for enabling WebAuthn 2FA. We did a little refactor
      to the Settings page for editing the 2FA methods – now it will list the
      methods that are available to the user (TOTP and WebAuthn) and from
      there they'll be able to add or remove any of them.
      Also, it's worth mentioning that for enabling WebAuthn it's required to
      have TOTP enabled, so the first time that you go to the 2FA Settings
      page, you'll be asked to set it up.
      This work was inspired by the one donde by Github in their platform, and
      despite it could be approached in different ways, we decided to go with
      this one given that we feel that this gives a great UX.
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      
      * feat: add request for WebAuthn as second factor at login if enabled
      
      This commits adds the feature for using WebAuthn as a second factor for
      login when enabled.
      If users have WebAuthn enabled, now a page requesting for the use of a
      WebAuthn credential for log in will appear, although a link redirecting
      to the old page for logging in using a two-factor code will also be
      present.
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      
      * feat: add possibility of deleting WebAuthn Credentials
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      
      * feat: disable WebAuthn when an Admin disables 2FA for a user
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      
      * feat: remove ability to disable TOTP leaving only WebAuthn as 2FA
      
      Following examples form other platforms like Github, we decided to make
      Webauthn 2FA secondary to 2FA with TOTP, so that we removed the
      possibility of removing TOTP authentication only, leaving users with
      just WEbAuthn as 2FA. Instead, users will have to click on 'Disable 2FA'
      in order to remove second factor auth.
      The reason for WebAuthn being secondary to TOPT is that in that way,
      users will still be able to log in using their code from their phone's
      application if they don't have their security keys with them – or maybe
      even lost them.
      
      * We had to change a little the flow for setting up TOTP, given that now
        it's possible to setting up again if you already had TOTP, in order to
        let users modify their authenticator app – given that now it's not
        possible for them to disable TOTP and set it up again with another
        authenticator app.
        So, basically, now instead of storing the new `otp_secret` in the
        user, we store it in the session until the process of set up is
        finished.
        This was because, as it was before, when users clicked on 'Edit' in
        the new two-factor methods lists page, but then went back without
        finishing the flow, their `otp_secret` had been changed therefore
        invalidating their previous authenticator app, making them unable to
        log in again using TOTP.
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      
      * refactor: fix eslint errors
      
      The PR build was failing given that linting returning some errors.
      This commit attempts to fix them.
      
      * refactor: normalize i18n translations
      
      The build was failing given that i18n translations files were not
      normalized.
      This commits fixes that.
      
      * refactor: avoid having the webauthn gem locked to a specific version
      
      * refactor: use symbols for routes without '/'
      
      * refactor: avoid sending webauthn disabled email when 2FA is disabled
      
      When an admins disable 2FA for users, we were sending two mails
      to them, one notifying that 2FA was disabled and the other to notify
      that WebAuthn was disabled.
      As the second one is redundant since the first email includes it, we can
      remove it and send just one email to users.
      
      * refactor: avoid creating new env variable for webauthn_origin config
      
      * refactor: improve flash error messages for webauthn pages
      
      Co-authored-by: default avatarFacundo Padula <facundo.padula@cedarcode.com>
      e8d41bc2
  18. Aug 20, 2020
  19. Aug 16, 2020
  20. Aug 14, 2020
Loading