1. 21 Jun, 2022 1 commit
  2. 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
  3. 08 Mar, 2022 1 commit
  4. 28 Feb, 2022 1 commit
  5. 25 Feb, 2022 1 commit
  6. 22 Feb, 2022 1 commit
  7. 21 Feb, 2022 1 commit
  8. 14 Feb, 2022 1 commit
  9. 09 Feb, 2022 1 commit
  10. 31 Jan, 2022 1 commit
  11. 21 Jan, 2022 1 commit
  12. 16 Jan, 2022 1 commit
  13. 23 Dec, 2021 1 commit
  14. 09 Dec, 2021 1 commit
  15. 07 Dec, 2021 1 commit
  16. 30 Nov, 2021 1 commit
    • Oliver Bartsch's avatar
      [BUGFIX] Properly handle l10n_display=displayAsReadonly · 3310c162
      Oliver Bartsch authored
      TCA provides the "l10n_display" configuration,
      which allows to define how TCA fields should
      behave in localizations. One of the possible
      values is "defaultAsReadonly", which just
      renders the default records value in a
      readonly field. This is non functional
      and only used in FormEngine.
      
      Common use cases are fields, which do not
      change in a localization, e.g. the author
      of a blog article.
      
      How did this work?
      
      The SingleFieldContainer, entry point of
      each TCA field, checked whether the option
      is set and if so, overrides the "itemFormElValue"
      - containing the processed database field value -
      with the raw field value of the default record
      and automatically sets the field to "readOnly".
      
      This already worked for basic types, such
      as "input", "check" or "radio", since their
      database values are usually not further
      processed by any form data provider.
      
      However, when it comes to types, dealing with
      relations or enrichments, just using the default
      records' raw database value did mostly not work.
      
      Therefore, this patch removes the replacement
      from SingleFieldContainer and adds a new
      form data provider, dealing with this task.
      This way, we ensure all following data providers
      can process the correct value (either the
      current database value or the default
      records value).
      
      This can be tested with a new styleguide record:
      https://github.com/TYPO3/styleguide/pull/254
      
      For some cases (mostly MM lookups and inline),
      the "l10n_mode" needs to be set to "exclude",
      when using "defaultAsReadonly", since otherwise
      the DataHandler doesn't hold the relations in sync.
      
      Note: TCA type "slug" and TCA renderType
      "belayoutwizard" do not yet handle readOnly
      at all, because this option is not supported
      as "columns config". This is fixed in two
      separate patches (#96096 and #96095).
      
      Note: TCA type "flex" does still not work,
      since the corresponding containers do not
      implement readOnly handling at all. Fixing
      this will be done in a separate patch.
      
      Resolves: #89152
      Related: #96095
      Related: #96096
      Releases: main, 11.5
      Change-Id: Ic5346606c0309784a689c83dcefd1888bf31fc89
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/72275
      
      
      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>
      Tested-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>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      3310c162
  17. 27 Nov, 2021 1 commit
  18. 13 Nov, 2021 1 commit
  19. 10 Nov, 2021 1 commit
  20. 13 Oct, 2021 1 commit
  21. 12 Oct, 2021 1 commit
  22. 05 Oct, 2021 1 commit
  23. 24 Sep, 2021 1 commit
  24. 16 Sep, 2021 1 commit
  25. 30 Aug, 2021 1 commit
  26. 16 Aug, 2021 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Adjust default behavior of HTML sanitization in parseFunc · 6a197e75
      Oliver Hader authored and Benni Mack's avatar Benni Mack committed
      As a result of TYPO3-CORE-SA-2021-013, new `htmlSanitize` behavior -
      when invoking `ContentObjectRenderer::parseFunc` - is enabled per
      default, in case it was not declared otherwise. That also happened
      when no processing configuration was given (or could be resolved).
      Without having any configuration, it was obviously not possible to
      disable `htmlSanitize`.
      
      Fluid's `HtmlViewHelper` can be used with an empty `parseFuncTSPath`
      (e.g. `<f:format.html parseFuncTSPath="">`) - due to missing (empty)
      configuration, sanitization was enabled per default in `parseFunc`.
      
      With this change, property `htmlSanitize` either needs to be enabled
      or disabled explicitly - otherwise deprecation logs will be generated,
      if not given, the fall-back behavior is inferred from new feature flag
      `security.frontend.htmlSanitizeParseFuncDefault`.
      
      Invoking `ContentObjectRenderer::parseFunc` without any configuration
      behaves like before TYPO3-CORE-SA-2021-013 was applied - it just does
      not process anything.
      
      Resolves: #94786
      Releases: master, 11.3, 10.4, 9.5
      Change-Id: I4aee54d712ce4758f6c9c2e64a43f80b6c076406
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70404
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      6a197e75
  27. 13 Aug, 2021 1 commit
  28. 12 Aug, 2021 1 commit
    • Nikita Hovratov's avatar
      [FEATURE] Register SoftReference parsers via DI · 48810cb7
      Nikita Hovratov authored and Benni Mack's avatar Benni Mack committed
      The concept for registration and usage of soft reference parsers
      received a complete overhaul.
      
      Starting with the registration, it is now possible to register soft
      reference parsers by dependency injection in the extension's
      Services.(yaml|php) file. For this, the new tag name
      "softreference.parser" has been introduced. One has to provide the
      additional attribute "parserKey" to identify the parser. This
      replaces the old way of registering these parsers in the $GLOBALS
      array. If a parser is registered with the same key in both ways,
      the old way takes precedence for b/w compatibility.
      
      This comes with a completely new factory service class
      TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory.
      This classes' responsibilities are collecting all registered soft
      reference parsers and serving them to the consumer by calling the
      method "getSoftReferenceParser" with the desired parser key as the
      only argument. There is a compatibility layer for the old way of
      registration and for classes not implementing the new interface.
      
      Soft reference parsers now have to implement
      TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserInterface.
      The interface defines the implementation of the "parse" method.
      The first 4 and the last parameter stay the same as in the old method
      "findRef". The remaining two parameters "spKey" and "spParams" have to
      be set with the "setParserKey" method, if they are needed. The key can
      be retrieved by using the "getParserKey" method.
      
      The different parser implementations in the old class
      TYPO3\CMS\Core\Database\SoftReferenceIndex have been extracted and
      moved into dedicated classes in the
      TYPO3\CMS\Core\DataHandling\SoftReference namespace. Missing tests
      for parsers other than "typolink" and "typolink_tag" are added.
      
      The method makeTokenID of SoftReferenceIndex has been moved into
      TYPO3\CMS\Core\DataHandling\SoftReference\AbstractSoftReferenceParser.
      A parser can extend this abstract class, if this method is needed.
      
      The methods of BackendUtility "softRefParserObj" and
      "explodeSoftRefParserList" are now deprecated and the replacement
      TYPO3\CMS\Core\DataHandling\SoftReference\SoftReferenceParserFactory
      should be used instead.
      
      Resolves: #94687
      Resolves: #94741
      Releases: master
      Change-Id: I460bfdd4478194fa4b4111fc44871f7225c6c084
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70177
      
      
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Oliver Bartsch's avatarOliver Bartsch <bo@cedev.de>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      48810cb7
  29. 10 Aug, 2021 1 commit
    • Oliver Hader's avatar
      [SECURITY] Ensure XSS-safe rich text rendering · 3dca584c
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Due to missing internal handling of provided RTE configuration, it
      was possible to directly persist XSS in database fields. Unless full
      blown backend RTE tag configuration is available, this patch still
      allows persisting potentially malicious data - which is not reflected
      in the backend user interface - but to be sanitized during frontend
      rendering (see below).
      
      Corresponding configuration directives (`removeTags`, `allowedAttribs`)
      are now considered again. Besides that a new, but simplified sequential
      HTML parser ensures that runaway node-boundaries are detected & denied.
      
      To sanitize and purge XSS from markup during frontend rendering, new
      custom HTML sanitizer has been introduced, based on `masterminds/html5`.
      Both `DefaultBuilder` and `CommonVisitor` provide common configuration
      which is in line with expected tags that are allowed in backend RTE.
      Using a custom builder instance, it is possible to adjust for individual
      demands - however, configuration possibilities cannot be modified using
      TypoScript - basically since the existing syntax does not cover all
      necessary scenarios.
      
      Resolves: #94375
      Related: #83027
      Related: #94484
      Releases: master, 11.3, 10.4, 9.5
      Change-Id: I5f8de43faab57b00052614ad37bd10ea9e384dc0
      Security-Bulletin: TYPO3-CORE-SA-2021-013
      Security-References: CVE-2021-32768
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70345
      
      
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      3dca584c
  30. 05 Aug, 2021 1 commit
  31. 04 Aug, 2021 1 commit
    • Helmut Hummel's avatar
      [TASK] Quote database identifiers when used instead of globally upfront · 55b8185f
      Helmut Hummel authored
      The implementation of the bugfix https://review.typo3.org/53360
      was done by iterating over TCA during cache generation and
      correctly quoting SQL fragments that are provided, to after
      that store TCA in cache.
      
      This has disadvantages:
      
      1. A DB connection is required to create TCA cache:
      This makes efforts for warming up caches upfront impossible,
      as cache warmup should be able to be performed on build
      systems without DB connection.
      
      2. It separates code that executes a query from code that
      is preparing a query: Escaping arguments for a query in a
      different place than the actual query execution can be
      considered an anti pattern, because at other points it isn't
      clear in which context these values are used. Beside that,
      performing the actual query, undoing DB encoding and redoing
      a different encoding is impossible.
      
      Pre-processing / quoting identifiers upfront can be considered
      a similar anti pattern as well. Despite there are less use
      cases to perform operations on the original non quoted
      identifiers, post processing of such fields in an event
      is impossible with the current implementation.
      
      3. The current implementation being buggy and the adoption
      in TYPO3 is sparse: While this could be tackled with according
      fixes, it shows that this feature, that has been implemented
      a couple of years ago and is a technical burden, is rarely
      used, and therefore the implementation can be simplified and
      cleaned up.
      
      The patch drops this TCA preparation and field name escaping
      is now done in places where the queries are actually built.
      
      Strictly seen this is a breaking change for implementers of
      the TCA post processing event or for custom code that directly
      uses TCA to perform query parts.
      
      It is unlikely though that such code exists in userland,
      nonetheless a feature flag "runtimeDbQuotingOfTcaConfiguration"
      is introduced to allow extensions to also use the feature flag
      and use the quoting on demand if not done before.
      
      For TYPO3 v12, this feature flag will be enabled at all times.
      
      Releases: master
      Resolves: #94697
      Change-Id: Ie0e48054def29c6c1e2810c8d30528c719439d9f
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69507
      
      
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      55b8185f
  32. 02 Aug, 2021 1 commit
    • Oliver Bartsch's avatar
      [FEATURE] Introduce TCA type "category" · 1e7653ce
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      A new TCA type "category" is introduced, which
      allows to simplify the configuration of category
      TCA columns. Besides the benefit for integrators,
      this allows to deprecate the CategoryRegistry
      in the next step.
      
      The new type can also be used for other use cases.
      Therefore, the TCA option "relationship" is available
      for this TCA type. Besides "manyToMany" (default), this
      can also be set to "oneToOne" or "oneToMany".
      
      Using the new type, FormEngine will always render a
      category tree. This means, no additional `renderType`
      is defined. In such case, TCA type "select" can
      still be used as before, without any limitation. However,
      all relevant places in core are adjusted in this patch.
      
      The category element is rendered through a custom element
      (web component), reducing inline javascript.
      
      Resolves: #94622
      Releases: master
      Change-Id: I1b95c42288b070fa6bac114266f5ad246a045b21
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69899
      
      
      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>
      1e7653ce
  33. 06 Jul, 2021 1 commit
  34. 29 Jun, 2021 1 commit
    • Oliver Bartsch's avatar
      [TASK] Avoid usages of sys_language in site configuration · da9c6df5
      Oliver Bartsch authored and Benni Mack's avatar Benni Mack committed
      This patch removes the last remains of sys_language in the
      site configurations' TCA.
      
      Therefore, the TCA of `site` and `site_langauge` is changed
      to always retrieve possible site languages via an itemsProcFunc,
      instead of using a relation to sys_language.
      
      As new site languages now have to be created in the module
      directly, a new internal TCA type "siteLanguage" is introduced.
      The new type behaves similar to type "inline", but contains some
      necessary features, e.g. unique record selector box next to a
      "create new" button, which are not available in type "inline".
      Also some not needed functionality is omitted.
      
      Instead of the sys_language records, all available site languages
      from all existing site configurations are now presented in the
      selector box. On selecting one of them, a new site language record
      is created, with most of the fields pre filled.
      
      Resolves: #94399
      Releases: master
      Change-Id: I60ac5b4259aa3c9d90a4aba9881bc1dc2341b464
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69188
      
      
      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>
      da9c6df5
  35. 21 Jun, 2021 1 commit
  36. 11 Jun, 2021 1 commit
  37. 09 Jun, 2021 1 commit
  38. 06 May, 2021 1 commit
  39. 25 Mar, 2021 1 commit
  40. 16 Mar, 2021 1 commit
    • Benni Mack's avatar
      [FEATURE] Introduce TCA type "language" · 954a3f08
      Benni Mack authored and Christian Kuhn's avatar Christian Kuhn committed
      A new TCA type "language" is added, in order to make life easier
      to set up new TCA. The main issue (as can be seen in core already)
      is that each TCA adds different implementations on how to deal with
      "-1". Now "-1" is added for any record except "pages", where the
      "-1 / All Languages" concept is not implemented.
      
      In addition, this decouples the select type from sys_language,
      effectively reducing the logic where a direct access is necessary
      to the "sys_language" table.
      
      This effectively also removes the now mis-use of `foreign_table`
      from the TCA "languageField" field by properly handling languages
      internally. This furthermore makes any relation handling superfluous,
      reducing quite an amount of code and complexity in the DataHandler.
      
      Instead, all columns, defined as "[ctrl][languageField]", are now
      automatically migrated to the new "type=language", with no specific
      configuration, as TYPO3 is managing this field, taking care of the
      user specific configuration.
      
      Furthermore, are all columns, using the “special=languages” option,
      migrated to the new TCA type. This allows to get rid of this special
      case as well, reducing complexity in FormEngine and DataHandler.
      
      The new TCA type also properly handles the field for records on
      root level, or on a page outside of a site context. The only
      exception is the `allowed_languages` field in be_users and
      be_groups, where a new itemsProcFunc is used.
      
      Resolves: #57082
      Releases: master
      Change-Id: Ic4878326c0cdc6ce1f233fa29f07419bf6b572a4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60293
      
      
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: core-ci's avatarcore-ci <typo3@b13.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      954a3f08