Upgrade Flow fork from 3.0.0 to 3.0.15 #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BUGFIX: orphanRemoval must be a true integer Doctrine expects a true boolean instead of a string (true in double quotes) for the orphanRemoval property. This change adapts the documentation to reflect that.
BUGFIX: If query is null the condition break This change casts the query (string) to string before checking if we need to append it. Without this change the condition to build the request URI is wrong when the query is null and the URI contains a question mark without request arguments.
The subpackage key is directly derived from the package key in the forward method. Previously, if the subpackage key was not provided, it would not be set in the next request. Therefore to forward to a non-subpackage from a subpackage it was required to specify the package key with trailing backslashes, so the subpackage key would resolve to an empty string. With this change it is possible by just specifying the actual package key to forward to.
BUGFIX: Always set subpackage key when setting package key in forward The subpackage key is directly derived from the package key in the forward method. Previously, if the subpackage key was not provided, it would not be set in the next request. Therefore to forward to a non-subpackage from a subpackage it was required to specify the package key with trailing backslashes, so the subpackage key would resolve to an empty string. With this change it is possible by just specifying the actual package key to forward to.
TASK: Add permissions check for setfilepermissions.sh Using the setfilepermissions.sh script fails due to wrong file permissions left by the composer installation (missing executable bit). Added the checking of the file's permissions, and correcting the file's permissions if needed. Mode 0700 is set as the setfilepermissions.sh script sets it's own permissions to that mode.
…his change log missing data during resource publishing. By default all notifications are logged in the system log. TASK: Handle missing data as a soft error during resource publishing This change log missing data during resource publishing. By default all notifications are logged in the system log. This change also introduce MessageCollector as the default API for resource storages and targets to provide error messages during publishing.
…using inheritance
…r trustedProperties configuration Before, when specifying a PropertyMappingConfiguration with a wildcard inside the initialize*Action() of a controller, this configuration would not be taken into account when a Fluid form was submitted, that set configuration for specific properties. This change makes the trustedProperties configuration happen *after* the user configuration, which in turn will lead to trustedProperties always only extend the user configuration and wildcard configurations to be used as the template configuration for the following specific trustedProperties configurations.
TASK: Add documentation about limitations of entity privileges When using inheritance for entities, privileges will only work with the root entity type. This was not documented before.
The CommandEvent and PackageEvent used in InstallerScripts are deprecated since early 2015.
TASK: Fix use of deprecated events in InstallerScripts
If a custom exception rendering fails, the exception would not be caught and thus difficult to debug. Instead as a fallback exceptions thrown during rendering will be rendered statically.
…exceptions BUGFIX: Fallback if custom exception rendering fails If a custom exception rendering fails, the exception would not be caught and thus difficult to debug. Instead as a fallback exceptions thrown during rendering will be rendered statically.
…ildcard TASK: Allow wildcard propertymapping configuration to set defaults for trustedProperties configuration Before, when specifying a PropertyMappingConfiguration with a wildcard inside the initializeAction() of a controller, this configuration would not be taken into account when a Fluid form was submitted, that set configuration for specific properties. This change makes the trustedProperties configuration happen *after* the user configuration, which in turn will lead to trustedProperties always only extend the user configuration and wildcard configurations to be used as the template configuration for the following specific trustedProperties configurations.
This reverts commit 241a416, caused by a bug in the reference update script. See neos/flow-development-distribution#24
This reverts commit dcda74f., caused by a bug in the reference update script. See neos/flow-development-distribution#24
## Problem Description If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with doctrine caching. ## Visible Error If you had Entity Constraints which did not only rely on different user roles, but needed the domain model to build up SQL constraints (through entity security), the query cache in production cached the SQL queries "wrongly", so you were able to see data from other accounts. ## Bugfix Inside the Doctrine CacheAdapter, we already namespace the full Doctrine cache with the SecurityContext's ContextHash. However, only roles were the source of the ContextHash. We now make it possible to add custom sources to the calculation of the ContextHash, by making aop.globalObjects able to contribute to the context hash calculation if they implement CacheAwareInterface. ## Custom SQL Filters / Root Cause Analysis It is not effective to call "setParameter" in the addFilterConstraint method of an SqlFilter; as this will interfere with Doctrine's query caching: Doctrine tries to avoid building queries as much as possible. It also takes the applied SqlFilters *and their parameters* into account when building cache identifiers, and if it has a matching cache entry, it will not call "addFilterConstraint". Thus, "setParameter" must be called as early as possible; way before the "addFilterConstraint" method might be called. We did not manage to find the fully right spot to do it inside the Framework, that's why we chose the more minimally-invasive solution here. ## Breakingness This change is only breaking if: - You used Entity Security AND custom context objects registered in `TYPO3.Flow.aop.globalObjects`: In this case, your global objects should very likely implement CacheAwareInterface. - You used custom SQL Filters: Basically you are not allowed to call `setParameter` inside `addFilterConstraint`; but setParameter must be called *before* the SQL query is actually executed. Currently, there's no standard Doctrine way to provide this; so you manually can receive the filter instance from `EntityManagerFactory::getEnabledFilterInstances()` and call `setParameter()` then. Alternatively, you can influence the Doctrine caching by registering a global context object in `TYPO3.Flow.aop.globalObjects` and use it to provide additional identifiers for the caching; effectively seggregating the Doctrine cache some more.
## Problem Description If you had used entity security and wanted to secure entities not just based on the user's role, but on some property of the user (like the company he belongs to), entity security did not work properly together with doctrine caching. ## Visible Error If you had Entity Constraints which did not only rely on different user roles, but needed the domain model to build up SQL constraints (through entity security), the query cache in production cached the SQL queries "wrongly", so you were able to see data from other accounts. ## Bugfix Inside the Doctrine CacheAdapter, we already namespace the full Doctrine cache with the SecurityContext's ContextHash. However, only roles were the source of the ContextHash. We now make it possible to add custom sources to the calculation of the ContextHash, by making aop.globalObjects able to contribute to the context hash calculation if they implement CacheAwareInterface. ## Custom SQL Filters / Root Cause Analysis It is not effective to call "setParameter" in the addFilterConstraint method of an SqlFilter; as this will interfere with Doctrine's query caching: Doctrine tries to avoid building queries as much as possible. It also takes the applied SqlFilters *and their parameters* into account when building cache identifiers, and if it has a matching cache entry, it will not call "addFilterConstraint". Thus, "setParameter" must be called as early as possible; way before the "addFilterConstraint" method might be called. We did not manage to find the fully right spot to do it inside the Framework, that's why we chose the more minimally-invasive solution here. ## Breakingness This change is only breaking if: - You used Entity Security AND custom context objects registered in `TYPO3.Flow.aop.globalObjects`: In this case, your global objects should very likely implement CacheAwareInterface. - You used custom SQL Filters: Basically you are not allowed to call `setParameter` inside `addFilterConstraint`; but setParameter must be called *before* the SQL query is actually executed. Currently, there's no standard Doctrine way to provide this; so you manually can receive the filter instance from `$entityManager->getFilters()->getEnabledFilters()` and call `setParameter()` then. Alternatively, you can influence the Doctrine caching by registering a global context object in `TYPO3.Flow.aop.globalObjects` and use it to provide additional identifiers for the caching; effectively seggregating the Doctrine cache some more.
This reduces the risk of collision on temporary filenames and other identifiers and data.
TASK: Use generateRandomString() instead of uniqid()
TASK: Ignore invalid cookie names instead of throwing an exception This prevents the exception that is thrown when a cookie has an invalid name. See the discussion here: https://discuss.neos.io/t/ignore-invalid-cookies-instead-of-throwing-an-exception/2234
BUGFIX: Annotate logoutAction with SkipCsrfProtection
BUGFIX: localeFormatType dateTime must use correct case
baschny
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Upgrade our fork from Flow 3.0.0 to 3.0.15.