The `secret` parameter has been added in#51434 with a default value of`''` and a deprecation message that it is required / may not be empty.Which is fine and doesn't hurt backwards compatiblity.The later ticket#52469 changes the deprecation into an exception, as itis undesirable that no secret is used (in any scenario). This leads tothe unintended side effect that there is a BC breakage when a developermanually creates a `DefaultLoginRateLimiter` as it is now actuallyrequired to provide a (non empty) value due to the check and exception.Allowing the service / class to be used without providing the secretparameter, in a backwards compatible manner, but then still breaking thebackwards compatibility by throwing due to the default value isconfusing. So making the `secret` required makes more sense from adeveloper perspective as it is clear in that the parameter must beprovided.

…r (RobertMe)This PR was merged into the 6.4 branch.Discussion----------[Security] make secret required for DefaultLoginRateLimiter| Q             | A| ------------- | ---| Branch?       | 6.4| Bug fix?      | yes/no| New feature?  | no| Deprecations? | yes/no| Issues        || License       | MITThis tickets results from the discussion here:#52469 (review) and `@nicolas`-grekas requested a PR for it.The `secret` parameter has been added in#51434 with a default value of `''` and a deprecation message that it is required / may not be empty. Which is fine and doesn't hurt backwards compatibility.The later ticket#52469 changes the deprecation into an exception, as it is undesirable that no secret is used (in any scenario). This leads to the unintended side effect that there is a BC breakage when a developer manually creates a `DefaultLoginRateLimiter` as it is now actually required to provide a (non empty) value due to the check and exception.Allowing the service / class to be used without providing the secret parameter, in a backwards compatible manner, but then still breaking the backwards compatibility by throwing due to the default value is confusing. So making the `secret` required makes more sense from a developer perspective as it is clear in that the parameter must be provided.Commits-------ecbf0e9 [Security] make secret required for DefaultLoginRateLimiter

…kernel.secret% with the rate-limiter (nicolas-grekas)This PR was merged into the 7.1 branch.Discussion----------[SecurityBundle] Use %container.build_hash% instead of %kernel.secret% with the rate-limiter| Q             | A| ------------- | ---| Branch?       | 7.2| Bug fix?      | no| New feature?  | no| Deprecations? | no| Issues        | -| License       | MITIn#51434, we decided to hash the username and the client IP in order to anonymize logs.I propose to use %container.build_hash% instead of %kernel.secret% in order to use %kernel.secret% one less time.%container.build_hash% looks good enough to me, and it doesn't need any external configuration.Related to the discussion happening insymfony/recipes#1314Commits-------574f573 [SecurityBundle] Use %container.build_hash% instead of %kernel.secret% with the rate-limiter