-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Add 'sap-csp-policies' option to 'serve' command. #188
Conversation
Note: this PR is a counterpart to SAP/ui5-server#179. |
There's an open discussion about the name of the new option ( Until we come to a conclusion, I won't submit neither this PR nor SAP/ui5-server#179. |
Why not simply |
To me, The purpose of the new option is to enable a set of policies that SAP want's to use in-house (for UI5 DIST layer development). As we don't have means to activate configuration for such a limited scope, having a new option seemed to be the 2nd best approach to me. But the term 'defaults' somehow conflicts with the fact that there are already (other) defaults even without the new option. |
Since CLI flags have defaults themselves, I would refrain from including the string "default" in any flags name since it refers to another level of defaults. Which I find very confusing. From a user perspective the URL parameters are mostly unknown. Even when known, I would see them as a separate feature. I.e. a standard functionality of the server. This new feature of having a certain set of CSP headers being sent from the server for every request can imho be referred to by a simple "do CSP" toggle. However, since it seems to be an in-house feature, maybe I don't see a reason for separating this feature from the existing URL parameters from a wording perspective. They are both controlled in different ways anyways. Maybe read it like this:
|
That was exactly my point why I wasn't happy with the name of the option. To me it became obvious in the test code where I was tempted to name two tests "CSP defaults", one for each level of defaults. I doubt that 'from a user perspective, the URL parameters are mostly unknown'. At least internally, developers have been asked to use these parameters to test their code against CSPs. Our QUnit integration even supports a UI (drop down) for them. But it doesn't really matter as I'm totally fine with
for the CLI help. |
@svbender for final approval. Please use Squash and merge since the commit messages do not align with our convention. The squash commit should have a |
The duplication of the 'p' is accepted as 'csp' and 'policies' both help to understand the purpose of the option and '--sap-content-security-policies' would be a monster, not an option.
8d5f8fd
to
77a35fa
Compare
Thank you for your contribution! 🙌
To get it merged faster, kindly review the checklist below:
Pull Request Checklist