symfony: [Security] Cannot use env in RememberMe config

Symfony version(s) affected: 3.4.39

Description
This is working until today’s 3.4.39 update. using env in security.yaml causes this error.

Invalid type for path "security.firewalls.main.remember_me.lifetime". Expected int, but got string.

How to reproduce
inside of security.yaml

lifetime: '%env(int:REMEMBER_ME_COOKIE_LIFETIME)%'

Possible Solution
Remove these lines https://github.com/symfony/symfony/pull/35910/files#diff-63961cbd5c56cdeb2e94e6024d58327fR148-R149

Additional context

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 15 (14 by maintainers)

Commits related to this issue

bug #36483 [SecurityBundle] fix accepting env vars in remember-me configurations (zek) This PR was merged into the 3.4 branch. Discussion ---------- [SecurityBundle] fix accepting env vars in remem... — committed to symfony/symfony by nicolas-grekas 4 years ago

Most upvoted comments

I can confirm that I no longer have this error when I update the reproducer to Symfony 4.4 (thanks for providing a reproducer, that makes it very easy to confirm/test!)

wouterj on Apr 3, 2020

@zek as you were the one reporting and discovering the lines that broke this, are you maybe up for a PR to revert the change on the 3.4 branch? That would give you all credits you deserve 😃

It means that any node, excepted for ScalarNode, has potentially an issue with env variables which will be always read as strings by the loaders, an array could be %env(json:file:…)% etc. Sounds very complex to try to handle this from any component, and probably too much to allow strings on every nodes…

Yes, this is also what I was thinking about. I think it might be possible to “solve” it a little bit if Config would recognize that it is an env string and discover the env processor. There are env processors for each type. E.g. if something is %env(int:...)%, we can be sure it’ll be an integer when it is processed by DI.

This would make the Config component aware of the fullstack framework though. I’m not sure how to fix that, but this could be a way of solving it for all config nodes.

wouterj on Apr 3, 2020

@zek as you were the one reporting and discovering the lines that broke this, are you maybe up for a PR to revert the change on the 3.4 branch? That would give you all credits you deserve 😃

Ok. I’ll send a PR today. Thank you all @wouterj @HeahDude @nicolas-grekas 👍

zek on Apr 3, 2020

4.4 is already able to know about these, but not 3.4 indeed.

nicolas-grekas on Apr 3, 2020