Inject 'strict-dynamic' into CSPRO
#60
Conversation
aidantwoods
force-pushed
the
fix/inject-strict-dynamic-on-cspro
branch
from
7f4a09f
to
866010d
Compare
| "<b>Strict-Mode</b> is enabled, but | ||
| <b>'strict-dynamic'</b> could not be added to <b>" | ||
| . $Header->getFriendlyName() | ||
| . '</b> because no hash or nonce was used.', | ||
| E_USER_WARNING |
There was a problem hiding this comment.
please throw an exception instead, it's ugly codestyle imo.
There was a problem hiding this comment.
Might be something to think about for 3.0, would be a BC break to start doing it now though.
Things to think about with errors v.s. exceptions:
- Exceptions will generally cause headers not to reach the adapter, and so won't be sent. i.e.
- Is no CSP better than suboptimal CSP? (bearing in mind loss of reporting header which might be stricter too).
- Is not sending a suboptimal CSP better than HSTS, Referrer-Policy, cookie upgrades, ...?
- It we throw exceptions, they should be genuine problems. That means not throwing an exception for advice: we cannot use exceptions to tell the dev they they should use something (learning opportunity). Learning opportunities would have to be disposed of if we converted all errors as used currently to exceptions.
There was a problem hiding this comment.
Feel free to open an issue, this would be a methodology change for the library so probably isn't worth debating for this one specific case 😉
I like exceptions, I just don't think they're appropriate for every case in which errors are used in the library currently (probably a separate issue is best to discuss the decoupling).
|
I'm considering whether these newly added config options belong really in |
WIP at present.
Min requirements before merge:
Closes #56