1. 21 Jun, 2022 1 commit
  2. 07 Jun, 2022 1 commit
  3. 01 Apr, 2022 1 commit
    • Christian Kuhn's avatar
      [!!!][TASK] Simplify TCA authMode settings · 2f0338a9
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      To prepare towards a deployable backend group access
      rights system, some of the more obscure options are
      removed to reduce overall complexity.
      * TYPO3_CONF_VARS['BE']['explicitADmode'] is finally
        gone: Following a deny list approach is a flawed security
        system. TYPO3's default setting (explicitADmode=allow)
        follows the very common "Least Privileged" principle,
        so editors need to be explicitly given access to a
        CType, as is done with all other permissions.
      * The only valid value for TCA config option "authMode"
        on type="select" fields is now "explicitAllow". The
        previous "explicitDeny" value is abandoned following
        the reasoning above. The value "individual" is abandoned
        since it is a very rarely used setting (not a single
        match in TER).
      * With authMode="individual" being gone, the select item
        array keys on position six that could be set to "EXPL_DENY"
        and "EXPL_ALLOW" are obsolete.
      * Field "explicit_allowdeny" in table be_groups is
        simplified. This was a comma separated list of
        colon separated: "table:field:value:ALLOW/DENY".
        The last "ALLOW" or "DENY" is now obsolete.
      The patch removes the above handling from the core. A
      TCA migration scans TCA for invalid options and adapts
      them. An upgrade wizard is in place to clean up the
      be_groups explicit_allowdeny field of existing rows.
      Resolves: #97265
      Releases: main
      Change-Id: I545b08fc694e9081ad79e69e7f55f684316e7b0f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/74126
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  4. 01 Feb, 2022 1 commit
    • Oliver Klee's avatar
      [BUGFIX] Fix some incorrect usages of Prophecy · f32fdb16
      Oliver Klee authored and Christian Kuhn's avatar Christian Kuhn committed
      With the following changes, we can get rid of a whole bunch
      of warnings from the PHPStan baseline:
      1. Now that we are using the Prophecy plugin for PHPStan,
         we don't need type annotations for prophecies anymore.
      2. Prophecies are not instances of the prophesized classes.
         So we need to fix/remove type annotations that incorrectly
         state this, and also move accesses on properties from the
         prophecies to the revelations.
      3. Revelations are not instances of ObjectProphecy. They
         implement ProphecySubjectInterface, but that usually is
         of no relevance to our test classes. So we can simplify
         the type annotations and usually convert those to native
         type annotations.
      4. Have PHPStan ignore false positive related to class aliasing
         (that probably is outside of what PHPStan can do).
      5. Drop extraneous arguments to Argument::any().
      Resolves: #96713
      Releases: main, 11.5
      Change-Id: Icfe3ddef89c6bd6edf331c103211ac2ac18f2ef7
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/73238
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Stefan Bürk's avatarStefan Bürk <stefan@buerk.tech>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  5. 30 Jan, 2022 1 commit
  6. 24 Sep, 2021 2 commits
  7. 29 Aug, 2021 1 commit
  8. 12 Aug, 2021 2 commits
  9. 05 Aug, 2021 2 commits
  10. 12 Jul, 2021 1 commit
  11. 11 Jun, 2021 1 commit
  12. 10 Jun, 2021 1 commit
  13. 17 Apr, 2020 1 commit
  14. 15 Apr, 2020 1 commit
  15. 14 Apr, 2020 1 commit
  16. 13 Apr, 2020 1 commit
  17. 22 Feb, 2020 1 commit
  18. 02 Dec, 2019 1 commit
  19. 25 Oct, 2019 1 commit
  20. 24 Oct, 2019 2 commits
  21. 16 May, 2019 1 commit
  22. 15 May, 2019 1 commit
  23. 18 Jan, 2019 1 commit
  24. 29 Sep, 2018 1 commit
  25. 01 Sep, 2018 1 commit
  26. 25 Aug, 2018 1 commit
  27. 14 Aug, 2018 1 commit
  28. 11 Aug, 2018 1 commit
    • Christian Kuhn's avatar
      [TASK] Make password hash selection an install tool preset · 4b695b64
      Christian Kuhn authored
      With this change, the password hash code in salted passwords is
      reduced to the SaltFactory with two methods and the single hash
      classes that implement SaltInterface without further public
      methods. Everything else including the utility classes is
      The change moves the LocalConfiguration.php config options around,
      adds a settings preset for hash mechanism selection, adds according
      silent upgrades, adds 'best available' hash mechanism selection
      at installation time and drops the last saltedpasswords
      ext_conf_template.txt option.
      * Remove the password hash selection from saltedpasswords config
        namespace and put to TYPO3_CONF_VARS/BE/passwordHashing/className
        and TYPO3_CONF_VARS/FE/passwordHashing/className
      * Move available password hash registry from
        to TYPO3_CONF_VARS/SYS/availablePasswordHashAlgorithms
      * Add a setting preset to select one of argon2i (preferred),
        bcrypt, pbkdf2 or phpass (last fallback)
      * Use 'best matching preset' during installation to select a good
        salt mechanism by default
      * Silently upgrade existing password hash selection and upgrade
        to one of the four hash algorithms above
      * Allow algorithm specific options in
        TYPO3_CONF_VARS/BE/passwordHashing/options and
        TYPO3_CONF_VARS/FE/passwordHashing/options for admins who
        know what they are doing and need to fiddle with hash details.
      * Simplify and refactor the single password hash classes. Deprecate
        a huge list of methods along the way.
      Change-Id: I773e2ee27a121c9f0d5302695ebf4aa561170400
      Resolves: #85804
      Resolves: #83760
      Releases: master
      Reviewed-on: https://review.typo3.org/57850
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  29. 28 Jun, 2018 1 commit
  30. 23 Jun, 2018 1 commit
  31. 16 Apr, 2018 1 commit
  32. 15 Mar, 2018 1 commit
  33. 14 Feb, 2018 1 commit
  34. 19 Jan, 2018 1 commit
  35. 19 Sep, 2017 1 commit
    • Christian Kuhn's avatar
      [TASK] Install tool: JS driven routing · 3896e163
      Christian Kuhn authored and Susanne Moog's avatar Susanne Moog committed
      The install tool suffered from three main issues since 6.2 rewrite:
      * The "step" installer was re-used for recovery and installation
      * The routing logic was server based and threw lots of redirects
        which lead to redirect loops
      * The Controller/Action class structure was weird and hard to
      The patch solves this with a rather huge rewrite:
      * There are two request handlers: One for the Installer, one for
        the install tool.
      * A simple list of controllers. One InstallerController for the
        step installer, the others for the main module points of the
        install tool and a Login and a Layout controller.
      * Single action code is moved into controllers.
      * Both tool and installer first load only a <head> section that
        contain JS references. All other calls are ajax based and the
        routing is done JS side.
      * Installer and install tool no longer share controller code
        or templates, the installer can potentially be fully extracted
        from ext:install in another step.
      * Installer.js is the "walk through installation" module of the
      * Router.js is the routing module for the install tool, all tool
        ajax requests get specific urls from this module and hand over
        errors to the Router.
      * Error handling is handled on JS side: If for instance
        the login session expires and user clicks elsewhere, a 403
        response is returned which is handled by JS to route to login.
        This is also the place where a recovery can hook in later.
      * The silent configuration updater is executed again which was
        removed during one of the previous master patches.
      * The template structure is much easier.
      * Various card content which has been calculated when loading
        the card layout is moved to the ajax code for single card
        content. That increases the performance of the main module
        points and makes them pretty snappy.
      Change-Id: Ib40f40acba17bb47142c0da1bcfb389ab9b4b3a1
      Resolves: #82504
      Releases: master
      Reviewed-on: https://review.typo3.org/54128
      Tested-by: default avatarStefan Neufeind <typo3.neufeind@speedpartner.de>
      Tested-by: default avatarTYPO3com <no-reply@typo3.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Mona Muzaffar's avatarMona Muzaffar <mona.muzaffar@gmx.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <susanne.moog@typo3.org>
  36. 09 Sep, 2017 1 commit