I have an Ember application that is using CORS to access APIs on different subdomains.
Since IE8 and IE9 don't have full CORS support I need to create a proxy to access the APIs.
The Ember application is deployed on an Azure Website and the API's are Web Roles. I have tried to create a proxy using URL rewrite but I only get a 404 Not Found.
I would like the following behavior
https://www.cloudstorez.com/rewrite/cms/public/designs
Rewrites to
https://cms-public.cloudstorez.com/designs
The URL rewrite looks like this
<rule name="Rewrite to APIs" stopProcessing="true">
<match url="^rewrite/([^/]*)/([^/]*)/(.*)" />
<action type="Rewrite" url="https://{R:1}-{R:2}.cloudstorez.com/{R:3}" />
</rule>
If I instead do a corresponding redirect it works fine.
<rule name="Redirect to APIs" stopProcessing="true">
<match url="^redirect/([^/]*)/([^/]*)/(.*)" />
<action type="Redirect" url="https://{R:1}-{R:2}.cloudstorez.com/{R:3}" />
</rule>
Is there something wrong in my rewrite or are there restrictions on Azure Websites regarding URL rewrites or accessing other servers?
Rewriting to External URLs is called Reverse Proxy. This functionality is achieved in a combination of ARR + Url Rewrite. These are two separate modules of IIS.
Reverse Proxy is not enabled by default on Azure Web Sites. But there is a trick to enabled it. Ruslan Y. from IIS Team (or former IIS team) has written a blog post on how to enable reverse proxy on Azure Web Sites here.
Note - I haven't personally tested the trick, so cannot say if it still works (Azure Web Sites has much evolved since Ruslan's blog and this feature might have been disabled), but still worth giving it a try.
Related
Problem #1: I have a classic cloud service running a single web site role. I would like to differentiate between the way it is debugged locally versus how it is deployed to the cloud. Specifically I would like the local site to run on HTTP and the cloud service to run on HTTPS. The main reason for this is that we don't want to have to install the same cert on all the developers' machines. However, the endpoints are defined in the common "ServiceDefinition.csdef", NOT in the two "ServiceConfiguration.cscfg" files ("local" and "cloud"). So, how do I set up different endpoints for local versus cloud?
Problem #2: I would like, especially in the cloud, to have a site running on HTTP that simply redirects the user to the HTTPS site. How would I set that up?
I realize these questions may not have sufficient detail, but I didn't want to write a book. Please feel free to ask for clarification.
Thanks a lot in advance!
Partial answer to your questions:
Problem #2: I would like, especially in the cloud, to have a site
running on HTTP that simply redirects the user to the HTTPS site. How
would I set that up?
For this, you can simply rely on web.config transforms. In your web.release.config you can set a redirection rule which will redirect http requests to https. Something like the following:
<rewrite>
<rules>
<rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{SERVER_NAME}/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
Similar thing would just not be present in your web.debug.config (or web.config).
Specifically I would like the local site to run on HTTP and the cloud
service to run on HTTPS.
For this, the way I have handled it in the past when I worked on Cloud Services is basically I created separate cloud projects for each environment (WebApp.Azure.Dev, WebApp.Azure.Prod etc.). This way I would get separate csdef file for each environment.
We have a Web App hosted in Azure. We have a staging deployment slot that the web app is on and the URL provided is a .internal link that is not accessible. How do we create an accessible URL for the deployment slot. Thank you!
The staging site deployed would have a separate URL on the slot's resource page. The deployment slot has its own host name and is also a live app. Which is publicly accessible by default, however, we have ways to limit public access to the deployment slot, for this checkout 'Azure App Service IP restrictions' – For it to work, IPv4 address ranges that start with 10. and 100. are internal to your deployment. You should allow them to connect to your app.
You have stated that the staging site is inaccessible, please do share more details on the error you may be receiving and how exactly are you accessing the site.
Some common issues and ways to mitigate:
During custom warm-up, the HTTP requests are made internally (without going through the external URL). They can fail with certain URL rewrite rules in Web.config. For example, rules for redirecting domain names or enforcing HTTPS can prevent warm-up requests from reaching the app code. To work around this issue, modify your rewrite rules by adding the following two conditions:
<conditions>
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Without a custom warm-up, the URL rewrite rules can still block HTTP requests. To work around this issue, modify your rewrite rules by adding the following condition:
<conditions>
<add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" />
...
</conditions>
Checkout the doc setting up App Service staging environment for more details on this topic.
i have a problem with a custom domain in azure, i created a webapps and configurate the custom domain, the only https is disable
the hosting of domain is azure dns zone
when i try go to my page, always redirect to https
i did step by step from https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain
Azure Web Apps do not automatically redirect http to https by default. It may be caused by some logic in your specific app.
Here is a similar issue, you could refer to it.
Azure Web Apps do not automatically redirect http to https by default, so it may be caused by some logic in your specific app, or some other non-default step that you took.
To see this, simply create a new empty Web App, and verify that you are able to browse to it using http.
its probaly that you have in your config this line
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
I am attempting to host multiple websites in a single Azure WebApp rather than having multiple web apps each hosting a site. Each of these sites is rather small, but in order to meet the requirements of the SLA with Azure, we need to have the server scaled with more than one instance for our Production environment, thus the reasoning for combining sites.
After researching this topic, I have got the following setup with our Azure account.
Created the proper CNAME DNS records in our zone manager (complete and works).
Setup the Azure WebApp to respond to the subdomains (complete and works).
Setup a virtual directory for the second web application (complete and works)
At this point, both web applications function correctly and both subdomains are pointing at our Azure instance. We now have the following setup:
both www.mydomain.com and app.mydomain.com bring up the root application that I deployed.
going to www.mydomain.com/app2 and app.mydomain.com/app2 bring up the second application that I deployed to the virtual directory
What I would like to achieve:
Going to app.mydomain.com would bring up the application in the virtual directory.
Going to www.mydomain.com would bring up the application at the root of the azure instance.
However, what I cannot figure out is how to map a subdomain to a specific virtual directory. I have tried to update the Site URL to be the subdomain I want the application to respond to, however, the subdomain still brings up whatever I have in the root of the WebApp deployment.
Should I have some HttpHandler that sits in the site root and directs traffic to the proper virtual directory? Is there a setting in the portal that I am missing? Previously, we did this with Web Roles and tinkering with the ServiceDefinition file, but the tool sets for the Azure Web Apps in regards to publishing, integration with Source Control, etc seem to be a bit further along.
The answer posted by RuslanY will work (with some modifications to the rules slightly) however, after understanding more of the Azure portal and Web App configurations, it is not needed to host multiple sites within a single Web App (Its technically multiple web apps all sharing the resource plan you define, such as 2 instances of Standard Level 0 (S0))*.
As of today's Azure service offerings, the following is true. When you create a new Web App, you pecify the "App Service Plan" that the app falls into. If you have an App Service plan, lets say Standard with 2 instances, any Web App you deploy to that App Service plan shares those resources with other web apps in the same service plan, meaning you are not paying additional costs to host the additional web app if it is in the same App Service plan. I had assumed each web app was its own set of resources (it can be, but doesn't have to be). Given this, to accomplish what I need, I simply create a web app for each sub domain and place them all into the same App Service plan. I now am hosting multiple sites, not paying for 2 servers per site (what I wanted to avoid) and I don't have to use URL rewrites or HTTP Handlers.
I hope this write-up helps others understand the structure of the Azure Web Apps a little bit better. The current online documentation, from what I can tell, doesn't make this exactly clear.
This may be possible to do with URL rewrite rule which takes the hostname of the request and rewrites the request URL to start with the subdomain extracted from the hostname:
<system.webServer>
<rewrite>
<rules>
<rule name="Rewrite Subdomain To Directory">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^www\.mydomain\.com$" negate="true" />
<add input="{HTTP_HOST}" pattern="^(.+)\.mydomain.\com$" />
</conditions>
<action type="Rewrite" url="{C:1}/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
To understand the syntax of the rewrite rules you can refer to the IIS.net documentation about URL rewrite module.
I would like to be able to have my ASP.NET web application run on a web role for scalability and have a subdirectory point to an Azure website. Like this:
http://www.mysite.com -> resolves to my web role deployment.
http://www.mysite.com/blog -> resolves to a WordPress website deployed on Azure.
I know on a virtual machine I could do this by installing WordPress and pointing a virtual directory under my main site to the location of the WordPress application. I am familiar with the ability to use the ARR web farms and URL Rewriting to accomplish something similar in IIS, but can this be done from within an Azure web role? Is there an easier way? (like by using some really sweet Azure URL rewriting tool)
If you are using MVC, register a route:
routes.MapRoute(
name: "Blog",
url: "blog",
defaults: new { controller = "Home", action = "Blog" }
);
and have the controller/action redirect:
public ActionResult Blog()
{
return Redirect("http://blog.com")
}
If you are using webforms, map the route to a redirect aspx page, and in the Page_Load, redirect.
Finally, you could use URL Rewrite by including something like below in your web.config:
<rewrite>
<rules>
<rule name="Blog">
<match url="^.*/blog.*" />
<action type="Rewrite" url="http://blog.com" />
</rule>
</rules>
</rewrite>