Skip to content

GitLab

Switch branch/tag
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
  3. 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
  5. 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
  7. 06 Jan, 2021 1 commit
  9. 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
  11. 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
  13. 27 Sep, 2020 1 commit
  15. 15 Apr, 2020 1 commit
  17. 14 Apr, 2020 1 commit
  19. 13 Apr, 2020 1 commit
  21. 04 Apr, 2020 1 commit
  23. 03 Apr, 2020 1 commit
  25. 17 Feb, 2020 1 commit
  27. 15 Feb, 2020 1 commit
  29. 07 Nov, 2019 1 commit
  31. 21 Jun, 2019 1 commit
  33. 29 Jan, 2019 1 commit
  35. 25 Jan, 2019 1 commit
  37. 19 Dec, 2018 1 commit
  39. 01 Oct, 2018 1 commit
  41. 22 Jul, 2018 1 commit
  43. 17 May, 2018 1 commit
  45. 17 Feb, 2018 1 commit
  47. 07 Dec, 2017 1 commit
  49. 30 Nov, 2017 1 commit
  51. 02 Oct, 2017 1 commit
  53. 16 Jan, 2017 1 commit
  55. 09 Jan, 2017 1 commit
  57. 01 Dec, 2016 1 commit
  59. 26 Oct, 2016 2 commits
  61. 01 Sep, 2016 1 commit
  63. 30 Aug, 2016 1 commit
  65. 21 Jul, 2016 1 commit
  67. 09 Jun, 2016 1 commit
  69. 20 Apr, 2016 1 commit
  71. 18 Apr, 2016 1 commit
  73. 14 Apr, 2016 2 commits
  75. 07 Apr, 2016 1 commit