Link to home
Start Free TrialLog in
Avatar of Mark
Mark

asked on

Need rewrite rule to redirect URL

I don't think I'll ever master rewrite rules ...

Here's what I need: I have 2 legitimate URLs: http://mail.mydom.com and http://www.mydom.com. I want anyone trying http://mydom.com to get a 400 status. What's my rewrite rule to do this?

Actually, not sure what the most appropriate return status should be:

400 Bad Request
404 Not Found
501 Not Implemented
503 Service Unavailable

404 implies a bad pagename, not necessarily an invalid domain. 503 implies that the server is down. So, I don't think I favor either of those. Open to suggestions.
Avatar of ozo
ozo
Flag of United States of America image

Sounds like a 501 Not Implemented
Avatar of Mark
Mark

ASKER

Thanks for the suggestion - what about the rule?
Q: Why?

I would expect that www.mydom.com to be the same as mydom.com.
Why do you want to aggravate your visitors by forcing them to type www in front?
Avatar of Mark

ASKER

Dan Cracium:
I would expect that www.mydom.com to be the same as mydom.com.
Why do you want to aggravate your visitors by forcing them to type www in front?
Several reasons:

o This is not a site for "visitors". It is suppose to be for specific people to go to a specific page.

o If you were to go to the http://mydom.com site you would see another reason. The site is "Untrusted". That is because of the two certificate for this domain neither is for just mydom.com.

o If the user goes ahead and accepts the "Untrusted" certificate, they will only get a blank page. I think it would be more polite to give them a status message like "Not Implemented".

I've already received a message from someone who finds the current presentation confusing. Again. this site is not intended for general public use. Authorize users have a specific page at the correct URL to access.

So, I want anything with http[s]://mydom.com[/anything] to return a 501 status.
The problem with mydom.com is that it uses the wrong certificate.
Someone installed the certificate valid for mail.mydom.com and www.mail.mydom.com ...

Godaddy certificates are good for both www.domain.com and domain.com, so both addresses should work.
My recommendation is to not use mod_rewrite to do this.  Instead, the domain should be its own virtual host, and you should handle responses to it in the vhost configuration.

If you absolutely demand having it in the same vhost, then you'd do something like this:
RewriteCond %{SERVER_NAME} ^!(www|mail)\.mydomain\.com$ [NC]
RewriteRule .* - [F]

Open in new window

RE: Dan Craciun:

>>> The problem with mydom.com is that it uses the wrong certificate.

That does not have to be true anymore.  All the big browser players support SNI now, as does Apache.  It is very possible to have more than one cert on a single IP/port set.  

Coincidentally, using a separate vhost supports this concept.
Avatar of Mark

ASKER

www.mydom.com and mail.mydom.com are two different hosts with two different public IPs. My overall point is: I don't want people going to http://mydom.com or https://mydom.com. This is not a public website where I want to attract google searchers. It is a private website accessible from the public Internet. The users must know the URL.

I'm not quite following Dan Cracium's suggestion.

RewriteCond %{SERVER_NAME} ^!(www|mail)\.mydomain\.com$ [NC]
RewriteRule .* - [F]

Id like to eliminate all but a certain URL: http[s]://mail.mydoman.com/thisfolder

where my [s] means either http or https is OK; not sure how to write that.

and I don't get why there are 2 rules, one with [N,C] and the 2nd rule with [F]. Why would this not loop since there is no change to the URL. Why not one rule with [L,F] or [L,403]
The URL rewrite is Steve Bink's, not mine :)

I simply said that you installed the wrong certificate, that's why you get "Untrusted" when you visit https://mydom.com.

Check your virtual host group for mydom.com and you'll see you accidentally installed the certificate issued for mail.mydom.com.
>>> It is a private website accessible from the public Internet. The users must know the URL.

