Ability to prevent autossl editing .htaccess files

That's definitely a perspective we hadn't considered, and makes a whole lot of sense. Practically, it should only trigger these adjustments once, but I completely understand how that's still an incredible inconvenience. I'll definitely be bringing this up internally. Thank you for reaching out!

It definitely only should do these changes once, during initial setup. Currently it seems to be doing these RewriteCond additions periodically (since updating to v60).

You're correct, in this instance, that compatibility with nginx wasn't considered as far as I know. Especially as a proxy. Once we add Nginx support to EA4, support will definitely be considered. This isn't a great place to discuss integration like that, but a forum thread would likely lead to a lot of good feedback.

The pre-virtualhost redirect text is in an above comment, but definitely test it on your server to make sure everything still works as expected.

Thank you for your answer. Since I wrote this comment I tried to write my own rules for nginx. So this is what I have now and it seems to be working just fine for every nginx vhost. So this combined with the fact that cPanel writes its own rules at the htaccess files only when needed it fixes my own problem. I thought to write it here just in case somebody else may need it. I agree that further discussion about nginx is not needed at this thread and of course I'm looking forward to the full integration of nginx with EA4.

So if you make any redirect from http to https at nginx as a reverse proxy to apache you might want to place something like this at the beginning of your server block.

1. location ~*.*\.(txt|cpaneldcv)$ {root /home/yourusername/public_html;try_files $uri @backend;}location / {return 301 https://yourdomain$request_uri;}
2. #you have to do this in two blocks
3. #yourodomain.com and http://www.yourdomain.com and place them isnide the server block

This is my own way and it is not guaranteed that it may work

Can you share such a patch? Because while this request become truth, a lot of sites all around are being messed up with this issue.

It's a allegedly a feature, but since it is badly implemented, it became a bug for a lot of us.

Hello Benny. The problem here is that these edits not always break sites. The collateral problem is that lots of customers don't want/like to see their files being edited without permission. They take it badly, like messing with their privacy. They argue that today "you" edited our .htaccess, who will assure no other files are being edited?

Ours are not edits causing sites to break, but edits causing customers to worry, loose trust with us and to contact us and complain.

For the moment all we can do is say sorry this is cPanels choice and we can't do anything about it. They answer, if cPanel does things like this why don't you use a different control panel.

We don't like this situation at all.

My defining of this as very much a BUG is because the system is making changes to files which wouldn't/shouldn't normally be changed in this way, AND there's no current way to prevent these changes being made (short of disabling autossl), so to my mind that's definitely a BUG.

There's also a huge assumption being made here by the system - that *any* RewriteRule is (potentially) going to prevent the URL to the file autossl needs being read. But that isn't always the case...

For example, a typical RewriteRule scenario for a CMS/framework front-controller might look like:

1. RewriteCond %{REQUEST_FILENAME} !-f
2. RewriteCond %{REQUEST_FILENAME} !-d
3. RewriteRule ^.*$ index.php [L,QSA]

..the RewriteCond's here specifically exclude requests to *real files* or directories, so the rule isn't going to cause a problem. BUT, currently the system will still stuff another redundant RewriteCond in here, and continue to repeatedly do so (if it's manually removed, e.g. by 'git checkout .htaccess).

In short: there absolutely *must* be an option within the autossl settings to prevent .htaccess files being altered in this way .. both globally, and per-site, preferably.

I definitely understand the frustration. From our side, we have always classified .htaccess files as part of Apache configuration files, which means we can/should manage them. This conversation has definitely helped us to understand how customers view the .htaccess files: as part of their website content, rather than as a server configuration file.

As always, if there's any change for us, I will definitely be back to let everyone know.

You're right Benny, customers (both cPanel's direct customers, plus their respective end-customers) consider .htaccess files to be part of their website; their project. That's because almost anything they'd have in place to run a website these days, be that Zend Framework, Laravel, Symfony, WordPress, etc (the list goes on) .. ALL include a boilerplate .htaccess file out-of-the-box, normally in the web root directory itself. That's why it's always going to be an issue if something external to that (i.e. cPanel) is changing that file..

