Conversation
Page: https://symfony.com/doc/6.4/security.html#the-firewall Reasons: * The inner parentheses `_(profiler|wdt)` are overly complicated * AssetMapper recommends to have all assets under `/asset/`: https://symfony.com/doc/6.4/frontend/asset_mapper.html
security.rst Outdated
| @@ -497,7 +497,7 @@ will be able to authenticate (e.g. login form, API token, etc). | |||
| # the order in which firewalls are defined is very important, as the | |||
| # request will be handled by the first firewall whose pattern matches | |||
| dev: | |||
| pattern: ^/(_(profiler|wdt)|css|images|js)/ | |||
| pattern: ^/(_profiler|_wdt|assets)/ | |||
There was a problem hiding this comment.
IIRC we have it this way to be in line with the recipe: https://.com/symfony/recipes/blob/main/symfony/security-bundle/6.4/config/packages/security.yaml#L10
There was a problem hiding this comment.
Well, then let's change it there too :-) symfony/recipes#1395
The security config is not merged between environments. So you would have to repeat everything for the |
Is this true for all parts of the config? if ('test' === $containerConfigurator->env()) {
// ...
} |
Not to all parts, and some parts behave differently. We don't merge configuration from About this PR, I think it makes sense, but let's wait for the recipe to be accepted as the documentation have to be in sync with the generated recipes. |
| @@ -497,7 +497,7 @@ will be able to authenticate (e.g. login form, API token, etc). | |||
| # the order in which firewalls are defined is very important, as the | |||
| # request will be handled by the first firewall whose pattern matches | |||
| dev: | |||
| pattern: ^/(_(profiler|wdt)|css|images|js)/ | |||
| pattern: ^/_profiler|_wdt|assets|build/ # `assets` is for AssetMapper; `build` is for Webpack Encore | |||
There was a problem hiding this comment.
| pattern: ^/_profiler|_wdt|assets|build/ # `assets` is for AssetMapper; `build` is for Webpack Encore | |
| pattern: ^/(_profiler|_wdt|assets|build)/ # `assets` is for AssetMapper; `build` is for Webpack Encore |
| @@ -529,8 +529,8 @@ will be able to authenticate (e.g. login form, API token, etc). | |||
| <!-- the order in which firewalls are defined is very important, as the | |||
| request will be handled by the first firewall whose pattern matches --> | |||
| <firewall name="dev" | |||
| pattern="^/(_(profiler|wdt)|css|images|js)/" | |||
| security="false"/> | |||
| pattern="^/_profiler|_wdt|assets|build/" | |||
There was a problem hiding this comment.
| pattern="^/_profiler|_wdt|assets|build/" | |
| pattern="^/(_profiler|_wdt|assets|build)/" |
Uh oh!
There was an error while loading. Please reload this page.
What is the problem this PR solves ? I mean, is there any real life problem with AssetMapper or Webpack ? (even if for the first I seriously doubt it, as the dev server priority is greater than security listeners in dev and ... it does not work in prod) |
Co-authored-by: Christian Flothmann <[email protected]>
Page: https://symfony.com/doc/6.4/security.html#the-firewall
Reasons:
_(profiler|wdt)are overly complicated/assets/: https://symfony.com/doc/6.4/frontend/asset_mapper.htmlQuestion:
Shouldn't this
devfirewall be loaded in DEV environment only? (i.e. under something likewhen@dev)