- Feb 07, 2023
-
-
Benjamin Franzke authored
Make clear that the early-bail out for empty pageArguments is done to prevent setting `disableCaches` to `true`. Also makes that that the $pageNotFoundOnCacheHashError condition is really tied to pageArguments being non-empty. Prevents us from refactoring that code and missing this bit. Resolves: #99860 Related: #99859 Releases: main, 11.5, 10.4 Change-Id: I98ffa3dffe76a37970784979a2c4f2a9a64aa5bf Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77752 Tested-by:
Stefan Bürk <stefan@buerk.tech> Tested-by:
Nikita Hovratov <nikita.h@live.de> Tested-by:
core-ci <typo3@b13.com> Reviewed-by:
Benjamin Franzke <bfr@qbus.de> Reviewed-by:
-
Oliver Hader authored
If $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation'] is enabled and the HTTP request only contains the `?id` query parameter, caching for the page is disabled - which should be avoided. Resolves: #99859 Releases: main, 11.5, 10.4 Change-Id: I14a81f5a2ec3ecabedd1abf0756a3ee32e7af4e4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77734 Tested-by:
Oliver Bartsch <bo@cedev.de> Reviewed-by:
-
- Feb 06, 2023
-
-
Benni Mack authored
When no cHash is given but GET parameters are handed in which _would_ require cHash parameters, these are now properly evaluated during the frontend request. As this has a security impact, a new option called $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation'] is introduced, which then skips the "requireCacheHashPresenceParameters" option. The latter is an include list, but cache Hash calculation should rather be based on the exclude list such as "excludedParameters" and "cachedParametersWhiteList". If the new option is set, but some properties such as tx_solr[q] should be allowed, then this needs to be added to the excludedList ("excludedParameters") by extension authors. A new test "SlugSiteWithoutRequiredCHashRequestTest" is added which works with a disabled feature flag compared to "SlugSiteRequestTest" which has the feature flag enabled. Resolves: #95297 Releases: main, 11.5, 10.4 Change-Id: Ib72c6a34602e77d8c2044ad2e826c0474ebd2326 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/77712 Tested-by:Oliver Hader <oliver.hader@typo3.org> Tested-by:
-
- Sep 13, 2022
-
-
Stefan Bürk authored
With #98331 friendsofphp/php-cs-fixer has been raised in v11. However, pre-merge ci only scans for cgl in changed php files. Thus no scan has been run on all php files and cgl violations were not detected. Nightly revealed them. This change runs cgl fix on all files to align them to the current rules and style. Used commands: > Build/Scripts/runTests.sh -s cgl Resolves: #98338 Related: #98331 Releases: 11.5 Change-Id: I98863b7bc28ea4e751a0b69f65eb4589db97b844 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/75698 Tested-by:
Andreas Fernandez <a.fernandez@scripting-base.de> Tested-by:
-
- Aug 04, 2021
-
-
Benni Mack authored
PSR3 ships with a LogLevel class, whereas TYPO3 Core ships its own logging API which is based on a numeric log level syntax. This change reduces the amount of usages of numeric usages of error / message magic (such as TimeTracker), thus, slowly migrating towards PSR3-based LogLevels everywhere. Resolves: #94702 Releases: master Change-Id: I359c88ce50ab94ef1022be975c07f4a7e3c25d0d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/70168 Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Tested-by:
Benni Mack <benni@typo3.org> Reviewed-by:
Wouter Wolters <typo3@wouterwolters.nl> Reviewed-by:
-
- Jun 16, 2021
-
-
Larry Garfield authored
PSR-3 has specific rules around interpolation: Messages may provide placeholders like {foo} and writers should substitute these in the messages if a context array with such a key is provided. Let's use placeholders correctly. Resolves: #94315 Related: #94356 Releases: master Change-Id: I2c285e84f1832c80828861369e99af9aff6cd267 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69425 Tested-by:Anja Leichsenring <aleichsenring@ab-softlab.de> Tested-by:
-
- May 17, 2021
-
-
Oliver Hader authored
Resolves: #94148 Releases: master, 10.4, 9.5 Change-Id: If1378f2d471f18099b55b05a84dc81adc247bc69 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69158 Tested-by:
-
- Apr 15, 2020
-
-
Alexander Schnitzler authored
With this patch, the header comment of php files is automatically added by the php-cs-fixer, which guarantees that its format and place of occurrence remain the same in all files. Files that are copied over from other projects are excluded. Furthermore, files that are kind of inspired by other projects also get the same header comment but may have a second, additional comment explaining its origin. Used command: bin/php-cs-fixer fix --config=Build/php-cs-fixer/header-comment.php Releases: master Resolves: #91024 Change-Id: I5a040517e0fbde6e5a27d589bf2f222078326dc8 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64159 Tested-by:TYPO3com <noreply@typo3.com> Tested-by:
-
- Apr 14, 2020
-
-
Benni Mack authored
This change adds two changes 'blank_line_after_opening_tag' => true, 'single_trait_insert_per_statement' => true, to our PHP-CS Fixer configuration, adopting more rules related to PSR-12. Resolves: #91020 Releases: master Change-Id: I180b2cbceb077911bddeb42d9f131e5b32244ed2 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/64158 Tested-by:Josef Glatz <josefglatz@gmail.com> Tested-by:
Alexander Schnitzler <git@alexanderschnitzler.de> Tested-by:
-
- Apr 13, 2020
-
-
Alexander Schnitzler authored
As a preparation to be compatible with PSR-12, all spaces in strict type declerations are removed. Releases: master Resolves: #91009 Change-Id: I2b7c2fda42b44168b5c4c6b21711eede2eadaf2e Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62104 Tested-by:
-
- Dec 06, 2019
-
-
Benni Mack authored
Since TYPO3 v10.0, all links generated by TYPO3 contain a cHash if - there are arguments that are not mapped within the routing - there are arguments that are not explicitly "excluded" from cHash (e.g. fbclid) - there are arguments that are not internal (L,id,MP). The PageArgumentValidator middleware now always evaluates the arguments properly at every request and decides to disable caching or throw a 404, if an incoming request does not have a cHash or an invalid cHash. Through the middleware, any plugin is automatically checked for the cHash, and it does not matter anymore for plugins, so it does not matter for integrators or template authors as well as cHash is managed internally by TYPO3 Core now (with no way to disable it, for security reasons). All functionality regarding cHash that can be dropped: - CacheHashEnforcer and Extbase option - TSFE->reqCHash() can be marked as deprecated - the option within PiBased Plugins is now irrelevant as well. This change jointly decouples cHash evaluation from any other part than Url Generation (= PageRouter) and Resolver (PageArgumentValidator), finally streamlining all logic of cHash functionality. Resolves: #89868 Releases: master Change-Id: I7a694fbc95fa1ea4dc85b12a94b0a06b3722fd11 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/62267 Tested-by:
Susanne Moog <look@susi.dev> Tested-by:
Frank Nägler <frank.naegler@typo3.org> Reviewed-by:
Markus Klein <markus.klein@typo3.org> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
-
- Aug 06, 2019
-
-
Benjamin Franzke authored
Use constructor injection for middleware dependencies, moving away from GeneralUtility::makeInstance based Singleton lookup. Dependencies which are already configured to be optionally injectable via constructor arguments (e.g. for unit tests) are changed to be required constructor arguments. Since the introduction of symfony dependency injection the fallback to GeneralUtility::makeInstance is no longer used – therefore it is dropped. Releases: master Resolves: #88800 Change-Id: I6dbec2f91fc78c1b06dd179323fb7a4810c13baa Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61322 Tested-by:
-
- Jul 13, 2019
-
-
Benni Mack authored
This patch re-arranges the TYPO3 Core internally used middlewares for lifting off the weight of $GLOBALS['TSFE'] as Site Handling already introduced a lot of functionality which can now be utilized further. For this reason, the Frontend Rendering chain has been adapted. * If there is a "Site" + "Language" resolved, this information can be used directly, as there are no dependencies currently. * Frontend + Backend User Authentication works regardless of TSFE, Frontend User is added to the Request object as attribute to be added to TSFE later-on. * Resolving the Page ("slug") and mapping them to Page Arguments (URL parts + GET parameters) as well as validation against cHash is fully decoupled from TSFE. After that, TSFE is instantiated, which now gets all resolved objects injected. TSFE now only resolves the rootline against the proper permissions (auth) and validates the final page. Once done, TypoScript is compiled / cached. TSFE still contains the rootline, TypoScript, and the information about which non-cacheables are there. RequestHandler creates or fetches cached content, but currently piped through TSFE. This should be simplified further later-on. Resolves: #88717 Releases: master Change-Id: I12807455fd8b01493b2da45cf73a5c532b108cbe Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/61155 Tested-by:
-
- Jun 26, 2019
-
-
Benni Mack authored
Checking if cHash matches any GET parameters can be done without $TSFE->cHash_array and $TSFE->hash as all data is built inside PageArguments already. However, $TSFE->cHash_array is still necessary and filled as before when ->setPageArguments() is called. This is a precursor to re-structure the dependencies within TSFE and PSR-15 middlewares. Resolves: #88460 Releases: master Change-Id: I43c2fdc1049d451b3fc9bc06a57b744703a7a323 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60841 Tested-by:
Daniel Gorges <daniel.gorges@b13.de> Tested-by:
-
- Jun 14, 2019
-
-
Benni Mack authored
Introduced with https://review.typo3.org/c/Packages/TYPO3.CMS/+/60895 cHash's that are used within the URL but not needed anymore, should rather create a redirect instead of silently unsetting the cHash argument. Related: #41033 Resolves: #88531 Releases: master, 9.5 Change-Id: Iaae3e72160c055f8848942d506f7cc3e25d31af4 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60905 Tested-by:
Nicole Cordes <typo3@cordes.co> Tested-by:
-
- Jun 08, 2019
-
-
Benni Mack authored
If a cHash GET parameter is given, but there are no GET parameters that are relevant, a hash_calc() call against an empty string is done. However, the change now allows an invalid cHash if no check is necessary. This could happen when upgrading from older instances where a cHash is not needed anymore. Bots would not then fill up the error log but get the new page (with a valid 200 result) Resolves: #41033 Releases: master, 9.5 Change-Id: Id02701fcbece371a6b9ce0f92fe0be55dd972325 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/60895 Tested-by:
Georg Ringer <georg.ringer@gmail.com> Reviewed-by:
-
- Jan 07, 2019
-
-
Benni Mack authored
This is a precursor for removing PseudoSiteHandling in general. The database field "pages.alias" field is dropped, along with the functionality to evalute if a frontend request "?id=acme" is non-integer, as it now always has to be integer. Existing links pointing to page aliases will stop working. Resolves: #87356 Releases: master Change-Id: I19134cc788e633e140b43497f716082ac96744e5 Reviewed-on: https://review.typo3.org/59232 Tested-by:
TYPO3com <no-reply@typo3.com> Reviewed-by:
-
- Nov 05, 2018
-
-
Stefan Neufeind authored
Adds a new method HttpUtility::buildQueryString() using http_build_query() instead of reimplementing the encoding-process like the old method GeneralUtility::implodeArrayForUrl() did. As the parameter $rawurlencodeParamName of implodeArrayForUrl() was set to "false" by default and used in several places without manually setting it to "true" using that method could lead to potentially unsafe non-encoded parameter names. Some unit-tests had wrong URLs with non-encoded braces [...], which were adapted to be properly escaped as well. Resolves: #83334 Releases: master Change-Id: Ifbaad912f0d658671356dc7bdf1579dacff272df Reviewed-on: https://review.typo3.org/55079 Reviewed-by:
-
- Sep 30, 2018
-
-
Benni Mack authored
PageArguments are fetched and added on top of PSR-7 request queryParams right after they are validated from the PageRouter. They are also re-populated after config.defaultGetVars has modified global state. But they do not need to be set to TSFE again within the the PageArgumentValidator middleware. Resolves: #86483 Releases: master Change-Id: I03df4223832845038d4207417cfcab7cbcc687dc Reviewed-on: https://review.typo3.org/58507 Tested-by:
Susanne Moog <susanne.moog@typo3.org> Tested-by:
-
- Sep 29, 2018
-
-
Benni Mack authored
Page-based routing can now be configured within a site configuration to add so-called "route enhancers" which allow to add more placeholders to a route for a page. There are three Enhancers that TYPO3 now ships with: - SimpleEnhancer - PluginEnhancer - ExtbasePluginEnhancer It is also possible to add custom enhancers by third- party extensions. Each placeholder within an enhancer can receive a so-called "Aspect", usually used for mapping speaking values instead of IDs, or month-names in an archive link, and "modifiers" to modify a placeholder. The simple enhancer transfers a link parameter, previously maybe used to add a `&product=123`, which will now result into `/product/123` for a page. PluginEnhancer adds a namespace, common for simple plugins or Pi-Based plugins, and the ExtbasePluginEnhancer adds logic for multiple route variants to be added, depending on the controller/action combinations. Aspects are processors / modifiers / mappers to transfer a placeholder value back & forth to make each placeholder value more "speaking". TYPO3 Core ships with the following aspects: * LocaleModifier (for localized path segments) * StaticValueMapper (for path segments with a static list) * StaticRangeMapper (for pagination) * PersistedAliasMapper (for slug fields) * PersistedPatternMapper (for database records without slug fields) Routing now returns a so-called "PageArguments" object which is then used for evaluating site-based URL handling and the cHash calculation. It is highly discouraged to access _GET or _POST variables within any kind of code now, instead the PSR-7 request object should be used as much as possible. Releases: master Resolves: #86365 Change-Id: I77e001a5790f1ab3bce75695ef0e1615411e2bd9 Reviewed-on: https://review.typo3.org/58384 Tested-by:
-
- Sep 28, 2018
-
-
Benni Mack authored
In order to be in line with the new PageArguments object, this newly introduced class is now renamed. Resolves: #86431 Releases: master Change-Id: I96575338538641fc27a578c49868b21100b61ed3 Reviewed-on: https://review.typo3.org/58446 Reviewed-by:
-
Benni Mack authored
The functionality is moved into a new PSR-15 middleware to base the logic on the request object directly, and to make the validation more flexible when validating page parameters for site-based routing. The previous deprecation to add the request object to the method has been reverted. Resolves: #86411 Releases: master Change-Id: I294fae7e7c0f9eb1e128a88238dabdd8ed27619f Reviewed-on: https://review.typo3.org/58420 Reviewed-by:
Jan Helke <typo3@helke.de> Tested-by:
-