We don't mind cPanel adding code to the top or to the bottom of .htacces files but do mind when lines are added amungst customer edits.

If you choose the touch file solution couldn't you just add an if statement around the code that runs the final autossl search/replace in htaccess files :

1. if ( ! file_exists(/usr/local/cpanel/deny.autossl.htacces.modifcations))
2. {
3. // Your code here
4. }

This mustn't be that long or complicated to do ?

Benny, let me add a suggestion for a quick fix in the meantime: just add a comment after the modified .htaccess entries so customers know it's been automatically modified. "# added by cPanel AutoSSL" or something to that effect.

This is certainly better than nothing. Is this a long term idea or something to resolve the problem for the time being? Medium-long term I would much prefer for cPanel to provide a supported solution, e.g. the DNS verification method or opting for global includes on compatible systems.

Yes that sounds fine. We would also need a way of applying this via SSH, either API or just editing a file.

Sorry if I don't understand, but can you ellaborate and share why exactly cPanel would be unable to provide support in case this feature is added and enabled?

As I understood after lots of replies, these edits are intended to fix a bug when the server is running Apache 2.2. Based on that, we only want AutoSSL to not mess with .htaccess files if the server is running on Apache 2.4. So... Is there any real reason why the edits are absolutelly required under Apache 2.4?

What about adding the no autossl support remark as a quick fix and then detect if the web server is Apache 2.4+ then add the rewrite rules outside the .htaccess.

I guess cPanel will want to do alot of testing before adding the global rewite rules on Apache 2.4+ and that this could take quite a bit of time so allowing us to disable it without support until this happens would be nice.

To answer some of your questions:

• This would likely be a long-term resolution, with allowing the editing of .htaccess files being the primary goal.
• At this point I and nearly 100% positive that all of our new features come with API calls, so it shouldn't be a problem to make that happen here.
• The edits are to ensure functionality with Apache 2.2, not to fix a bug in Apache 2.2. Apache 2.2 functions slightly differently than 2.4, which is why the edits were necessary.

I'll bring up the idea of adjusting behavior based on Apache version again, to see if this is worth investigating as well. It sounds like, overall, this is an acceptable middle ground. If that continues to be true I'll let the PO know and he can take all of this to the feature team to see what they think collectively. If you have additional feedback feel free to add it here. I'm about to step away for the weekend, so you likely won't hear from me until next week. :)

That's exactly the point Benny. If the edits are to ensure functionality with Apache 2.2, why in the world are the .htaccess being edited under Apache 2.4?

I mean... if the server is running Apache 2.4, downgrading to 2.2 is largely unlikely. So, edits are not needed at all.

In the other hand, feel free to edit the files if the server is running on Apache 2.2. All in all, take into account that edits to end users files are not really a nice touch.

I can't be 100% certain, but I assume it is a combination of the number of cPanel & WHM servers still running Apache 2.2, and the amount of effort that it would take to develop two ways to accomplish the same thing.

Ok, ask the team for this: May it be feasible to evaluate the results of a single IF routine to evaluate the currently installed version of Apache before starting to glob and edit thousands of .htaccess files?

I don't understand why cPanel aren't able to use other server-wide Apache configuration ensure that the requests to the request needed by autossl are working (i.e. unaffected by .htaccess RewriteRules) .. seems like having to doctor all user-added RewriteRules with a RewriteCond could if avoided if some condition higher up the 'stack' of Apache configuration levels mitigated it.

Benny, could you ask the team by exactly it is that the current behaviour is apparently the *only* way to mitigate the problem?

Nobody understand why Apache 2.2 should work without .htaccess (which is the sake way).

and instead Apache 2.4 should still run messing around .htaccess

Did you see this?

Everybody are asking the SAME: you have to port your script in the .httpconfig and leave .httaccess alone.

This will work both for Apache 2.2 and 2.4!