This PR was squashed before being merged into the 3.4 branch (closes#35305).
Discussion
----------
[HttpKernel] Fix stale-if-error behavior, add tests
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #24248
| License | MIT
| Doc PR |
This PR adds the first tests for `stale-if-error` logic in `HttpCache`.
It also fixes an observation from #24248: For responses that have been cached as `public` with an `ETag` but without a lifetime, in case of an error the stale response will be served forever (= as long as the error persists), even beyond the configured `stale-if-error` grace period.
Furthermore, it tries to improve compliance with RFC 7234: Stale responses must not be sent (under no condition) if one of
* `no-cache`
* `must-revalidate`
* `proxy-revalidate` or
* `s-maxage` (sic) is present.
This can be found in the corresponding chapters of Section 5.2.2 for these directives, but is also summarized in [Section 4.2.4](https://tools.ietf.org/html/rfc7234#section-4.2.4) as
> A cache MUST NOT generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; see Section 5.2.2).
Because disabling of `stale-if-error` for `s-maxage` responses probably has a big impact on the usefulness of that feature in practice, it has to be enabled explicitly with a new config setting `strict_smaxage` (defaulting to `false`).
Commits
-------
ad5f427bed [HttpKernel] Fix stale-if-error behavior, add tests
This PR was submitted for the 4.4 branch but it was merged into the 3.4 branch instead.
Discussion
----------
[Security] Improved error message when no supported user provider is found
| Q | A
| ------------- | ---
| Branch? | 4.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35435
| License | MIT
| Doc PR | -
Commits
-------
6b2db6dc30 Improved error message when no supported user provider is found
This PR was merged into the 3.4 branch.
Discussion
----------
Fix testing with mongodb
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Commits
-------
28cd964ac9 Fix testing with mongodb
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Use supportsClass in addition to UnsupportedUserException
| Q | A
| ------------- | ---
| Branch? | 3.4+
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35045
| License | MIT
| Doc PR | ~
This PR fixes the issue where user providers rely on just the UnsupportedUserException from `refreshUser()`, causing a flow where users are wrongfully re-authenticated.
There's one issue where `refreshUser()` can do far more sophisticated checks on the user class, which it will never reach if the class is not supported. As far as I know it was never intended to support instances that are rejected by `supportsClass()`, though people could've implemented this (by accident). So the question is more if we should add a BC layer for this; for example:
```php
try {
$refreshedUser = $provider->refreshUser($user);
$newToken = clone $token;
$newToken->setUser($refreshedUser);
if (!$provider->supportsClass($userClass)) {
if ($this->shouldCheckSupportsClass) {
continue;
}
// have to think of a proper deprecation here for 6.0
@trigger_error('Provider %s does not support user class %s via supportsClass() while it does support it via refreshUser .. please set option X and fix %s::supportsUser() ', E_USER_DEPRECATED);
}
```
This would prevent behavior from breaking but also means we can't fix this on anything less than 5.1.
Commits
-------
d3942cbe17 Use supportsClass where possible
This PR was merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge][SymfonyTestsListenerTrait] Remove some unneeded code
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Risky errors when there are no assertions are added before the test end listeners are called (ie, before the code in endTest is executed) so forcing beStrictAboutTestsThatDoNotTestAnything to false when there is a expectedDeprecation annotation is enough.
If the goal is to reset the value to the original value, then I think we should not do it since we basically "lie" to the next listeners. Let's assume that when a test expect a deprecation, it can have 0 assertions. Also this flag is not used anymore by PHPUnit after we reset it.
Ref https://github.com/symfony/symfony/pull/21786 btw
Commits
-------
fb48bbc05b [PhpUnitBridge][SymfonyTestsListenerTrait] Remove some unneeded code
This PR was merged into the 3.4 branch.
Discussion
----------
[Filesystem] chown and chgrp should also accept int as owner and group (3.4)
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Reference: https://github.com/symfony/symfony/pull/35356#issuecomment-575526299
Commits
-------
6b811e6b4c chown and chgrp should also accept int as owner and group
This PR was merged into the 3.4 branch.
Discussion
----------
[Validator] Fix plurals for sr_Latn validation messages
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35276
| License | MIT
validators.sr_Latn.xlf (Serbian, written with latin script) has wrong plurals for all validation message translations that require them (only two where there should be three). This commit fixes that by adding the missing third plural-translation.
Commits
-------
207cdafd54 [Validator] Fix plurals for sr_Latn (Serbian language written in latin script) validation messages
This PR was merged into the 3.4 branch.
Discussion
----------
[Security] Fix RememberMe with null password
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | yes
| Tickets | NA
| License | MIT
| Doc PR | NA
From `UserInterface` the method getPassword may return null, while generateCookieHash requires a string.
This PR changes the signature of the methods to allows null password
Similar to #35335 for branch 3.4
Commits
-------
820eb357c8 Fix RememberMe with null password
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Fix that no-cache MUST revalidate with the origin
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
From [RFC 7234 Section 5.2.2](https://tools.ietf.org/html/rfc7234#section-5.2.2)
> The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.
This is unconditional – the response must be revalidated right away.
(`must-revalidate`, to the contrary, requires revalidation only once the response has become stale.)
Commits
-------
c8bdcb3408 Fix that no-cache requires positive validation with the origin, even for fresh responses
This PR was merged into the 3.4 branch.
Discussion
----------
Avoid `stale-if-error` in FrameworkBundle's HttpCache if kernel.debug = true
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#24248 (maybe?)
| License | MIT
| Doc PR |
When working with the `HttpCache` in development, error messages may not become visible if a `public` response has been successfully generated for the same URL before.
This is because the `HttpCache` from the `HttpKernel` component by default sets `stale_if_error` to 60 seconds.
At least when using the `HttpCache` subclass from the `FrameworkBundle`, we know about the `kernel.debug` setting and its intention to support local development. In that case, we could set the *default* `stale-if-error` value to 0.
Commits
-------
3a23ec89c3 Avoid stale-if-error if kernel.debug = true, because it hides errors
This PR was merged into the 3.4 branch.
Discussion
----------
[DI] deferred exceptions in ResolveParameterPlaceHoldersPass
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#30428
| License | MIT
| Doc PR | n/a
fixes case #30428
implemented as in AutowiringPass
Commits
-------
b3a2173c8e [DI] deferred exceptions in ResolveParameterPlaceHoldersPass
This PR was merged into the 3.4 branch.
Discussion
----------
[Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no
| Deprecations? | no
| Tickets | https://github.com/symfony/symfony/issues/35035
| License | MIT
| Doc PR | -
The test uses heredoc for the expected part. Expected line returns are `"\n"` because that's how they are written in the source code file.
However, on Windows, the console outputs `"\r\n"` (`PHP_EOL`) for new lines.
`"qqq:\r\n"` does not contain `"qqq:\n"`.
I'm still wondering why this test is not *always* failing...
Commits
-------
474f3bef08 [Console] Fix SymfonyQuestionHelper tests sometimes failing on AppVeyor
This PR was merged into the 3.4 branch.
Discussion
----------
Added more tests for WebProfilerBundle
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | no
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | - <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | -
Thanks to @jpauli Code Coverage info about Symfony (http://cov.jpauli.tech/) I found that WebProfiler's controllers are pretty badly covered:
![image](https://user-images.githubusercontent.com/73419/57919817-ec390500-7899-11e9-81b7-763a0b35d0ec.png)
This PR focuses on testing the main controller class:
![image](https://user-images.githubusercontent.com/73419/57919877-04108900-789a-11e9-8a93-3466b672d873.png)
Commits
-------
2f7a820edd Added more tests for WebProfilerBundle
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
file_get_contents 3rd parameter (context) expects resource or NULL to ignore them
Commits
-------
a28a42187c [PHPUnitBridge] file_get_contents() expects parameter 3 to be resource
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets |
| License | MIT
| Doc PR |
Some commands executed by the `simple-phpunit` script are not checked for success. For example [here](https://travis-ci.org/twigphp/Twig/jobs/634110681), Composer fails with the message
```
[InvalidArgumentException]
Could not find package phpunit/phpunit with version 7.5.* in a version inst
allable using your PHP version 7.0.25.
```
Yet, the `simple-phpunit` script happily continues, going over failing `chdir()`, `file_get_contents()` and `include()` calls and eventually returns a successful `0` exit code. So CI tests look OK when in fact PHPUnit was not even downloaded.
Commits
-------
576e18561f [PHPUnit-Bridge] Fail-fast in simple-phpunit if one of the passthru() commands fails
This PR was merged into the 3.4 branch.
Discussion
----------
[Dotenv] Fixed infinite loop with missing quote followed by quoted value
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34642
| License | MIT
| Doc PR |
If there's a quote missing to end a value and in the next line there's again a quoted value Dotenv will run into an infinite loop. An .env file with the following content will result in this error:
```
FOO="foo
BAR="bar"
```
See #34642 for more details.
Commits
-------
eb69e135b2 [Dotenv] Fixed infinite loop with missing quote followed by quoted value
This PR was merged into the 3.4 branch.
Discussion
----------
[Security\Http] Prevent canceled remember-me cookie from being accepted
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#35198
| License | MIT
| Doc PR | -
`RememberMeServices::autoLogin()` only checks that the cookie exists in `$request->cookies` while `loginFail()` only alter `$request->attributes` (which allows child implementations to read the canceled cookie for e.g. removing a persistent one).
This makes `autoLogin()` checks for `request->attributes` first, which fixes the linked issue.
Failure expected on deps=high build.
Commits
-------
9b711b87fe [Security] Prevent canceled remember-me cookie from being accepted
This PR was merged into the 3.4 branch.
Discussion
----------
[Debug] fix ClassNotFoundFatalErrorHandler
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
Spotted by the CI on 4.4, see https://github.com/symfony/symfony/pull/35266 for details.
Replaces https://github.com/symfony/symfony/pull/35255 /cc @mpdude
Commits
-------
0c320febe1 [Debug] fix ClassNotFoundFatalErrorHandler
If there's a quote missing to end a value and in the next line there's again a quoted value Dotenv will run into an infinite loop. An .env file with the following content will result in this error:
```
FOO="foo
BAR="bar"
```
See #34642 for more details.
This PR was squashed before being merged into the 3.4 branch (closes#35193).
Discussion
----------
[TwigBridge] button_widget now has its title attr translated even if its label = null or false
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | Fix#34330
| License | MIT
| Doc PR | TODO
Duplicate of #34436 but changed to bugfix and applied to 3.4. Buttons with null or false 'label' options will now have their 'title' attribute translated against the current translation domain.
Commits
-------
2a5d9cb75a [TwigBridge] button_widget now has its title attr translated even if its label = null or false
This PR was squashed before being merged into the 3.4 branch.
Discussion
----------
[PhpUnitBridge] When using phpenv + phpenv-composer plugin, composer executable is wrapped into a bash script
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no
| Deprecations? | no
| Tickets | #34796
| License | MIT
| Doc PR | -
Locally using [phpenv](https://github.com/phpenv/phpenv) together [phpenv-composer](https://github.com/ngyuki/phpenv-composer) with for managing php versions and composer installations.
`which composer` is detecting wrapper instead of binary.
Before appending PHP executable to composer path need to validate that detected composer is not a wrapper otherwise PHP will simply return the content of a wrapper
Commits
-------
25c805ed56 [PhpUnitBridge] When using phpenv + phpenv-composer plugin, composer executable is wrapped into a bash script