We're developing a new website running in azure. We are currently developing against the local azure dev environment. But now we need to publish and test the site in the real Azure world. But we would like to run in a "closed" environment, where only know users have access, as the site should not go live yet. Any suggestions to accomplish this?
/Rasmus
Windows Azure has something called 'staging mode', see this post: http://sevans.info/2010/10/10/windows-azure-staging-model/
It's very powerful, and exactly what you need as far as I can see.
You could remove the endpoints of your instance configuration, so there will be no forwarding through the load balancer. After that you could use the Remote Desktop to log into your azure instance and test your web application.
Above suggestions are great and I would also like to add two more in this list as well:
Using production deployment and having a dummy index/default page with directory browsing disabled (already set as default) So when someone come you your site there is nothing they will see. And as there is no directory browsing so they can not guess the page*.aspx to visit your site. This will keep your production site running and you can test it from outside.
Removing your instance form Load Balancer while keeping your instance healthy. This will require you to test the Azure Application by RDP to your instance and then launch internally. If you wish to do so here is the Powershell based trick.
You could restrict the IP addresses that are allowed to access your app if you have a static IP address. As per this link: https://azure.microsoft.com/en-us/blog/ip-and-domain-restrictions-for-windows-azure-web-sites/
Developers can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to their websites. With Windows Azure Web Sites developers can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Here's the code:
<system.webServer>
<security>
<ipSecurity allowUnlisted="false" denyAction="NotFound">
<add allowed="true" ipAddress="123.456.0.0" subnetMask="255.255.0.0"/>
</ipSecurity>
</security>
</system.webServer>
Related
I setup a Sitecore infrastructure on azure (I created the same before and it worked) and when I connect to the web apps directly, they all work. I configured access to two of the apps via Application Gateway - while one works, the other one gives 502 on the health status.
I checked on the application and there it shows me that the error is "ERROR_INTERNET_CONNECTION_ABORTED".
When I completely deactivate Sitecore (rename default.aspx and web.config) and put an index.html page, the application gateway can access it.
As mentioned - I have a running deployment that I did with the same ARM template. I also deleted everything and redeployed - same issue.
As mentioned - direct access to the web app works perfectly.
I have NO network restrictions on the web app yet.
It might be the case for Sitecore initial startup to take ages (more than health probe from service gate).
Considering Service Gate does not receive response from WebApp, it assumes application to be unhealthy, and might cache the 502 code.
What does your web app diagnostics say?
I finally found the issue. It was not the startup time and not an issue with the Application Gateway:
<ipSecurity allowUnlisted="false" denyAction="AbortRequest">
<clear />
<add ipAddress="0.0.0.0" subnetMask="0.0.0.0" allowed="true" />
</ipSecurity>
this is in the web.config for newer Sitecore Versions. No idea why it worked for the other installation - but removing this solved the issue for me.
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.
Well, I spent ages on this so I'll do something I don't normally do which is post a question and answer it in case it is helpful to someone else. If someone finds an easier way I'll gladly accept it.
Requirement: -
Need to access website running on azure emulator from an external device for testing.
Website uses oauth.
Website uses https only.
Problems: -
Azure emulator binds to local.
Google+ sign-in checks valid origin and redirect URIs.
It seems a bit crazy to go through all this just to get an external test going. Perhaps it has been one big yak shaving exercise. So, if there is an easier way, I would gladly accept it.
The solution to problem 1 is reasonably straightforward, there are a number of options, the simplest being to use netsh (assuming 33333 is some arbitrary free port that is accessible through the firewall and 44300 is the https enpoint port that azure is listening on):
C:\WINDOWS\system32>netsh interface portproxy add v4tov4 listenport=33333 connectaddress=localhost connectport=44300 protocol=tcp
This will make azure emulator think that the connection is coming from a local device.
If you are using oauth such as google+ sign-in you will still hit problem 2. This is because the host name of the redirect URL that the server sends does not match what google expects. The solution is: -
Configure a domain for your local network, e.g. test.com. This is needed because google+ does not allow an IP address for the redirect URI.
Edit ServiceDefinition.csdef and set the hostheader for the azure endpoint:
<Binding name="Endpoint3" endpointName="HttpsEnd" hostHeader="station.test.com" />
where station is the name of the computer that azure emulator is running on.
Configure google+ to accept the correct redirect URL, e.g:
http://station.test.com:33333/Account/ExternalLoginCallback
Run visual studio as Administrator. You need to run as administrator otherwise the hostHeader in ServiceDefinition does not work.
From your external device, connect to you computer using the full name:
https://station.test.com:33333
References:
netsh port forward
wrt domain config
Add bindings to your azure role in Azure Compute Emulator
Azure host header
I need to make a web api internal to Azure cloud. What attributes or setting to make?
setup
I have two application deployed in azure cloud.
1st is a frontend MVC5 application with UI.
The 2nd is a WebAPI.
The user external to cloud can make calls only to 1st application.
The 1st application calls the 2nd appliction internal to cloud.
i don't what users external to cloud make calls to 2nd application.
How do i restrict it?
The 1st application is a website deployed in cloud. Second application is also a MVC5 website with only WebAPIs deployed in cloud.
Thanks in advance.
Since Azure Web Sites don't support virtual networks yet, what you can do is configure IP restriction.
Place this section in your Web.config file and replace the IP address with the MVC5 address.
<security>
<ipSecurity allowUnlisted="false"> <!-- block everybody, except those listed below -->
<add ipAddress="999.999.999.999" allowed="true"/> <!-- allow requests from the MVC5 app -->
</ipSecurity>
</security>
One caveat is that all Web Sites from the same Azure region are sharing the same IP address. To get around this, you need to configure SSL as described here: http://blogs.msdn.com/b/benjaminperkins/archive/2014/05/05/how-to-get-a-static-ip-address-for-your-microsoft-azure-web-site.aspx
Let's say I have a website that is hosted on a traditional dedicated hosting:
http://www.mycompany.com
This website has 'folders' like /area1, /area2, /area3, etc.
I'd like to host /area1 and /area3 on Windows Azure, and keep the other parts of the website hosted on my existing dedicated hosting.
Is it possible? How?
Subfolders will always be requested against the base host, you will not be able to serve content from the Azure instance without first hitting your www server. If you use subdomains on the other hand (like #CSharpRocks suggest) you will be able to configure separate DNS entries and thus direct traffic directly to the Azure web role without ever hitting your dedicated server.
Not exactly what you're looking for but you can set a CNAME that points to a Web role. You'll end up having something like this:
http://area1.mycompany.com
http://area2.mycompany.com