In Joomla 4 the CSP is configured in the components options not in the plugin.

So to me the link to the component is right.

For sure we can change the string when there is a better suggested.

Maybe we could add a message in the component pointing to the options when nothing is configured yet? What do you think?

in Joomla 4 the CSP is configured in the components options not in the plugin.

Sorry you are half wrong. :-)

well this is what is in the options of the component:

What this controls is this header:

content-security-policy-report-only: default-src 'self'; report-uri http://127.0.0.1:4444/index.php?option=com_csp&task=report.log&client=site

**If this option is DISABLED (in the component options) then the content-security-policy header (controlled by the plugin) is STILL SENT!

If this option is ENABLED, To CUSTOM and REPORT ONLY turned off - then it hijacks the output of content-security-policy header and overrides the plugin!!**

The actual policy (the content-security-policy header) is in the plugin

The link in the Manage list of links is text "Content Security Policy" and therefore I WOULD ASSUME that is where I go to Manage my Content Security Policy... not to view my reports or set my content-security-policy-report-only header

HOWEVER (edit)

it seems that you can set content-security-policy by disabling report-only in the component options which is overriding the http headers plugin...

so now we have two things trying to control one header? How confusing!

in Joomla 4 the CSP is configured in the components options not in the plugin.

Sorry you are half wrong. :-)

well this is what is in the options of the component:

What this controls is this header:

content-security-policy-report-only: default-src 'self'; report-uri http://127.0.0.1:4444/index.php?option=com_csp&task=report.log&client=site

Yes and there you can also switch to custom and auto mode and that is the suggested way to implement CSP in 4.x ;-)

**If this option is DISABLED (in the component options) then the content-security-policy header (controlled by the plugin) is STILL SENT!

If this option is ENABLED, To CUSTOM and REPORT ONLY turned off - then it hijacks the output of content-security-policy header and overrides the plugin!!**

The actual policy (the content-security-policy header) is in the plugin

Well the plugin can overwrite the setting from the compo ent that is right but the option to do so is called 'forced header' right?

The link in the Manage list of links is text "Content Security Policy" and therefore I WOULD ASSUME that is where I go to Manage my Content Security Policy... not to view my reports or set my content-security-policy-report-only header

As mention above the siggested way to configure the header is com_csp's options.

HOWEVER (edit)

it seems that you can set content-security-policy by disabling report-only in the component options which is overriding the http headers plugin...

so now we have two things trying to control one header? How confusing!

Well there are two places to allow to set an pre existing header that bypasses com_csp but the usual user should use com_csp to manage and configure the CSP header.

Cool... hope all that is documented in a way idiots like me can follow along and understand ;-)

Why is this closed? I only tried to explain the intended stuff. I'm happty to improve UX where needed and would be very happy for your input here.

Why is this closed?

Because I accept that I was wrong and did not understand how things were expected to work. It makes sense now that you have taken time to explain, thanks.

Cool... hope all that is documented in a way idiots like me can follow along and understand ;-)

It is (one of the few 4.x stuff that is documented) but i'm happy to improve the docs where need.

So please share your input and possible improvments.

I guess the bit - for me at least - that never made sense was hiding the "setting up of the CSP" in the component options... and having the main component be the reporting management...

And I wrongly assumed the HTTP Headers Plugin was the correct and definitive way to set all these fiddly custom headers, now I understand what the "Force" in "Force Http Headers" means... it means override any other previously set header value for this header.

Do you have a suggestion how we can impeove that?

The main reason for the current look and feel is that we used the structure that we have for other places too. For example the redirect component + plugin.

And I wrongly assumed the HTTP Headers Plugin was the correct and definitive way to set all these fiddly custom headers, now I understand what the "Force" in "Force Http Headers" means... it means override any other previously set header value for this header.

Well as it bases on my 3.x plugin there it was the place for all headers but to make sure all options are in the right spot we moved the csp options stuff to com_csp.

Well my feedback, take it or leave it, is that Joomla needs to do better "Empty State Design".

Wasn't there a UX Project? Im no expert. I just know what I like personally.

I.e: Rather than going to a page, and seeing a blank list of nothing, with a message "no matching results", Joomla could have a page that that introduces the feature, gives links to documentation, explains the basics and gives a call to action...

This would be much better. VERY easy to do and would add value to Joomla for those new to using Joomla (or a new feature) or idiots like me...

Comparing:

I personally like the Examples at DigitalOcean - but this is just an example to prove how much more helpful this is than just "no matching results",

Another bad empty state is the redirects component that mentioned - it starts like this:

A big red error message... "but I just installed Joomla 5 mins ago... why have I got big red errors?!?!?"......

I then have to do three clicks to open a modal change a setting, save and close a modal... just to enable something else somewhere else... and then Im STILL LEFT ON A PAGE that says the The Redirect System Plugin is disabled. until I reload the page manually.... Bad experience.

Agree can we re open this issue here and re label it as UX issue for the empty state? Adding more info and links to the docs etc makes sense to me.

Up to you. Design, lipstick and paint are my worse dev qualities... I don't have all the answers, but its a no brainer I think to improve the default empty state design for all components.... Its such a quick win for little effort.

Thanks will have a look into that and come back here.

Up to you. Design, lipstick and paint are my worse dev qualities... I don't have all the answers, but its a no brainer I think to improve the default empty state design for all components.... Its such a quick win for little effort.

For now i would start with com_csp but i think it can be adopted for other components later too. Lets see what i can come up with.

Lead and Im sure others will follow :-)

At the moment the out of the box experience (without demo data) is a bunch of left menu items that all lead to blank pages saying "no matching results" :-) haha

A single HTML page of helpful information, links, an illustration maybe, and a call to action is all that is needed... and a single if statement in PHP (if rows ==0 then load the empystate view :) ... zero b/c breaks ... big win ...

for inspiration here are two screenshots from an unnamed "service I might own" ;-) it can be as simple as these, but with helpful links and text specific for the component.

Thanks its noted

#33264