1. 05 May, 2021 1 commit
  2. 18 Mar, 2021 2 commits
  3. 16 Mar, 2021 3 commits
  4. 15 Mar, 2021 1 commit
  5. 11 Mar, 2021 1 commit
  6. 27 Feb, 2021 1 commit
  7. 17 Feb, 2021 1 commit
  8. 11 Feb, 2021 1 commit
  9. 01 Feb, 2021 1 commit
  10. 21 Dec, 2020 1 commit
    • Imko Schumacher's avatar
      [BUGFIX] Set timezone on TCA dbType input · bd55644a
      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/+/67201
      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>
  11. 15 Dec, 2020 1 commit
  12. 13 Dec, 2020 1 commit
  13. 25 Nov, 2020 1 commit
  14. 17 Nov, 2020 2 commits
  15. 29 Sep, 2020 1 commit
  16. 25 Sep, 2020 1 commit
  17. 17 Sep, 2020 1 commit
  18. 08 Sep, 2020 1 commit
  19. 07 Sep, 2020 1 commit
  20. 05 Sep, 2020 1 commit
    • Christian Kuhn's avatar
      [TASK] CSV integrity test script can fix fixtures · 341fc266
      Christian Kuhn authored
      CSV fixture files are a straight way to feed test database
      with stuff and to assert database state after operations.
      Script Build/Scripts/checkIntegrityCsvFixtures.php tests those
      files for integrity, making sure all lines have the same number
      of columns. Maintaining the number of commas when fiddling with
      functional tests however is annoying.
      The patch adds options to checkIntegrityCsvFixtures.php:
      * '--fix' simply fixes files with broken integrity
      * '--fixAll' goes through all files and looks for details
        like superfluous comma.
      While --fixAll is used once now to establish a good baseline
      on all .csv fixtutre files, --fix can be used whenever the
      integrity script mumbles about broken stuff:
      Build/Scripts/checkIntegrityCsvFixtures.php --fix
      It is also added to runTests.sh:
      Build/Scripts/runTests.sh -s fixCsvFixtures
      Change-Id: Idee2a97094f56d059b02f801ffecb50a7ce21a5c
      Resolves: #92207
      Releases: master, 10.4, 9.5
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65589
      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>
  21. 17 Aug, 2020 1 commit
  22. 03 Aug, 2020 1 commit
  23. 28 Jul, 2020 1 commit
  24. 27 Jul, 2020 1 commit
  25. 25 Jul, 2020 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Adjust processing order of routes during URL generation · 6fd7c3c4
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      Prior to this patch routes were processed in reverse definition order.
      Routes defined last came first. Depending on the existence of variable
      defaults this behavior produced a couple of unexpected results.
          routePath: '/route/{a}/{b}'
          routePath: '/route/{c}'
            c: '0'
      The example above, processed in reverse order and having parameters
      `a` and `b` given, still resulted in `second` route being used since
      the missing parameter `c` was defined by corresponding variable default.
      This change adjusts the order of routes depending on given parameters,
      completeness of a route (when all parameters are given, even defaults).
      Sorting is adjusted based on the following criteria:
      * default routes (e.g. `/my-page`) - processed later
      * static routes (e.g. `/my-page/list`) - processed later
      * all variables are given (complete) - processed earlier
        (e.g. parameters `a` and `b` are given for route `/route/{a}/{b}`)
      * all mandatory variables are given (complete) - processed earlier
      * less missing variable defaults - processed earlier
      * less variable defaults amount - processed earlier
      Tests in class `RouteSorterTest` provide more examples & details.
      Resolves: #90924
      Releases: master, 10.4, 9.5
      Change-Id: I26f56e6905472a501ff487295da23b3bc3b5c77e
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65041
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
  26. 30 Jun, 2020 1 commit
  27. 09 Jun, 2020 1 commit
  28. 05 Jun, 2020 2 commits
  29. 03 Jun, 2020 1 commit
  30. 19 May, 2020 1 commit
  31. 18 May, 2020 1 commit
    • Oliver Hader's avatar
      [BUGFIX] Allow multiple referrer types in backend main route · 6d9e803c
      Oliver Hader authored and Oliver Hader's avatar Oliver Hader committed
      With TYPO3-CORE-SA-2020-006 (SSRF via XSS) a strict referrer handling
      has been introduced to avoid the TYPO3 backend being called from other
      non same-origin locations. In case a HTTP referrer header was empty
      the system tried to refresh the view - otherwise the request was
      denied completely.
      It turned out that this scenario was probably too strict, disabling
      feature `security.backend.enforceReferrer` was the only work-around
      for site administrators.
      This change adds new options for handling referrers in backend routes:
      * refresh-empty (existed already): refresh in case referrer is empty
      * refresh-same-site: refresh in case referrer is on same site, like
        `https://example.org/?eID=auth` calling `https://example.org/typo3/`
      * refresh-always: refresh always in case there is not valid referrer
      TYPO3's main backend route is using `refresh-always` now to be more
      relaxed on handling same-site and cross-site referrers as well.
      The term "refreshing" relates to trigger a reload in the browser to
      get the referrer of the current location. This still block direct
      CSRF/SSRF requests since the refreshing HTML instructions are
      delivered back to the client. Besides that, cross-site requests are
      covered by the `same-site` cookie policy, and existing CSRF tokens.
      Resolves: #91396
      Releases: master, 9.5
      Change-Id: Ib3756671fa60c6f41ba992d0e645f03da1730d19
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64499
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
      Reviewed-by: Oliver Hader's avatarOliver Hader <oliver.hader@typo3.org>
  32. 15 May, 2020 1 commit
  33. 14 May, 2020 1 commit
  34. 12 May, 2020 1 commit
  35. 11 May, 2020 1 commit
    • David König's avatar
      [BUGFIX] Correctly evaluate "unique" eval for slug fields · d3297faa
      David König authored and Helmut Hummel's avatar Helmut Hummel committed
      TYPO3 v9.5.16, fixed functionality for URL resolving
      for records with slug fields defined as "uniqueInSite".
      With such setting, it is important to limit URL resolving
      to the site the slugs are generated for. Because we currently
      don't support records to be stored within one site, but
      generating slugs for another one, this change enforced the storage
      of news records to be in the same site as the detail page.
      This however led to not working installations, where a record storage
      folder is available in a site where other sites are fetching this
      information from, which is a quite common use case.
      To cover such use case, TCA needs to be adapted to the existing configuration
      eval=unique, which diables the site check in URL frontend resolving.
      However the current implementation of DataHandler only checks uniqueness
      of fields of type "input".
      This means for slug fields, the functionality of 'unique'
      is currently not taken into account when generating the slug,
      which can lead to duplicate slugs.
      To fix this problem, a check for the unique eval setting is added to
      DataHandler and FormSlugAjaxController. SlugHelper is adapted
      to correctly generate slugs for this use case.
      Resolves: #91235
      Releases: master, 9.5
      Change-Id: Id6e5c1d27860b09604787132f2cd83976418baa4
      Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64455
      Tested-by: default avatarTYPO3com <noreply@typo3.com>
      Tested-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>
      Reviewed-by: Helmut Hummel's avatarHelmut Hummel <typo3@helhum.io>