I have a classic ASP deployed in IIS 7. The Windows Authentication is enabled and every other authentication is disabled. Thus the page does not require any login, the server is able to determine the NTADMIN username.
We have an Apache rewrite in place so that the page can be accessed in an alias such as https://www-site/app/page.asp rather than accessing it like https://ntp123:8090/app/page.asp; the rewrite is like this:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/app https://%{HTTP_HOST} %{REQUEST_URI} [R,L]
ProxyPass /app http://ntp123:8090/app/
ProxyPassReverse /app http://ntp123:8090/app/
Most of the time, perhaps 99% of the time the code returns the correct "NTADMIN\user":
LoginName = Request.ServerVariables("Logon_User")
However there were several cases when the code is getting the wrong NTADMIN username. I tried to look for any similar issues via Google but most does not show the resolution.
Perhaps the ASP / IIS experts here may have the solution?
It turns out the culprit was Apache HTTP Rewrite, because from observation of the IIS logs, the client IP address is always the same, in this case the Apache Server. It looks like it either has some caching issue or it's just not compatible with IIS's windows authentication. Either way, by removing this, the issue is no longer encountered.
Related
my website resides in public_html/rhf folder.
1. i want if some one enter url https://rhf.in , it should be redirected to https://rhf.in/rhf in background and browser should display only https://rhf.in
also for if some one enters http://rhf.in or http://www.rhf.in it should redirected to https://rhf.in/rhf and shows only https://rhf.in/ in browser address bar.
first case is working fine for me by adding following in .htaccess
RewriteRule !^rhf/ /rhf%{REQUEST_URI} [L]
But second case is not working
Kindly help in this regard
This would be the classical setup:
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,QSA,END]
RewriteCond %{REQUEST_URI} !^/rhf(?:/|$)
RewriteRule ^ /rhf%{REQUEST_URI} [QSA,END]
For the first redirection to http you obviously need to listen and react to the unencrypted http protocol at all. This implements a general redirection. In case you only want to redirect for that specific path you mentioned, the rule would have to be extended by a condition as well.
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a distributed configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a distributed configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using distributed configuration files (".htaccess"). Those distributed configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I'm developing an application that is running on my domain.
All works as expected, but I cannot seem to find any good answer to my problem relating subdomains.
This application allows for different clients to register themselves and get their own "environment" inside the application.
E.g. if client1 registers himself, his environment will be at https://main.application.com/v/client1
Now, as you can see, this is quite ugly. I want him to be able to go to https://client1.application.com/ and in the background it would show him https://main.application.com/v/client1.
I've read this is possible with apache rewrite.
My case is a little bit more complex than a simple rewrite, I'm guessing. What I'm trying to achieve is this:
User goes to | Has to redirect to
client1.application.com | main.application.com/v/client1
client1.application.com/register | main.application.com/v/client1/register
client1.application.com/dashboard | main.application.com/dashboard
client1.application.com/... | main.application.com/...
As you can see, the only time I want to redirect with the /v/client1 appended to my domain, is when somebody is trying to register or trying to reach the login page for their environment. In all other scenarios, I just want to take what's behind the URL and append it to main.application.com (which is where the main app runs). I also don't want the users to notice the redirect, but that the URL in the address bar stays the same.
I've tried to come up with a bit of pseudocode that explains what I want to do:
If subdomain.application.com/ or subdomain.application.com/register
--> take subdomain and paste it like this:
main.application.com/v/SUBDOMAIN/ or main.application.com/v/SUBDOMAIN/register
Else
--> Redirect to main.application.com/URL
e.g. client1.application.com/dashboard --> main.application.com/dashboard
But I'm completely lost on how I should write it with a Rewrite.
Has anybody got experience in this matter that would be able to help me out with those rewrites here? I'm new to this and I cannot find documentation for my specific case.
Assuming that all requests to those host names ("sub domains") are handled by the same http host (by means of a ServerAlias or simply using the default fallback host) this should be pretty straight forward...
do not rewrite any requests directly to example.com or www.example.com
rewrite requests to other hosts that do not specify any path
rewrite requests to other hosts that specify the /register path
no treatment for other paths required if your http host uses the same file system layout (DOCUMENT_ROOT) for all these hosts ("sub domains")
That leaves is with this:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$
RewriteRule ^ - [END]
RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.com$
RewriteRule ^/?$ /v/%1 [END]
RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.com$
RewriteRule ^/?register/?$ /v/%1/register [END]
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This implementation will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
I would like to limit any redirects to URLs within the same application. Is this possible with ISAPI Rewrite (mod_rewrite for IIS)? Basically I want to prevent against open redirection attacks.
One example is where a URL may come from a query string, or some other source. I want to check that any use of that URL, for a redirect, is only permitted if it's within the same domain. For example: Response.Redirect("some URL");
Mine is an ASP.NET application, running under IIS 6.
You can try to use the following to check the domain in query string and show 403 Forbidden if it's an external one:
RewriteBase /
RewriteCond %{QUERY_STRING} !^.*yourdomain.com.* [NC]
RewriteRule .? - [F]
You'll need to do that check on ASP.NET side, not to allow redirects outside your domain. Once redirect instruction is sent to client, your server will never get another chance to bump in because client will immediately go to other domain.
If you don't control ASP.NET code of this application you may try to use Helicon Ape (instead of ISAPI_Rewrite). Helicon Ape has more features and also offers outbound response rewrites, so it may intercept "redirect" response of your application before it is sent to client. Two options are available:
mod_header with "Header" directive;
mod_replace with "HeaderReplacePattern" directive
I have a requirement that I want to check the request headers and according to that I want to forward the incoming request to appropriate sub domain of my company.
For example:
request header A is coming then it goes to a.domain.com always (no matter request comes to a.domain.com or b.domain.com)
Similarly request header B is coming then it goes to b.domain.com always.
Although I can do this by changing my application (checking the request headers in it) and then forwarding the request but I want that instead of request reaching application server, it should be handled by web server at the first.
Is there something available (some way like CGI) which can handle IIS as well as Apache both as my company has sub domains hosting applications on these two.
Any help is greatly appreciated. Thanks
In Apache you can use mod_rewrite to direct the request to another domain, something like the following perhaps:
rewriteEngine on
rewriteBase /
rewriteCond %{HTTP_HOST} ^A$
rewriteRule ^(.*) http://a.domain.com/$1 [L,R=301]
This needs to be scoped appropriately by putting it in a .htaccess file in the appropriate directory or in a site configuration element.
IIS (depending on the version) also supports a rewrite module. For IIS 6 you can look at IIRF which has a syntax similar to mod_rewrite. For IIS 7 take a look at the URL Rewrite Module which has a simple GUI that imports mod_rewrite rules.
I have a web site that I administer that uses Apache 2.0 on the front with Tomcat 6 on the back-end (with mod_proxy proxying the connection between the two).
I want to be able to use the same VirtualHost to also access the phpMyAdmin application running on the box. So, for example, www.mywebsite.com will pass all traffic to Tomcat, but www.mywebsite.com/myadmin (with obvious security) will pass traffic to phpMyAdmin.
How about using mod_rewrite instead of mod_proxy?
You can use the P modifier to send certain request (i.e. all those that aren't to /phpmyadmin*) through a proxy. This actually uses mod_proxy internally.
Something like this (not tested):
RewriteCond %{REQUEST_URI} !^/phpmyadmin
RewriteRule ^.*$ http://tomcat/$0 [P,L]