Not so much.  If you are running www.mydom.com, it is not a far reach to assume a percentage of your users will just type mydom.com instead.  For making a site private, you would be better off creating some other subdomain, such as private.mydom.com.  This is same point Dan Craciun was trying to make in a previous comment (#41045114).

>>> Id like to eliminate all but a certain URL: http[s]://mail.mydoman.com/thisfolder

That's a separate question.

>>> and I don't get why there are 2 rules, one with [N,C] and the 2nd rule with [F].
>>> Why would this not loop since there is no change to the URL. Why not one rule
>>> with [L,F] or [L,403]

There aren't two rules.  There is one rule, with a condition on that rule.  I recommend taking a look through the mod_rewrite documentation for a more thorough understanding of the rule I am suggesting.

Even better, if the mydom.com domain is its own virtual host, you don't need to worry about creating a rewrite rule.   Simply configure the vhost to accept a whitelist of IPs, or a similar security strategy.
Avatar of Mark

ASKER

>>> Id like to eliminate all but a certain URL: http[s]://mail.mydoman.com/thisfolder

> That's a separate question.

Actually, that *is* my original question -- or at least that was my intention. We've touched on a number of ancilliary topics, so let's get simple ...

I am not going to mess with the certificates.

I don't care if "it is not a far reach to assume a percentage of your users will just type mydom.com." Too bad. I am requiring them to include either the 'www' or the 'mail' prefixes.

Recall that www.mydom.com and mail.mydom.com are different hosts with differerent public IPs. Currently, if someone just enters mydom.com, it routes the the mail.mydom.com host.

Therefore, on that host, I'd like a rule (or whatever) that only permits:

http[s]://mail.mydom.com/thisfolder[/]

How can I do that? If there is a way to do that with a virtual host setting, I'm all ears.
>>> Too bad. I am requiring them to include either the 'www' or the 'mail' prefixes.

The point Dan and I were trying to make is that you're swimming upstream with that requirement.  I.e., you are making your own life more difficult by trying to ignore what is widely considered "standard" behavior.  But, as you say, that's what you want.  

>>> Therefore, on that host, I'd like a rule (or whatever) that only permits:
>>> http[s]://mail.mydom.com/thisfolder[/]

There are two approaches to this:

1) Accept only those requests going to /thisfolder.  The rule below will force a "Forbidden" response to any request outside of the target folder:
RewriteRule !^/?thisfolder/.*$ - [F,NC]

Open in new window


2) Force all requests into /thisfolder.  The rule below will force non-compliant requests into the /thisfolder directory:
# "standard" version
# e.g., mail.mydom.com/somefile.html --> mail.mydom.com/thisfolder
RewriteRule !^/?(thisfolder/.*)$ /thisfolder [R,NC]
# alternate version, reusing the path from the initial request
# e.g., mail.mydom.com/somefile.html --> mail.mydom.com/thisfolder/somefile.html
RewriteRule !^/?(thisfolder/,*)$ /thisfolder/$1 [R,NC]

Open in new window

Avatar of Mark

ASKER

Steve Bink: Neither of those are what I want. In the first case, both http://mail.mydom.com/thisfolder and http://mydom.com/thisfolder will load 'thisfolder', with the latter case also giving the untrusted certificate error.

In the 2nd case, any random schmoe typing in http://ohprs.org will get to thisfolder. As I said, the user needs to KNOW the URL, which shows a login page. Non-members are not welcome explore this page.

It's not supposed to be easy to find.
>>> both http://mail.mydom.com/thisfolder and http://mydom.com/thisfolder will load 'thisfolder'

They won't, as long as you have these two as separate virtual hosts.  Again, separate these into different virtual hosts, and a lot of your problems become easily manageable.

>>> In the 2nd case, any random schmoe typing in http://ohprs.org will get to thisfolder.

They will go to whichever site is marked as the default site.  Proper organization of your virtual host includes will resolve this.  Select which of your virtual hosts should be default, and make sure it is a) found first, and b) covers a wildcard host IP:port.

>>> It's not supposed to be easy to find.

If your member area is supposed to be secure, then secure it.  Security through obscurity just isn't going to work here, especially when your obscurity consists of simply removing the "www" from the domain.  You should be implementing either HTTP-level authentication through Apache, or relying on application-level authentication.  Your landing page for the secure site (the only page unauthenticated users should be seeing) should not have anything on it to "explore".  It should ask for credentials, and maybe a link back to the "regular" site.
Avatar of Mark

ASKER

What's your vision for the virtual host? What should it contain? I don't really see how that blocks usage of mydom.com.
They will go to whichever site is marked as the default site.  ...
I believe you're still permitting mydom.com, just directing it to the "proper" page, right? If so, not what I want.  
Security through obscurity just isn't going to work
Oh! I heartily disagree!! Obscurity it every security system's first level of protection. What's Unisys' catch-phrase for its "Invisibility Cloak"? "You can't hack what you can't see." And of course, I have all the other security layers, you mention, plus pro-active monitoring.

So, we aren't going to come up with a rule, are we?
ASKER CERTIFIED SOLUTION
Avatar of Steve Bink
Steve Bink
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial