My production setup is as follows:
M1 – ASP.NET Website
M2 - IIS URL Rewrite 2.0 + ARR 3.0
Using IIS URL Rewrite, any request to M2, say http://m2/app/login.aspx will be redirected to M1 as http://m1/app/login.aspx.
On M1, ASP.NET Open Auth has been implemented on the website to use Google external authentication. When user clicks the Google button, the browser will be redirected to the Google login page to allow the user to authenticate.
But when the website is accessed from M2, the redirection url generated by .net oAuth(https://accounts.google.com/[query-string]) to redirect to Google, is being replaced by URL Rewrite as http://m2/[query-string].
So just to be clear; when the request is made to authenticate via an external authentication provider a 302 redirect is returned. Often the form of this may look like:
Response Headers:
...
Location: https://accounts.google.com/o/oauth2/auth?big_long_query_string
...
This redirect is created by a server (M1) that sits behind the proxy server (M2 - IIS URL Rewrite 2.0 + ARR 3.0). So the rewrite server rewrites the Location header to:
Response Headers:
...
Location: http://M1/o/oauth2/auth?big_long_query_string
...
What we need is a rule that does not rewrite the location URL on redirection. It can only target certain redirects as well. Most of the time the behaviour mentioned here is wanted as all redirects are redirected to the main proxy server. Can someone suggest a solution or workaround for certain redirects?
Check out Application Request Routing settings under IIS > [SERVER] > Application Request Routing and on Actions side bar Server Proxy Settings > for Reverse rewrite host in response headers. For the behavior you desire, uncheck the checkbox. That's is a server level setting, use responsibly.
You can also edit %WinDir%\System32\Inetsrv\Config\applicationHost.config. Basically insert/update the following line in the file between <system.webServer> tags.
<proxy enabled="true" reverseRewriteHostInResponseHeaders="false" />
I would assume this setting to be available per site too, but my attempts on web.config files for proxy settings didn't confirm that.
I was able to solve the same issue with an outbound rule in IIS. So You have to create an outbound rule in IIS in URL rewrite module to modify the location header. You have to check for the 302 status header as a condition and provide match URL and action URL for Location header. Below is the steps from referred article.
Modifying Location Header with IIS URL Rewrite
Go to the URL Rewrite feature for your site and click Add Rule(s)…
Select from the Precondition drop-down.
Click Add in the dialog that appears
Enter {RESPONSE_STATUS} in the Condition input field and 3[0-9][0-9] in the pattern field.
Click OK.
Select Server Variable from the Matching scope drop-down.
Enter RESPONSE_Location as the Variable name.
In the Pattern field enter a regex to match the URLs your backend system is producing (e.g. http://local/page)
In the Action Value box enter the correct URL (e.g. http://example.com/page)
Click Apply and your done!
Reference: Handling 301 and 302 redirects with IIS 7 URL Rewrite
Check out global.asax. it is a HTTPModule. All requests go through this file and other modules before they reach your page handlers. Use this to perform certain tasks on your request or response, like url routing, global error handling etc. This file is used to implement application and session level events, such as:
Application_Init - fired when an application first initializes
Application_Start - fired when the application first starts
Application_End - the final event fired when the application ends or times out
Session_Start - fired the first time a user’s session is started
Application_BeginRequest - fired with each new request
Application_EndRequest - fired when the application ends
Application_AuthenticateRequest - the event indicates that a request is ready to be authenticated.
Application_Error - fired when an unhandled error occurs within the application
Session_End - fired whenever a single user Session ends or times out.
Related
I have the following scenario. I have a website in IIS 8 and I am trying to secure it (https). I have made the web with web forms. In the process to secure it I have to change the page at the beginning (default page in the IIS administrator). When I do it, I don't get the change and I go to the website that was set by default.
I have seen the log and when trying to access the new homepage it gives an error 302 (object moved). I have seen the response header and I see that the location is configured with the old home page.
Example:
Old default page: www.namedomain.com/start.aspx
New default page: www. namedomain.com/home.aspx
The new website has as in the response header: location = /start.aspx and as I said before when trying to access it gives error 302.
Thanks.
There's a few things going on here, "securing" the site with HTTPS and also potentially <authentication mode="Forms"> in your web.config where it will try and redirect any unauthorised requests to a login page. It seems like you are just doing the HTTPS though at this stage, and maybe trying to set up a redirect from HTTP to HTTPS?
It sounds like you are also trying to change the default page for the website (in IIS or the web.config?) from default.aspx to home.aspx? I'm not sure I understand why you want to do that as it isn't necessary for HTTPS, but the effect of that will mean you can go to https://www.namedomain.com/ and you will get served the content from home.aspx instead of start.aspx (or default.aspx) but the URL will stay as just https://www.namedomain.com/
Normally to set up HTTPS, all you do is go into IIS, Bindings, and add a HTTPS binding (you'll need a TLS certificate to make the https work properly). then just make sure you include the "https://" at the start of your URL.
If you think it might be caching problem on your machine, just add a nonsense querystring to the end of your URL (like https://www.namedomain.com?blah=blahblah) and it will cause your browser to get a fresh copy of the page.
I'm not sure what is causing the 302 redirect, have you added any special code to swap HTTP requests over to HTTPS? Can you update your answer with any more info?
Yes, it is what I put in my last comment Jalpa. I do not understand very well the relationship between not configuring the session variables and the default page but once corrected in code, the application correctly loads the web by default.
I have an application which is accessed via HTTPS, but is "reverse proxied" to the server using plain HTTP. It is set up on AWS as follows:
[BROWSER] --(https)--> [ELB] --(http)--> [SERVER]
Everything works fine except when a page is being accessed by an unauthenticated user, the server responds with a HTTP 302 redirect using the whole protocol://server/path string. Like so:
Location: http://my.server.com/Account/Login?ReturnUrl=%2F
The problem is, it specifies HTTP as the protocol (presumably because it is being connected to by the ELB using HTTP. So the browser redirects the request using HTTP and now an error occurs. Is there a way to customize the redirect such that it redirects using just the path, so irregardless of protocol or hostname, it is redirected properly? Like so:
Location: /Account/Login?ReturnUrl=%2F
If this is not advisable, what can be done?
(note: I've checked other solutions posted on SO. All I've seen so far involve customizing the Path, not removing the protocol://hostname)
I've got an asp.net website (let's say http://cdn.mysite.com) hosted on IIS and sat behind an Amazon CloudFront Distribution (using a CNAME to access the cdn.* url above, let's say the distribution URL is http://mysite.cloudfront.net).
If a user hits a folder/directory url without a trailing slash, the server will issue a redirect to the origin cdn url, so if a user navigates to http://mysite.cloudfront.net/thanks, they'll end up on http://cdn.mysite.com/thanks/ instead of http://mysite.cloudfront.net/thanks/
Any suggestions of how to fix this in asp.net / iis / cloudfront?
You're right - and rather than fighting it - have you configured CloudFront to whitelist host headers?
For each behaviour > Forward Headers > Select 'Whitelist' > Select 'Host' from the list and hit Add.
This setting ensures that the host header (mysite.cloudfront.net) is included in requests back to the origin (so make sure you've added mysite.cloudfront.net to your site bindings). I'd expect the redirect issued by IIS will use the correct domain name once this configuration is in place.
Here is the current scenario:
I'm trying to run a JMeter script on my dev machine - dev.mysite.com and I'm running into an issue.
In production this works fine:
With a correct user / pass -
www.mysite.com/login.html
www.mysite.com/secure.html
With a bad user / pass -
www.mysite.com/login.html
server side redirect to www.mysite.com/login_failed.html
My problem is that the server side redirect has the hostname hardcoded
So when I do this on my dev box I get:
With a correct user / pass -
dev.mysite.com/login.html
dev.mysite.com/secure.html
With a bad user / pass -
dev.mysite.com/login.html
server side redirect to www.mysite.com/login_failed.html (redirects to www)
I know I need to fix my code, but I'm looking for a work-around in JMeter.
Is this possible in JMeter?
There is an option within the HTTP Request sampler to control redirects. There are two options. 1. Redirect Automatically (checkbox) and 2. Follow Redirects (checkbox). Uncheck these two check boxes to disable the redirects. You can then include a separate HTTP sampler to perform the redirects if you want by checking the status of the previous request. I face this situation in my projects and this is the technique I use to control redirects.
I Recently set an aspnet application under win 7 IIS 7 and got enabled SSL for this app.
the app works great under ssl, but when i change the schema from https to http, using a response.redirect, the request get a timeout, i am stuck with it, any idea is welcome.
regards
You cannot switch protocols unless you provide an absolute URL. The reference must be absolute.
make use of the encryptedUri and unencryptedUri attributes. "unencryptedUri" may be specified to send the user back to another domain or specific URI when the module removes security.
You can have a custom configuration..
<secureWebPages
mode="RemoteOnly"
encryptedUri="secure.mysite.com"
unencryptedUri="www.mysite.com"
maintainPath="True"
warningBypassMode="AlwaysBypass">
...
</secureWebPages>
An example would be to redirect secure requests to secure.mysite.com and requests that don't need to be secure could be redirected back to www.mysite.com. maintainPath is used in conjunction with the above attributes. When the module redirects to the encryptedUri or unencryptedUri, it appends the current path before sending users on their way.