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. 22 Jul, 2021 1 commit
  5. 16 Jul, 2021 1 commit
    • Oliver Bartsch's avatar
      [TASK] Clean up Permission controllers · 6d956e81
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed 
      The PermissionController was previously handled
via extbase, even though no pure Extbase-related
feature (validation, type-converting, persistence)
was used. Furthermore a combination of non-extbase
arguments and extbase-prefixed arguments was used,
leading to a couple of GeneralUtility::_GP() usages.

To clean up the controller, it is now not longer
registered as extbase module, while keeping
the module name "system_BeuserTxPermission"
for backwards-compatibility reasons.

Furthermore, is the PermissionAjaxController,
used for inline updates in the tree view,
moved into the PermissionController. This
allowed to streamline and clean up its only
endpoint.

Besides the clean up, some things got improved,
e.g. the shortcut button does now also take the
current action into account and all used labels
can now be translated.

Resolves: #94564
Releases: master
Change-Id: Ic03e341df5b69aa154be1a5b737df2eecc433e55
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69893

Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      6d956e81
  7. 30 Jun, 2021 2 commits
  9. 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
  11. 31 May, 2021 1 commit
    • Oliver Bartsch's avatar
      [TASK] Change password reset functionality · 12737d31
      Oliver Bartsch authored and Richard Haeser's avatar Richard Haeser committed 
      In case administrators don't want their users to
initiate the reset password process, they have to
set the global configuration option "passwordReset"
to false.

This however also prevents administrators from
using the cli command or the action in the backend
user module.

Therefore, some things changed in the password
reset implementation:

- `passwordReset` now only affects the login screen
- The CLI command is always enabled (requires shell
  access since the command is not schedulable)
- Initiating password reset in the backend can be
  managed separately with a new user TSconfig option

Also the descriptions of the global configuration
options are adjusted. Actually `passwordResetForAdmins`
previously mentioned that setting this to FALSE will
only affect the login screen, which was not the case.
It always affected all places.

In the end, this enables administrators to be more
precise when configuring the password reset functionality
in their installations.

Resolves: #91496
Releases: master
Change-Id: Ic74080adffbaf55f82189dffddb93fdd601034e2
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69268

Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Richard Haeser's avatarRichard Haeser <richard@richardhaeser.com>
      12737d31
  13. 30 May, 2021 1 commit
  15. 29 May, 2021 1 commit
  17. 27 May, 2021 1 commit
    • Christian Kuhn's avatar
      [TASK] Deprecate ext:backend ModuleLayout view helpers · 5a456090
      Christian Kuhn authored 
      A while after the PHP based ModuleTemplate API has been
introduced back in 2015, a couple of fluid view helpers
have been added to ext:backend as a second way to handle
full backend module content like the doc header.
It found an example use in ext:beuser.

Development however stopped at this point, the provided
view helpers are only a sub set of the PHP based API and
they didn't find broader use within the core - all other
backend modules stick to the ModuleTemplate based API.

On a structural level, those view helpers are questionable:
They move functionality to the view component which is
arguably more a controller task. The ext:beuser module
proofes this since it had to assign controller knowledge
like the current action and controller name to the view
in order to render the doc header module down and shortcut
buttons.

The patch drops usages of these view helpers in ext:beuser,
plus the minor usages of the outer ModuleLayout view helper
in ext:install and ext:belog, substitutes them with the
PHP ModuleTemplate API within controllers, and deprecates
the full set of ModuleLayout view helpers.

The change sharpens our separation between controller and
view: The "outer" module handling like doc header buttons
and menus are tied to controller logic and should be
located there, while the module body is rendered by a
fluid view.

As a bonus, a couple of issues within ext:beuser are
fixed along the way, since they can now be easily solved
and were rather hard to tackle with the view helper based
approach:
* The beuser module now remembers state and jumps to
  for instance the group sub module when a user selected
  this last. This is now in line with many other backend
  modules that do the same.
* Shortcuts to single user details work.
* The main doc header drop down can now contain all possible
  sub modules, including those that are available only
  indirectly, for instance the single user details view.
  This is good when calling these from shortcuts.

Change-Id: Idef3aa6975e97677c1da0cef57f70c855bd2ea9f
Resolves: #94209
Releases: master
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69269

Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Jochen's avatarJochen <rothjochen@gmail.com>
Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
Reviewed-by: Jochen's avatarJochen <rothjochen@gmail.com>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      5a456090
  19. 26 May, 2021 2 commits
  21. 25 May, 2021 1 commit
  23. 19 May, 2021 1 commit
  25. 14 May, 2021 1 commit
  27. 30 Apr, 2021 1 commit
  29. 28 Apr, 2021 1 commit
  31. 27 Apr, 2021 1 commit
  33. 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
  35. 03 Feb, 2021 1 commit
  37. 25 Jan, 2021 1 commit
  39. 20 Jan, 2021 1 commit
  41. 07 Jan, 2021 2 commits
    • Oliver Bartsch's avatar
      [TASK] Fetch route from request instead of GET parameter · b52f67b6
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed 
      The "route" GET parameter is deprecated since #93048.
