Skip to content
Snippets Groups Projects
  1. Feb 19, 2021
    • Benjamin Franzke's avatar
      [TASK] Refactor low level console commands to avoid full boot · 3500a5ca
      Benjamin Franzke authored
      This will allow for low level commands like cache:warmup (or flush)
      to be implemented.
      Commands that're registered in (internal!) service providers are now
      defined to be lowlevel. That allows to change behaviour for internal
      commands only, without being breaking.
      
      Low level commands…
       * will only be defined by TYPO3 core, not by third party extensions
         or libraries (despite by using internal interfaces)
       * will not use any $GLOBALS in constructor
       * will only inject dependencies defined by service providers
       * must not require a database connection during construction
       * will only be defined in internal service providers
       * may use the internal BootService to bootstrap to a certain
         boot level
      
      Regular commands…
       * are allowed to access TYPO3_CONF_VARS in constructor
       * are allowed to inject any service via constructor
       * are allowed to access TCA in constructor
       * may perform database calls in constructors (although this is not
         recommended)
       * may fail during construction, e.g. because of a stale DI container
         (an upcoming low level cache:flush/warmup command will be
         provided for such scenarios)
      
      The command list `bin/typo3 list`…
       * will show all low level commands
       * will degrade to low level only commands if the DI
         container is not loadable
      
      The upgrade command therefore now runs fully uncached and does not
      require a full boot upfront.
      
      The symfony command `help` is treated as non low level command,
      as command constructors need to be executed in order for arguments
      to be configured and available for help output. Therefore a full
      boot is required. This causes the symfony DI container,
      ext_localconf and ext_tables to be loaded.
      That means: An invalid container cache will cause help to fail,
      `list` will degrade do lowlevel commands, but an
      (upcoming) low level console command cache:flush/warmup will
      still be invokable and is intended for scenarios where 3rd party
      code is changed and therefore DI/localconf/TCA cache became stale.
      
      `typo3/cms-cli`, which provides vendor/bin/typo3 in composer mode,
      is adapted in: https://github.com/TYPO3/cms-cli/pull/5
      
      Commands used for updating typo3/cms-cli:
      
        composer require typo3/cms-cli:^3.0
        composer require typo3/cms-cli:^3.0 \
          --no-update --working-dir=typo3/sysext/core
      
      Resolves: #86248
      Related: #93174
      Releases: master
      Change-Id: Ie7cfb73983d96ed67532570be4099a25d106db28
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67241
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarHelmut Hummel <typo3@helhum.io>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      3500a5ca
    • Oliver Bartsch's avatar
      [FEATURE] Introduce MFA in Core · 39145a46
      Oliver Bartsch authored
      A new API is introduced, providing multi-factor
      authentication for the Core. The API is furthermore
      directly used to add two MFA providers by default:
      
      * TOTP (time-based one-time passwords)
      * Recovery codes
      
      Even if the API is designed to allow MFA in both,
      backend and frontend, it is currently only implemented
      into the backend. Users can therefore configure their
      available MFA providers in a new backend module,
      accessible via their user settings.
      
      There are also some configuration options for
      administrators to e.g. define a recommended provider
      or to disallow available providers for specific users
      or user groups.
      
      Administration of the users' MFA providers is possible
      for administrators in the corresponding user records.
      
      New providers can be introduced by implementing the
      MfaProviderInterface and tagging the service with the
      `mfa.provider` tag.
      
      Note that the API is currently marked as internal since
      changes in upcoming patches are to be expected.
      
      Following dependencies are introduced:
      
      * bacon/bacon-qr-code "^2.0"
      * christian-riesen/base32 "^1.5"
      
      Possible features that could follow later-on:
      
      * MFA frontend integration
      * Webauthn core provider for FIDO2 and U2F.
      * Forcing users to set up MFA on login
      * Password-recovery with active MFA
      
      Resolves: #93526
      Releases: master
      Change-Id: I4e902be624c80295c9c0c3286c90a6a680feeb5d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67548
      
      
      Reviewed-by: default avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: default avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarcore-ci <typo3@b13.com>
      Tested-by: default avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarBenni Mack <benni@typo3.org>
      39145a46
  2. Feb 18, 2021
  3. Feb 17, 2021
  4. Feb 16, 2021
  5. Feb 15, 2021
  6. Feb 13, 2021
  7. Feb 12, 2021
  8. Feb 11, 2021
  9. Feb 10, 2021