[#20847] - [4.0] [CSP] Initial Integration of com_csp & plg_system_httpheaders
- Fixed in Code Base
- 19 Jul 2018
- Medium
- Build: 4.0-dev
- # 20847
- Diff
- zero-24:plugin_comcsp
User tests: Successful: Unsuccessful:
Summary of Changes
This PR is the next step for the implementation of a core csp handling.
This now does the integration of com_csp & plg_system_httpheaders.
The general goal of the PR is that everything that is published in com_csp also gets added to the automatic csp rule including some general things like nonce's
Testing Instructions
Testing the detecting mode
- Go to the Plugin
- Got to the CSP tab in the plugin settings
- Set the
modetodetecting - Visit the frontend & navigate in the backend
- check the com_csp backend
- notice the collected reports also with client info
Testing the custom mode
- Go to the Plugin
- Got to the CSP tab in the plugin settings
- Set the
modetocustom - Notice that now the additional fields open
- configure (i would suggest) a report only rule
- confirm using the browser's networktab that the header is set
Testing the auto mode #1
- make sure NO report is published in com_csp
- Go to the Plugin
- Got to the CSP tab in the plugin settings
- Set the
modetoauto - confirm using the browser's networktab that NO CSP header is set
Testing the auto mode #2
- Go to com_csp
- publish all collected rules
- Go to the Plugin
- Got to the CSP tab in the plugin settings
- Set the
modetoauto - confirm using the browser's networktab that the CSP header IS set
Expected result
All four test cases works
Actual result
No integration between com_csp & plg_system_httpheaders
Documentation Changes Required
This is a new feature so docu is needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | SQL Administration com_admin Postgresql Language & Strings Front End Installation Libraries Plugins |
| Labels |
Added:
?
?
?
|
||
| Labels |
Added:
?
|
||
Hi,
thanks for the feedback. Yes that sounds like a plan. But before I do the development I would like to get @wilsonge check this and tell us a bit more details about the planed design rework and how such a configuration would fit into the new design.
The design rework is going to give us a separated dashboard and set of components. There is now a more conscious separation between administration components and day to day content components with the split of dashboards. Not all administrators are actually going to be totally aware of this extension.
As I would like to not redo all of this two times. Or worse do something that is completely against that design rework.
Given that this is for now the technical PR with all the features working I would like to get this in even with this know UI/UX improvements and than when we have the details for the design do a separate PR to implement the new design so we have step by step improvements. Would you agree with that?
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-07-19 23:20:10 |
| Closed_By | ⇒ | wilsonge |
I can see Brian's point of view about having a singular place for editing everything - but I'm not totally sure whether it's a good idea or not to be honest. Can I hear thoughts from others?
OK I've merged this so we have the integration. We can now see the new design. The aim is that we are going to remove the CSP from the main components menu and leave it only in the system dashboard (along with the various other components that live there)
Ok please ping me on Glip on the details so i can do my bit and help implementing it.
@zero-24 With this component your original idea for providing http headers etc has changed (for the better). However from a UI/UX it is unusual in the joomlasphere in that we have a component that does one part of the job and a plugin that does the rest.
I understand why it is a plugin that does the actual headers but there isnt a good reason (I think) for the creation of the rules to be done in the plugin, especially now we have a component that is detecting some of the rules that you require.
Would it not make more sense to strip out all the configuration from the plugin, other than being enabled/disabled, and putting it all into the component.
Then there would be two views in the component
com_csp?task=report
com_csp?task=setup
and possibly
com_csp?task=options
It will make more sense to view the reports in the component and then apply the recommendations to the headers if we can see the final config in the same component without having to close the component and go to the plugin. It will also be quicker and easier to see what happens all from the same place.
If you look at com_finder as an example then you see that its all done in the component and not the plugins