Therefore the route path has now to be fetched from the
request object instead.

This patch replaces all places in core where the route
is still fetched via GET. It's currently often necessary
to access $GLOBALS['TYPO3_REQUEST'] therefore, since the
request object is not always present at those places. This
will be tackeled in upcoming patches.

Resolves: #93158
Releases: master
Change-Id: I6e163919b19484171b6ebf8087fdc650cf977c9c
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67355

Tested-by: default avatarTYPO3com <noreply@typo3.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>
      b52f67b6
    • Benjamin Franzke's avatar
      [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
      Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed 
      When a controller finds some pre-requisites of the called
action are not fulfilled, it can create an 'early' response
and throw it as ImmediateResponseException. This exception
bypasses the middleware stack, and is caught in the Application
to emit the response. This is a big win in contrast to
die/exit calls.

Some middlewares however expect to be always called when the
response bubbles up. Good examples are 'locking' middlewares:
They set up a lock when called, dispatch to inner middlewares,
and tear town the lock when a response is retrieved.

The tear down code of those middlewares is bypassed when
a controller throws an ImmediateResponseException.

The patch introduces a second exception: PropagateResponseException.
This one is caught by a new very inner middleware positioned at the
end of the middleware stack, just before the request is dispatched
to some controller. It then sends the response up the outer
middlewares. This allows middlewares like a 'locking' middleware
to do it's job without being bypassed, and at the same time
allows a controller to bypass any further local processing by
throwing such a response exception.

ImmediateResponseException exists as before and can still be used
to directly bypass the middleware stack and is kept as safety net
in case a PropagateResponseException is thrown within a middleware.
PropagateResponseException therefore extends ImmediateResponseException.

It's however discouraged to throw ImmediateResponseException from
within controllers - they require knowledge on what middlewares
do in their 'tear down' part and there shouldn't be a reason to
bypass them.

Middleware/BackendUserAuthenticator is adapted to properly
handle ImmediateResponseException that would have been thrown
BackendUserAuthentication::backendCheckLogin(). BackendUserAuthentication
is therefore refactored to allow to call the backend login
initialization without (duplicate) login check.
This allows to propagate redirect/maintenance responses.

Releases: master
Resolves: #93007
Change-Id: I291d9d532e7fa289b803e5eef38b23402e57e8ba
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67042

Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Tested-by: default avatarTYPO3com <noreply@typo3.com>
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>
      f179a57f
  43. 06 Jan, 2021 4 commits
  45. 05 Jan, 2021 1 commit
  47. 04 Jan, 2021 1 commit
  49. 22 Dec, 2020 1 commit
  51. 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
  53. 17 Dec, 2020 1 commit
    • Oliver Bartsch's avatar
      [!!!][TASK] Rework shortcut PHP API functionality · e4833fda
      Oliver Bartsch authored and Christian Kuhn's avatar Christian Kuhn committed 
      To be able to introduce URL rewrites for the backend,
the internal handling and registration of the shortcut
PHP API is reworked.

The Shortcut PHP API previously has the full URL of
the shortcut target stored in the database. This lead
to many problems such as shortcuts got invalid as soon
as their target module changed its route path. Furthermore,
this required unnecessary functionality like replacing
tokens on URL creation.

Therefore, a shortcut record now stores only the route
identifier of the module to link to and necessary arguments
in two new database columns. A upgrade wizard is in place
to migrate existing data.

The rework also required to deprecate some methods in
the ShortcutButton API and a parameter signature change
of the JavaScript function `TYPO3.ShortcutMenu.createShortcut()`
which performs the AJAX call to create new shortcuts.

Side effect, this also deprecated the last remains of
xMOD_alt_doc.php in the core.

Resolves: #93093
Releases: master
Change-Id: I07666a299651e4953b4adf2987fcd3469094c288
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67143

Tested-by: default avatarTYPO3com <noreply@typo3.com>
Tested-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
Reviewed-by: Daniel Goerz's avatarDaniel Goerz <daniel.goerz@posteo.de>
Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      e4833fda
  55. 14 Dec, 2020 1 commit
  57. 12 Dec, 2020 1 commit
  59. 10 Dec, 2020 2 commits
  61. 09 Dec, 2020 1 commit
  63. 07 Dec, 2020 2 commits