2

I have my main domain as example.software. I used to have example.kiwi configured as a subdomain, but the hosting company could not get the certificate to work.

They asked me to fork out more money to have multiple sites so I could use the addon domain feature. I did that and now the certificate works properly. So example.kiwi has document root under public_html and I cant avoid it. It's set to public_html/example.kiwi.

But there is access from one to another. In particular example.software/example.kiwi is allowed. I am trying to put a rule in example.software .htaccess to fix it, but it has no effect.

RewriteCond ^https:\/\/example\.software\/example\.kiwi$ [NC]
RewriteRule ^(.*)$ https://example.kiwi%{REQUEST_URI}  [R=301,L,QSA]

I realise now that the above is incorrect but I had also tried this

RewriteCond %(HTTP_HOST} ^example\.software\/example\.kiwi$ [NC]

Is there anyway to get this to work? Either redirect or error is fine.

5
  • 1
    The way that cPanel creates document roots for add-on domains is the worst. It would avoid so many problems if they had the document roots in side by side parallel directories rather than in parent/child directories. Dec 20, 2021 at 16:09
  • @StephenOstermiller This isn't a restriction imposed by cPanel as such, but could be a restriction imposed by the host. (All cPanel accounts I've used as far back as I remember have allowed you to create addon domain document roots outside of the main domain, ie. "side by side parallel directories" with the main domain. Although the parent/child directory setup is often the default, unless you manually change it.)
    – MrWhite
    Dec 20, 2021 at 16:20
  • I better answer would probably be to tell them how to configure cPanel better then. I had no idea that was available in cPanel. I've never used it myself. It is still an awful default. I can't imagine a situation in which anybody would actually want parent/child document roots. Dec 20, 2021 at 16:21
  • @MrWhite I agree with Stephen Ostermiller on this, it causes me headaches as a web host. Do you know how to change the default?
    – Steve
    Dec 20, 2021 at 21:54
  • I am with Crazy Domains and the mandatory prefix is public_html. No matter what you do, it puts it back on. And the help explicitly says that you are not allowed to get around it by using "../" Even though I have a solution for now, I am dreading possible future issues. Dec 21, 2021 at 11:13

1 Answer 1

3
RewriteCond ^https:\/\/example\.software\/example\.kiwi$ [NC]
RewriteRule ^(.*)$ https://example.kiwi%{REQUEST_URI}  [R=301,L,QSA]

The condition as written doesn't make sense (it will never be successful so prevents the rule from doing anything). However, the RewriteRule directive would propagate the example.kiwi subdirectory, which is not what you require - you need to remove it.

For example, try the following instead in the root .htaccess file of the example.software domain:

# https://example.software/.htaccess

RewriteCond %{HTTP_HOST} ^example\.software [NC]
RewriteRule ^(example\.kiwi)(?:$|/)(.*) https://$1/$2 [R=301,L]

This will redirect a request for https://example.software/example.kiwi/foo to https://example.kiwi/foo.

The $1 backreference simply saves repetition and captures example.kiwi from the first path segment in the URL-path. $1 contains the remainder of the URL-path (if any), eg. foo in the above example.

The QSA flag is not required.

NB: Test first with a 302 (temporary) redirect.


Alternatively, you could use the following in the /example.kiwi/.htaccess (subdirectory) file, instead of the parent domain's root .htaccess file. In fact, this would be preferable if you have an existing .htaccess file in the addon domain, since the parent directives (that includes the redirect) could otherwise be overridden.

# https://example.software/example.kiwi/.htaccess

RewriteCond %{HTTP_HOST} ^example\.software [NC]
RewriteRule (.*) https://example.kiwi/$1 [R=301,L]

Although it may be preferable to check whether the request is not for the expected host (rather than is the main domain), since addon domains can often be accessed via the subdomain the addon domain is mapped to as well. For example:

# https://example.software/example.kiwi/.htaccess

RewriteCond %{HTTP_HOST} !^example\.kiwi$ [NC]
RewriteRule (.*) https://example.kiwi/$1 [R=301,L]

Or, simply block access (403 Forbidden) when the requested hostname is not as expected? For example:

# https://example.software/example.kiwi/.htaccess

RewriteCond %{HTTP_HOST} !^example\.kiwi$ [NC]
RewriteRule ^ - [F]

Although you may want to make sure you have canonicalised the hostname first.


So example.kiwi has document root under public_html and I cant avoid it. It's set to public_html/example.kiwi

This might be a restriction imposed by your host, but ordinarily, you can set the document root of the (cPanel?) addon domain outside of the main domain's document root (at the same level in the directory tree as the main domain). And this is how it should be configured most of the time, unless the domains are related.

This then naturally prevents the addon domain being accessed by different hostnames.

2
  • The forbidden in the child domain works like a treat. And thats where it belongs anayway. I did have a better structured example I had tried in the parent, which hadnt worked. And then I forgot It was a comparison :-) Dec 20, 2021 at 20:12
  • @RohitGupta Yes, using the .htaccess file in the addon/child domain (ie. inside the subdirectory) would be preferable to using the .htaccess file in the main domain's document root. I've updated my answer to state that.
    – MrWhite
    Dec 20, 2021 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.