1. 21 Dec, 2020 2 commits
    • Imko Schumacher's avatar
      [BUGFIX] Set timezone on TCA dbType input · 6b0be8e1
      Imko Schumacher authored and Benjamin Franzke's avatar Benjamin Franzke committed
      The value from columns that are marked as "dbType" date(time) fields
      in TCA configuration are now explicitly interpreted using UTC timezone,
      when the string value has no timezone specifier given.
      JS supplied values contain Z as specifier, while records from the database
      (which are processed during copy operations) do not contain a timezone
      Local time was assumed by PHP in the latter case before, as we did not
      pass an explicit timezone information to the DateTime constructor.
      Therefore we now assure no timezone conversion will happen and no
      time/date-offset will be added, by using UTC explicitly.
      Resolves: #89914
      Releases: master, 10.4, 9.5
      Change-Id: I8e531ae5f3367c4493ce1e7db4bec0ef02311e24
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67200
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
    • Christian Kuhn's avatar
      [TASK] Increase session id db field size · ef816532
      Christian Kuhn authored and Benni Mack's avatar Benni Mack committed
      Since one of the recent security patches, frontend and
      backend user sessions are stored as HMAC-SHA256 if using
      redis storage backend, and HMAC-MD5 if using default
      database storage backend.
      Reason for using the less collision resistant md5 in
      database backend over sha256 has been, that the 64
      characters of sha256 did not fit into the varchar(32)
      field of the ses_id fields. This would have led to
      trouble for users upgrading to the security patch level
      We now increase the field size to varchar(255) with this
      patch, and backport this to v10. A second patch will then
      switch only v11/master to sha256. This way, users
      can increase db field size in v10 already to prepare for
      v11 and later upgrade to v11 without being logged out or
      experiencing db errors. Only users running current
      master will have to use the standalone install tool once
      to increase field size.
      Strictly, a field size of 64 characters would be enough
      for sha256, we however raise to 255 to never run into
      this chicken-egg issue again - just in case.
      Resolves: #93131
      Releases: master, 10.4
      Change-Id: Ifcafba0c3bae2f27ba0e13e6925007a6e1627d88
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67199
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
      Reviewed-by: Benni Mack's avatarBenni Mack <benni@typo3.org>
  2. 20 Dec, 2020 3 commits
  3. 19 Dec, 2020 2 commits
  4. 17 Dec, 2020 1 commit
  5. 16 Dec, 2020 1 commit
  6. 15 Dec, 2020 2 commits
  7. 14 Dec, 2020 3 commits
    • Helmut Hummel's avatar
      [BUGFIX] Implement deferred BE image processing consistently · 0c5439f2
      Helmut Hummel authored and Georg Ringer's avatar Georg Ringer committed
      Change the implementation of backend deferred image processing
      to use a file processor, which is only but always used in the backend.
      By doing so all limitations of the current implementation are resolved,
      which means, width and height of the image can be set in HTML, to avoid
      layout shifts and once the images are processed, they will simply
      be delivered by the web server.
      Inconsistencies with thumbnail ratio (depending on crop being defined
      or not) are also tackled on the go.
      While this changes processing configuration for some files,
      which triggers a re-generation, it should not matter, as image
      processing will be done in parallel on request, making such changes
      viable in a bugfix release.
      The introduced database field is neither used nor required for the
      current implementation, but is introduced to provide a possibility for
      third party processors to replace the current implementation with simple
      (and persisted) URLs to third party SaaS image processing services.
      Resolves: #92188
      Releases: master, 10.4
      Change-Id: I8d1e14324085c5b6ba646475206c8cb10a1fc10d
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66587
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
      Reviewed-by: Georg Ringer's avatarGeorg Ringer <georg.ringer@gmail.com>
    • Christian Kuhn's avatar
      [BUGFIX] More deterministic mm sorting · 3f22bb9e
      Christian Kuhn authored
      A 'true' MM relation (select / group with MM, but not inline
      with foreign_field - used in core for pages/tt_content table
      to sys_category via sys_category_record_mm) has two sorting
      fields: 'sorting' for the local (sys_category) side, and
      'sorting_foreign' for the foreign (pages / tt_content) side.
      When categories are added to a tt_content element,
      'sorting_foreign' is set to the given order of sys_category
      elements. 'sorting' is set to 0. When then opening a
      sys_category record that has multiple records pointing to
      it with 0 as sorting, the returned order of records is
      non-deterministic and depends on implicit DB engine fallbacks.
      This also confuses the reference index, which checks
      refindex integrity always from the 'local' side.
      The patch adds 'uid_foreign' as second order-by field to
      force deterministic ordering. There is still a possible
      collision in multi table relations (more than one foreign
      table uses the mm table like pages AND tt_content to
      sys_category with foreign records having the same uid) and
      if the mm table allows "multi" relations. Those scenarios
      however have no explicit TCA configuration (only implicit
      via MM_match_fields), need a deeper investigation and
      possibly further detail patches later.
      The patch should for now fix a functional test that is
      flaky with postgres.
      Change-Id: I3c89d0e67f8a4065354f9df173020ca0080e0d57
      Resolves: #93075
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67058
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
    • Christian Kuhn's avatar
      [TASK] Raise typo3/testing-framework to ^6.6.0 · 2bfe77bd
      Christian Kuhn authored
      Makes lit-html loadable in unit tests.
      composer require --dev typo3/testing-framework ^6.6.0
      Change-Id: I4b5cbf0825d12708882e744b10ffa31b78332c25
      Resolves: #93074
      Releases: master, 10.4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67114
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Benjamin Franzke's avatarBenjamin Franzke <bfr@qbus.de>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  8. 13 Dec, 2020 2 commits
  9. 12 Dec, 2020 1 commit
  10. 11 Dec, 2020 1 commit
  11. 10 Dec, 2020 5 commits
  12. 08 Dec, 2020 3 commits
  13. 07 Dec, 2020 2 commits
  14. 05 Dec, 2020 1 commit
  15. 04 Dec, 2020 3 commits
  16. 02 Dec, 2020 1 commit
  17. 01 Dec, 2020 4 commits
  18. 29 Nov, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Add application type to request · 26ae838c
      Christian Kuhn authored
      The cardinal issue with constant 'TYPO3_MODE' is that it's
      value is NOT constant: It is defined early during bootstrap and
      derived from information that is hand over from entry point
      index.php's. Depending on this, value is either 'FE' or 'BE'.
      Using that constant or the related constant 'TYPO3_REQUESTTYPE'
      makes it impossible to change scope from backend to frontend
      in one PHP call. This actively blocks executing sub requests,
      use cases are for instance executing a frontend request within
      a running backend call (eg. view module), or executing frontend
      requests from cli (eg. some indexer).
      Dropping 'TYPO3_MODE' and its friends is thus a requirement to
      finally allow such scenarios. We can't get rid of the distinction
      between 'frontend' and 'backend' altogether since some legit use
      cases like different paths or security settings depend on it.
      Looking at TYPO3 bootstrap, the only class that 'knows' if it's
      frontend or backend are the Application classes of ext:frontend
      and ext:backend. They are the PSR-15 entry points, they create a
      first PSR-7 request object if it has not been given, and then
      call the PSR-15 middleware stack dispatcher to create a PSR-7
      response, starting with this first request object.
      The solution to get rid of 'TYPO3_MODE' is to add the information
      'I am a frontend or backend request' as attribute to the request
      object in the Application classes. To simplify things, the helper
      class ApplicationType is introduced that answers isFrontend() and
      isBackend() for a given request object.
      Documentation changelog files with full details on the impact of
      this change will be added with an upcoming patch that deprecates
      the constants in master.
      This patch targets master and v10: 'TYPO3_MODE' is used in
      extensions quite often. Having the API in both v10 and v11 helps
      extension developers to deliver deprecation free extensions that
      are compatible with both v10 and v11 in one version. Codewise,
      neither the 'applicationType' attribute nor the helper class
      harm in v10.
      Resolves: #92951
      Related: #92947
      Releases: master, 10.4
      Change-Id: Ia4ea637b252b774cf72492402e6be52ee4695242
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66920
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  19. 28 Nov, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] Introduce constant 'TYPO3' · 1462f2a6
      Christian Kuhn authored
      TYPO3 still has some script files that run in global scope
      without class or callable encapsulation. Those are especially
      ext_localconf.php, ext_tables.php and Configuration/TCA/Overrides/*
      script files.
      When those files are located within document root, they can be
      called directly via HTTP and may output something, which can be
      a security risk. To prevent this, they have a call at the very
      start: 'defined('TYPO3_MODE') or die();'.
      Unfortunately, constant 'TYPO3_MODE' is a technical debt, core
      tries to phase it out in v11. We thus need something equivalent
      for these calls.
      Since that test for existance of a constant is so simple and
      straight forward, the solution is to define a new constant to
      true, simply named 'TYPO3', to substitute 'TYPO3_MODE'. The
      call is very similar: 'defined('TYPO3') or die();'.
      The patch targets core master and v10: Having that constant in
      v10 simplifies life of extension developers who want to deliver
      extensions compatible with v10 and v11 in the same version, when
      'TYPO3_MODE' constant is deprecated in v11 with upcoming patches.
      Resolves: #92948
      Related: #92947
      Releases: master, 10.4
      Change-Id: Ib7b438422a41e242cf49cd4f87a6f8c50a9907d3
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66919
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
      Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
  20. 27 Nov, 2020 1 commit