J4 Issue ?
avatar zero-24
zero-24
27 Jul 2019

Steps to reproduce the issue

I'm opening this issue here as response to the following questions raised here by @brianteeman so we can discuss here how to deal with them:

Its all very confusing. Writing headers to the file actually makes it more confusing (for me). Is it even compatible with setting headers for site or admin or both?

There is no way to delete all the headers from the htaccess. So once they have been written to the htaccess if you then disable that option no changes made to the settings will be applied

We also now have the situation that we have rules set in the htaccess, rules set in the plugin, and rules set in the component and no way to see in one place all the rules that are being applied. This will make debugging a faulty rule very hard.

avatar zero-24 zero-24 - open - 27 Jul 2019
avatar joomla-cms-bot joomla-cms-bot - change - 27 Jul 2019
Labels Added: ?
avatar joomla-cms-bot joomla-cms-bot - labeled - 27 Jul 2019
avatar franz-wohlkoenig franz-wohlkoenig - change - 27 Jul 2019
Labels Added: J4 Issue
avatar franz-wohlkoenig franz-wohlkoenig - labeled - 27 Jul 2019
avatar zero-24
zero-24 - comment - 27 Jul 2019

Its all very confusing. Writing headers to the file actually makes it more confusing (for me). Is it even compatible with setting headers for site or admin or both?

Here is a PR to make sure only the global headers are written.: #25717 Good spot 👍

avatar zero-24
zero-24 - comment - 27 Jul 2019

We also now have the situation that we have rules set in the htaccess, rules set in the plugin, and rules set in the component and no way to see in one place all the rules that are being applied. This will make debugging a faulty rule very hard.

Well usually you should set the CSP in the CSP Component an all other headers are set in the plugin. Well you can overwrite them from the plugin too but then you should know what you are doing. Do you have a suggestion to deal with that? I personally don't see an issue how it is done now as there is a clear split between plugin and component; CSP should be set in the component and all others in the plugin.

avatar zero-24
zero-24 - comment - 27 Jul 2019

There is no way to delete all the headers from the htaccess. So once they have been written to the htaccess if you then disable that option no changes made to the settings will be applied

Well what would you suggestion about this be? Here is a issue about this question too. The hard part is with web.config file as you can't detect whether the header was set by the plugin or the admin or other tools.

avatar mbabker
mbabker - comment - 27 Jul 2019

Stick to handling it in PHP only.

avatar franz-wohlkoenig franz-wohlkoenig - change - 27 Jul 2019
Status New Discussion
avatar brianteeman
brianteeman - comment - 27 Jul 2019

If the htaccess file is not writeable then you get a popup which should contain the text to copy etc. BUT its not scrollable so its not possible to copy it all

image

avatar zero-24
zero-24 - comment - 27 Jul 2019

Stick to handling it in PHP only.

What do you mean by that, i'm confused?

avatar zero-24
zero-24 - comment - 27 Jul 2019

its not scrollable so its not possible to copy it all

A Patch can be found here: #25719 Thanks for the report 👍

avatar brianteeman
brianteeman - comment - 27 Jul 2019

The htaccess changes do not make it clear that these are only the "global" settings and that there may be others set in the plugin or in com_csp which may replace the ones in the htaccess

MANAGED BY PLG_SYSTEM_HTTPHEADERS DO NOT MANUALLY EDIT! - START


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25716.
avatar richard67
richard67 - comment - 27 Jul 2019

I agree with @mbabker, handle it in PHP only.

avatar zero-24
zero-24 - comment - 28 Jul 2019

Well what do you mean by handle it in PHP only.

The disadvantage of not using .htaccess is that the rules only being applied when Joomla runs, htaccess enforces that on the server level.

avatar richard67
richard67 - comment - 28 Jul 2019

I like to edit my .htaccess myself, I don't need a plugin doing that. I don't want to imagine what happens with all those users having no ssh access with their hosting package and we have a bug which ruins their .htaccess file so they get a server error 500. I can fix that per ssh, but they have to call their provider.

avatar brianteeman
brianteeman - comment - 28 Jul 2019

or use ftp, or use their hosts control panel

avatar richard67
richard67 - comment - 28 Jul 2019

yes, if they know about it ;-)

avatar mbabker
mbabker - comment - 28 Jul 2019

How many of the headers are you actually concerned with if a request goes to a non-Joomla resource on the server? Can Joomla reliably manage writing config files for all supported web servers without losing user data in those files? Core has avoided having a web server config in its interface and I would not monkey patch partial support in a plugin (if you want to do it, which I don’t think it is a web application’s responsibility to give this to users, it should be a proper API that is hookable throughout the system).

avatar brianteeman
brianteeman - comment - 28 Jul 2019

@richard67 makes a very good point. Its the same reason why in the training videos for admintools I stress repeatedly that the user should have access to the htaccess file BEFORE touching the tools that change the file.

My main concern however is as in the original post. There is no single place to find out what the current settings are and they remain active after the write to headers has been disabled because there is no delete

avatar zero-24
zero-24 - comment - 29 Jul 2019

How many of the headers are you actually concerned with if a request goes to a non-Joomla resource on the server?

The idea came up for the content-type-options and hsts and that it is actually the server who is enforcing the rules but this header is now enforced by the default htaccess anyway.

But I agree I patch it out of the plugin in the coming days.

avatar zero-24
zero-24 - comment - 31 Jul 2019

As suggested here hear is the PR to remove the support: #25754

avatar franz-wohlkoenig franz-wohlkoenig - close - 31 Jul 2019
avatar franz-wohlkoenig
franz-wohlkoenig - comment - 31 Jul 2019

Closed as having Pull Request #25754

avatar franz-wohlkoenig franz-wohlkoenig - change - 31 Jul 2019
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2019-07-31 18:06:01
Closed_By franz-wohlkoenig

Add a Comment

Login with GitHub to post a comment