I am new to windows azure. I have requirement that I have to achieve. I have searched on the google but it was not useful.
I have to deploy multiple web sites to 1 cloud service. Is there any possibility? I will make them ssl enabled with multiple certificates in one cloud service.
So url's will be like:
https:// mysite/Home/
https:// mysite2/Home/
https:// mysite3/Home/
Actually my requirement is I should be able to deploy multiple web site and able to change the web.config after deployment. I think this we can do by enabling remote machine to the cloud service. After that we can login to remote machine and change the web.config file through iis manager. Am I correct?
Do we have any best way to achieve the requirement? I have to consider the minimum cost for this.
Thanks
This is an old post, but it shows how to run multiple websites in the same web role: http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
Regarding the changes in the web.config, you should not do that, because your instances may be changed, and those new instances will not have the modified file. All the configuration you are willing to change after deployment should be stored in the ServiceConfiguration.cscfg file. This way you can modify the configuration without redeploying, and the configuration is shared among all instances of the service.
Related
I am migrating a project to the cloud with the aim to load-balance the website.
It is currently .NET Core app hosted on IIS, but there is a Virtual Application attached to this site in IIS (for a very old MVC3 application):
www.mysite.com hits the .NET Core app
But
www.mysite.com/blog hits the completely separate MVC app.
I want to dockerise my application and run it behind Elastic Beanstalk, or even just some EC2 instances behind a load balancer, but how can I take care of the "blog" app in this scenario? It 100% doesn't need to be load balanced and I don't want to make it part of the deployment strategy, since it is a simple CMS and the code hasn't been re-deployed for years!
EDIT: I'm thinking the Load Balancer provided by AWS must be the thing I am looking for, since it will be linked to the DNS entry and as it is effectively a reverse proxy, I should be looking to see if I can configure the Load Balancer to add a rule to reverse proxy the request into one of my EC2 boxes?
how can I take care of the "blog" app in this scenario?
You can use Application Load Balancer. You can have different listeners handling different URLs (e.g. one listener handles www.mysite.com and another one handles /blog).
You can add more sophisticated rules for /blog to forward its handling to different target groups.
Target groups can contain ECS, EC2 and whatever you need.
Specific to Web Apps hosted on Microsoft Azure, is there a way to prevent the mydomain.azurewebsites.net URL from being indexed by search engines? I'm planning to use a web app as a staging website, and don't want it to accidentally get indexed.
I know I could add a robots.txt file to the project with everything set to no-index, but I don't want to ever accidentally publish it to the production site (or alternatively, forget to publish it to the staging website).
Is there a setting in Azure that will prevent the ".azurewebsites.net" domain from being indexed? Or if the robots.txt file is the only way, how do you keep it organized so that the right robots.txt file is published to staging and production, using ASP.NET Core.
Another option is to enable Authentication against your Azure Active Directory from the Authentication/Authorization tab in your App Service's settings for development and staging environments.
This way users will be forced to login to access those apps.
Documentation: https://learn.microsoft.com/en-us/azure/app-service/app-service-authentication-overview
https://learn.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication
You can publish robots.txt to your staging server once. This can be done via FTP or via your SCM site. Once you publish this file, web publish will not remove additional files on the server (including your robots.txt file) unless you select "Remove additional files at destination" in your web publish settings.
So the robots.txt file will hang around forever on your staging server unless you remove it. Then you do not need to include robots.txt in your project or solution, and not risk accidentally publishing it to your production environment.
Restrict access based on hostname and request IP
Unless you need your staging slot to be accessible to a wide range of dynamic IPs, you could consider using the URL Rewrite module and adding rule[s] to your web app config to disallow traffic except for a few known IPs, but make those rules conditional on the HOST header matching the staging host (mydomain.azurewebsites.net), so they can never apply on the production hostname.
The details in the question here show a similar type of setup.
Received security testing report for our service, which is hosted as Web Role in Azure. One of the points is vulnerability to Slow POST attack. The recommendations are mostly for configuring IIS, which we cannot do here. There is reference to some SiteExtentions that applies to Azure Web Site. But we don't use Web Site, we use Web Role.
Any suggestions what can be done?
Yes! You can use startup tasks defined in your web role to run programs that will customize IIS after the VM hosting your app has been created.
See this MSDN article on startup tasks and this blog post.
Don't forget that many IIS settings can be controlled via web.config sections these days (as long as the host doesn't lock them down). In the event that you can't change the nodes because they are locked, then you need to script the change and host start as others have mentioned.
Looking at Security Labs and their advice on IIS 7 at least some of the confing nodes they link to are held in the web.config:
Request Limits: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits
Header Limits:
http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits/headerlimits
I would like to create a sandbox area on my hosting provider that only the client can see. For example the production website would be at www.domain.com. However, would it be possible to create a sandbox version of the website at www.domain.com/sandbox and only provide access to the client?
If so, what is the best method? Do I manually have to create a login page etc in the sandbox folder? Or, can I publish the test website in the sandbox area and restrict access through my hosting provider?
Generally a sandbox/staging/test version of your production site would be a complete duplicate of your production deployment, not just the login page.
You'd have a separate copy of the application and the database, and then serve it via another hostname/IP address or on an entirely different machine.
For instance, you could have www.domain.com and test.domain.com, each with the own isolated version of the software. This way your client can play as much as they want in the sandbox without fear of damaging the production environment.
To restrict access you could use access control lists in IIS to restrict the sandbox to a specific ip address (or range), or enable basic support on it with a username/password required security.
I'm stumped. I've got an asp.net mvc app being hosted on a shared hosting provider. The configuration of their system leaves a little to be desired, but it's cheap (getting what I pay for I suppose...)
The problem is this: The application is hosted at the root level of the hosting account. I have a virtual directory established underneath the root that is running a .net 2.0 web app along with a web service. I can access the web service directly via the domain/subdirectory url. The main web app (at the root level) needs access to the web service in the virtual (subdirectory). Locally in development, I can run the app against the web service out on the hosting server and it runs just fine. When I push the web app up to the root of the hosting service, I get "The remote name could not be resolved: ".
At first I thought the error was related to the DNS settings of the primary domain since both the web app and web service technically live at the same domain. As part of just trying to get something working, I reverted the web app to reference an older version of the web service on a different server (different host altogether). Again, it works fine locally. When I push the updated web app, I got the same error, but noticed the host name referenced is that of the external domain. Of course, I can access the web service via the browser just fine.
Sorry if this doesn't make total sense... it's late and I'm beat from looking at this for the last few hours. Any help would be greatly appreciated.
EDIT
So the web app simply has a Web Reference to the web service (I could probably just restructure the app avoiding the web service altogether, but time is of the essence [for now]). Since I got stuck last night, I pointed the web reference back to an old server but the issue remains. Right now the url the web reference points to is http://road34.hi-fisoftware.com/webservices/giigsterservice.asmx.
If the server has a firewall then and an external ip and different internal ip then probably you will not be able to access the webservice with the domain name. you will need to access it as internal url or as relative url.