This project is mirrored from https://git.typo3.org/typo3/typo3.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 02 Aug, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate generic extbase domain classes · 3c78adc6
      Christian Kuhn authored
      Extbase provides a couple of generic domain repositories
      and models, especially frontend / backend users and
      groups. Those are flawed by design:
      
      The main issue is that domain models have to be specific
      for the domain they are used in. By definition, a generic,
      opinionated model can't be "correct" since the domain
      it is used in, is unique: It might be that a backend user
      email has to be set and the domain does not model
      anything but email and firstname?
      
      Many usages don't need backend groups attached to a
      backend user model at all, or if they need them, then
      maybe in a recursive presentation, or a specific order
      or something similar. Having a default group resolution
      is thus at least misleading, if not wrong, and can be a
      performance issue on top.
      
      A generic model can never foresee its usages. The existing
      models thus try to 1:1 adapt the database fields, which
      is also misleading since a domain model is not and should
      not be a direct representation of a database table. It
      would only be by chance if the generic models fit a
      specific domain.
      
      Similar issues exist with the repositories: The
      CategoryRepository for instance assumes it is a good
      idea to set respectStoragePid(false), which is most
      likely not the right thing for an extension use.
      In the end, whatever extbase delivers here, is most
      likely wrong and does not fit the problem domain.
      
      The patch keeps the 'experimental' FAL related models
      since those can be actually useful for extensions and
      their final fate has not been decided, yet. The other
      generic models, especially those with lots of properties
      are marked as deprecated with the patch.
      
      Change-Id: I06629fddd0258c517f3fa8bdf2e9c4b342be9678
      Resolves: #94654
      Related: #83296
      Releases: master
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70061
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      3c78adc6
  2. 29 Jun, 2021 1 commit
    • Oliver Bartsch's avatar
      [BUGFIX] Extract switch user handling from EXT:beuser · 70f8559a
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      The switch user handling was previously placed in EXT:beuser,
      more precisely in the BackendUserControllers' indexAction.
      It was therefore necessary to link to the extbase based
      controller with a mix of prefixed arguments and the non
      prefixed "switchUser" argument. Latter was internally
      evaluated with GU:_GP(). This means, switching users was
      done via GET requests in an extbase action, but only in
      case a non extbase prefixed argument was set.
      
      In #94209 this got worse when the BackendUserGroupController
      was merged into BackendUserController. Since this controller
      features a "remember my last action" functionality, switch user
      could no longer reliably be triggered. The evaluation of the
      non extbase prefixed "switchUser" argument only took place in
      the "user listing" (indexAction) and the success of the call
      therefore depended on the users' last called action, as this
      action was automatically used.
      
      This patch now extracts the switch user functionality from
      EXT:beuser into a dedicated EXT:backend controller, featuring
      two ajax routes "/switch/user" and "/switch/user/exit". Both
      accessible via POST requests only. To trigger those requests,
      a new JS module "TYPO3/CMS/Backend/SwitchUser" is introduced.
      This also allows to completely remove the logout hook by using
      the concrete markup (custom element) for the "exit" button.
      
      Resolves: #94426
      Related: #94209
      Releases: master
      Change-Id: I556b323fe6ae77cf696e7e34dbbe269eb4f9927a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69635
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      70f8559a
  3. 19 Feb, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce MFA in Core · 39145a46
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      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: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      39145a46
  4. 06 Jan, 2021 1 commit
  5. 21 Dec, 2020 1 commit
    • Benjamin Franzke's avatar
      [TASK] Update bootstrap javascript to 5.0.0-beta1 · 27881b60
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
      Bootstrap v5 – introduced in #92616 – was added with CCS from beta1 but
      JavaScript from alpha2. bootstrap.bundle.js was manually wrapped
      into a AMD closure, and because bootstrap 5.0.0-beta1 contains alot of
      changes regarding data tags, it couldn't be updated in the initial
      patch.
      
      Bootstrap is now bundled using rollup using the ES6 sources in order
      to allow for automatic updates through `grunt build`.
      
      popperjs – previously bundled into bootstrap distributed files –
      is now added as dependency. The bootstap ES6 sources, that we now use
      through rollup, do not bundle this external dependency (for good reasons).
      
      Dependency added with:
      
         yarn add @popperjs/core
      
      Further adaptions contained in this change to ensure beta1 compatibility:
      
      a) Carousel "item" to "carousel-item" class migration
      b) $.fn.modal(options) does no longer imply $.fn.modal('show')
      c) Fix panels, both JS and CSS (card-group can't be used here)
      d) All bootstrap data- tags are migrated to data-bs-.
         (see https://github.com/twbs/bootstrap/pull/31827)
         Migrated with
      
         # renderes a sed substition with the help of a nested sed from all the
         # data-bs attributes that where changed in the twbs/bootstrap commit
         git grep -l data- | xargs sed -i $( \
              curl -s \
              https://patch-diff.githubusercontent.com/raw/twbs/bootstrap/pull/31827.patch | \
              sed 's/data-bs-[a-z-]*/\n&\n/g' | grep "data-bs-[a-z-]" | \
              sort | uniq | \
              sed 's/data-bs-\(.*\)\([^a-z-]\|$\)/ -e s\/data-\1\\\([^a-z-]\\\)\/data-bs-\1\\1\/g -e s\/data('"'"'\1'"'"')\/data('"'"'bs-\1'"'"')\/g/g' \
         )
      
         # Revert false positives from the above auto-replacement
         git checkout -- typo3/sysext/core/Documentation/Changelog/ \
              typo3/sysext/backend/Classes/Form/Container/FlexFormContainerContainer.php \
              Build/Sources/TypeScript/backend/Resources/Public/TypeScript/LiveSearch.ts \
              Build/Sources/TypeScript/backend/Resources/Public/TypeScript/FormEngineFlexForm.ts \
              Build/Sources/TypeScript/install/Resources/Public/TypeScript/Module/Settings/ExtensionConfiguration.ts \
              Build/Sources/Sass/typo3/_element_panel.scss
      
         (cd Build && grunt build)
      
      Resolves: #93126
      Resolves: #93123
      Resolves: #93132
      Related: #92616
      Releases: master
      Change-Id: Ie194d0f87d2c60df7b9e8a6de4893cfaaea55356
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67215
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: default avatarMartin Kutschker <mkutschker-typo3@yahoo.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: default avatarMartin Kutschker <mkutschker-typo3@yahoo.com>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      27881b60
  6. 10 Dec, 2020 1 commit
    • Benni Mack's avatar
      [!!!][FEATURE] Refactored Session Handling · 733353c1
      Benni Mack authored
      The AbstractUserAuthentication class handles way too much
      of what it should know / do.
      
      For this reason, a new UserSession object which contains
      basic information needed for everything belonging to a non-fixated
      session, a fixated anonymous session, if a session was evelated,
      or if a session has expired, is kept in there.
      The "SessionManager" should not be used anymore publically
      but slowly dissolve into a SessionBackendManager.
      
      Design goals:
      * UserAuth object should not know about session backends
      * UserAuth should not store sessionData etc. directly in its own object
      * Decouple UserSession info from any properties of UserAuth
      * A UserSessionManager deals with the creation and validation of the UserSession objects. No Session Objects can be created etc outside
      of this class to maintain persistability
      * UserSessionManager also encapsulates ipLocking and the responsible SessionBackend
      
      Final goals to be tackled later:
      * Build a user session object from the request object, and not within the UserAuth object
      * Session Handling can be accessed outside of UserAuth
      * Cookie Handling and Session Handling are separated from UserAuth
      * Load Session information from PSR-7 request instead of $_COOKIE
      
      Resolves: #93023
      Releases: master
      Change-Id: Ia2d8244e433d0f6adf220d443b2c0947f251b5e9
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66935
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      733353c1
  7. 27 Sep, 2020 1 commit
  8. 15 Apr, 2020 1 commit
  9. 14 Apr, 2020 1 commit
  10. 13 Apr, 2020 1 commit
  11. 04 Apr, 2020 1 commit
  12. 03 Apr, 2020 1 commit
  13. 17 Feb, 2020 1 commit
  14. 15 Feb, 2020 1 commit
  15. 07 Nov, 2019 1 commit
  16. 21 Jun, 2019 1 commit
  17. 29 Jan, 2019 1 commit
  18. 25 Jan, 2019 1 commit
  19. 19 Dec, 2018 1 commit
  20. 01 Oct, 2018 1 commit
  21. 22 Jul, 2018 1 commit
  22. 17 May, 2018 1 commit
  23. 17 Feb, 2018 1 commit
  24. 07 Dec, 2017 1 commit
  25. 30 Nov, 2017 1 commit
  26. 02 Oct, 2017 1 commit
  27. 16 Jan, 2017 1 commit
  28. 09 Jan, 2017 1 commit
  29. 01 Dec, 2016 1 commit
  30. 26 Oct, 2016 2 commits
  31. 01 Sep, 2016 1 commit
  32. 30 Aug, 2016 1 commit
  33. 21 Jul, 2016 1 commit
  34. 09 Jun, 2016 1 commit
  35. 20 Apr, 2016 1 commit
  36. 18 Apr, 2016 1 commit
  37. 14 Apr, 2016 2 commits
  38. 07 Apr, 2016 1 commit