1. 21 Jun, 2022 1 commit
  2. 22 Apr, 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>
      2f0338a9
  4. 22 Feb, 2022 1 commit
  5. 21 Feb, 2022 1 commit
  6. 16 Jan, 2022 1 commit
  7. 24 Sep, 2021 1 commit
  8. 13 Aug, 2021 1 commit
  9. 05 Aug, 2021 1 commit
  10. 11 Jun, 2021 1 commit
  11. 10 Jun, 2021 1 commit
  12. 26 Nov, 2020 2 commits
  13. 11 Sep, 2020 1 commit
  14. 12 Aug, 2020 1 commit
  15. 14 May, 2020 1 commit
  16. 28 Apr, 2020 1 commit
  17. 17 Apr, 2020 1 commit
    • Benjamin Franzke's avatar
      [TASK] Inject singletons used by EXT:install in service providers · c020e9ba
      Benjamin Franzke authored and Susanne Moog's avatar Susanne Moog committed
      This will allow both, dependency injection for these services (manually
      wired in service providers), and usage in install/maintenance tool
      (where we do not use the caching symfony container for basic tasks).
      
      The move to DI is possible thanks to the failsafe container and the
      service providers which can fed the failsafe container with service
      factories. These factories are used to wire services manually.
      
      Notes:
      
       * The definition in a service provider means we are required to use
         manual wiring and are forced to define the dependencies in the service
         provider when we add new depenencies to services that are being used
         by the install..
         With that approach we can assure that we do not accidentally add new
         dependencies to services which would become available in symfony DI due
         to autowiring, but would be unavailable in the install tool.
      
       * The install tool has operations that require a booted symfony
         container which is provided by the LateBootService. Services that
         are used in that mode do not need to be listed in service providers.
         Therefore we do only add core services to service providers if they
         are used in a context without a fully booted symfony DI container.
      
       * GLOBALS['LANG'] mocks in Core\Tests\Unit\DataHandling\DataHandlerTest
         have been removed as the code under test does no longer use
         $GLOBALS['LANG']->csConvObj->substr() but mb_substr. The test had been
         introduced with #68602 but the tested code was adapted in #78670.
      
       * We got a bit ugly constructs now, where a unit(!) test previously used
      
           $GLOBALS['LANG'] = new LanguageService();
      
         …we now have to encode the dependency structure:
      
           $GLOBALS['LANG'] = new LanguageService(new Locales,
               new LocalizationFactory(
                   new LanguageStore,
                   $cacheManagerProphecy->reveal()
               )
           );
      
         This isn't nice, but this change reveals that the affected unit tests
         should either be adapted, removed or be moved to a functional test.
         Such adaption are out of scope for this change.
      
       * loadExtLocalconfDatabaseAndExtTables() is removed from the
         EXT:install AbstractController, as it hides the implicit dependency
         to LateBootService
      
       * Nullable constructor arguments have been changed to be non-nullable
         whenever possible. That results in some more test adaptions, but
         reveals, where unit tests rely on implicit dependencies and offers
         better readability and less possible codepaths.
      
      Releases: master
      Resolves: #89892
      Resolves: #89891
      Change-Id: Ib72d6440f81b2c0d05279e8768697c3b48aecfe4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62575
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Tested-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Susanne Moog's avatarSusanne Moog <look@susi.dev>
      c020e9ba
  18. 15 Apr, 2020 1 commit
  19. 14 Apr, 2020 1 commit
  20. 22 Feb, 2020 1 commit
  21. 20 Nov, 2019 1 commit
  22. 07 Oct, 2019 1 commit
  23. 04 Jul, 2019 1 commit
  24. 12 Jun, 2019 1 commit
  25. 30 May, 2019 1 commit
    • Benni Mack's avatar
      [!!!][TASK] Remove Frontend Track User functionality · 8300dd31
      Benni Mack authored and Andreas Fernandez's avatar Andreas Fernandez committed
      The functionality "ftu" ("Frontend Track User"), which allows
      to send the session through GET parameter within the site
      has been removed.
      
      It was used to hand in a session via `config.ftu = 1` and
      the GET parameter "ftu=a-32-character-string", which then
      started a session which was added to any link generated.
      
      This way, sessions could _have_ been transferred across
      domains but only if cookies would not be activated by
      the browser, which is unreliable.
      
      In order to pave the way to modern standards (OTP
      or JWT), this functionality is removed, as the ftu functionality
      has some flaws, conceptually and security wise.
      
      Removed public properties
      * AbstractUserAuthentication->get_name
      * AbstractUserAuthentication->getFallBack
      * AbstractUserAuthentication->getMethodEnabled
      * AbstractUserAuthentication->get_URL_ID
      * TypoScriptFrontendController->getMethodUrlIdToken
      
      Removed TypoScript:
      * config.ftu = 1
      
      Removed TYPO3_CONF_VARS
      * $TYPO3_CONF_VARS[FE][get_url_id_token]
      
      GET Parameter "ftu" has no special meaning anymore.
      
      Resolves: #88458
      Releases: master
      Change-Id: I664be44228b2180909f6abfda8acfcd5fe36aa5a
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60840
      
      
      Tested-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      Reviewed-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
      Reviewed-by: Andreas Fernandez's avatarAndreas Fernandez <a.fernandez@scripting-base.de>
      8300dd31
  26. 21 May, 2019 1 commit
  27. 16 May, 2019 1 commit
  28. 23 Feb, 2019 1 commit
  29. 18 Jan, 2019 1 commit
  30. 01 Oct, 2018 1 commit
  31. 29 Sep, 2018 1 commit
  32. 03 Sep, 2018 1 commit
  33. 25 Aug, 2018 1 commit
  34. 14 Aug, 2018 1 commit
  35. 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
      deprecated.
      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.
      
      Details:
      * 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
        TYPO3_CONF_VARS/SC_OPTIONS/ext/saltedpasswords/saltMethods
        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>
      4b695b64
  36. 28 Jun, 2018 1 commit
  37. 23 Jun, 2018 1 commit
  38. 21 Apr, 2018 1 commit
  39. 13 Feb, 2018 1 commit