[Resolved] Rewrite rule directly in vhost to fix cPanel AutoSSL ?

[wanah]

Hello,

We are looking for a way to disable .htaccess rewrite rules if a specific condition si met directly from the vhost.

Our idea was to write a rewrite rule that finishes with [L] directly in a vhost include file so other rules are not triggered.

The following rule works if added to the beginning of a .htaccess file but not if added to the virtualhost directly.

Do you have any ideas how I could achive this on our LiteSpeed servers ?

Here is the rule we tried adding :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^\/[0-9]+\..+\.cpaneldcv$ [OR]
RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule (.*) $1 [L]
</IfModule>

Can you see a reason whay it's not working when directly added to the vhost ? Some findings seem to say that I would have to specify a directory. But unless this directory can be specified from a variable of some sort I don't see how this would be possible.

If it's not possible with Apache standard rules, Is there a litespeed sepicific way to achieve this ?

The reason for doing this is we do not approve with the current method cPanel is panning which is to edit all rewrite rules in .htaccess files. We want to try and avoid user's rules from being edited.

 

[NiteWave]

RewriteRule (.*) $1 [L]

how about change it to
RewriteRule /(.*) - [L]

 

[wanah]

In the .htaccess this works :

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^\/[0-9]+\..+\.cpaneldcv$ [OR]
RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule (.*) - [L]
</IfModule>

But in the vhost

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^\/[0-9]+\..+\.cpaneldcv$ [OR]
RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule /(.*) - [L]
</IfModule>

doesn't, and neither does

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^\/[0-9]+\..+\.cpaneldcv$ [OR]
RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule (.*) - [L]
</IfModule>

Are .htaccess rules run before vhost rules ?

 

[NiteWave]

no. virtual host rewrite rule should run first. I'll do some simple tests later today and get back here to report.

 

[NiteWave]

I did some tests on lsws 5.0.19 and apache 2.2
1) virtual host rewrite rule run first.
2) regardless [L] flag in virtual host rewrite rule, rewrite rule in .htaccess will run after 1)
so rule in .htaccess may override rule in 1)
lsws and apache behaves same 1) and 2)

in apache 2.4, there is a new flag [END] -- "Stop the rewriting process immediately and don't apply any more rules.". it may work as you expects but I've not tested it.

there is a solution for litespeed. it works for my simple example.
my example:

virtual host section:

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule (.*) - [E=vhlast:1]

.htaccess: put following

RewriteCond %{ENV:vhlast} =1
RewriteRule .* - [L]

in very beginning of .htaccess. not sure if your complex rules will work in this way as well.

 

[mistwang]

LiteSpeed support [END] flag already, so,

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^\/[A-F0-9]{32}.txt(?:\ Comodo\ DCV)?$ [OR]
RewriteCond %{REQUEST_URI} ^\/[0-9]+\..+\.cpaneldcv$ [OR]
RewriteCond %{REQUEST_URI} /\.well\-known\/acme\-challenge
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule /(.*) - [END]
</IfModule>

at vhost level should work.

 

[wanah]

It works !!!!!

Thanks, you've just saved me hours of manually editing .htaccess files as well as a huge headache with cPanel's idea of automaticaly editing all rules in htaccess files which I can see going awefully wrong…