Make it possible to enable CSP in debug mode

[kraftner]

I'd like to have this plugin enabled during development to not only spot possible breakage through CSP issues in production. But currently setting 'debug' => true always disables it.

I have two ideas how to solve this:

• Instead of directly checking for the value of debug it could be used to set the default for enable. But this would change the behavior for people already using the plugin. :cry:
• Make the debug option configurable just like enabled as bnomei.securityheaders.debug so it can have a different value than the global debug option.

As a temporary workaround I use this code/configuration for my dev setup:

return [
    'debug' => true,
    /**
     * Weird workaround to enable the plugin even if debug is true
     * Works like this:
     * 1. Set enabled to false to skip the plugin instantiating the singleton
     * 2. Instantiate it on our own but forcing debug to false and enabled to true
     * 3. Profit
     */
    'bnomei.securityheaders.enabled' => false,
    'hooks' => [
        'route:before' => function (): void {
            \Bnomei\SecurityHeaders::singleton([
                'debug' => false,
                'enabled' => true,
            ])->sendHeaders();
        },
    ],
];

[bnomei]

@kraftner thanks for the feeback. in most of my plugins i follow a rule like this "if the plugin does something that is not needed 100% then disable it in debug mode – debug is not production" (like caches or other optimizations). this is based on my own preference to have debug OFF in local development until i encounter a crash, then turning it ON until i fix the issue. so for me having debug enabled is a rare case. but i understand that this might not be how others see it.

so apart from how to setup local dev config files why exactly do you need debug and the csp enabled at the same time?

[kraftner]

I can totally understand that having debug enabled is a matter of taste, but since tastes obviously differ I was just hoping to make this plugin flexible enough to have it easily cater to all. :)

Personally I have two main reasons:

• While developing it is comfortable to have whoops tell me what exactly went wrong, including telling me about warnings.
• I can have things (like e.g. switching API access to dummy endpoints or more detailed logging) all together tied to the debug state

[bnomei]

i added a new value 'force'.

return [
    'debug' => true,
    'bnomei.securityheaders.enabled' => 'force',
    // other options...
];