Scenario: The login page for a host of web applications lives on an internally hosted server. When this server gets rebooted we need this login page to remain accessible, even if it just displays a friendly message.
The thought I am having is rendering this login page on a different app hosted in the cloud. When our server then gets rebooted the cloud hosted app will instead render a different message.
Is this even a viable option?
What are the pitfalls of this approach?
Are there any cleaner and better alternatives? (And "host the login page in the cloud" has already been considered but I'm looking for alternatives to that as well)
this is totally possible, what your describing is a reverse proxy or load balancer have a look at configuring apache as a reverse proxy server
Related
I have set up an application gateway(AG) to eventually protect my web app using this link but with the difference that the AG's public IP will forward the requests to my web app and I won't be using any jump box.
This diagram should give you a better idea.
Now on my web app, I have added couple of domains under the Custom domains and I don't have any SSL binding thinking that the AG will do the work. Basically I have added the SSL cert to the AG's Front End IP--->Listener. I also redirect the HTTP to HTTPs on AG using the listeners, and on the web app I am not forcing HTTPS.
My questions are:
Is this roughly the right way to protect a web app (Please note that in the future I intend to enable WAF and the DDOS protection on AG)?
Is having the AG do the encryption/decryption going to slow things down?
EDIT: I actually removed the two domains from the web app's custom domains and it seems to work fine without it but I still have the above two questions. :)
Yes, this is the way of doing it, if you want to can configure end-to-end ssl (a bit more secure)
Obviously it will, but negligible.
When it comes to web development, I've heard of the terms web hosting and web server being thrown around. What is the difference and when is each used ?
Web hosting in simple term can be explain like like business of housing ,serving or maintaining files for one or more websites.
When Internet users want to view your website, all they need to do is type your website address or domain into their browser. Their computer will then connect to your server and your webpages will be delivered to them through the browser.
I recently discovered that one of my server machines had the same service under different Web Sites and they were managed by different app pools. Something like this:
Custom Web Site
MyWebSite (Managed by CustomAppPool v4)
Default Web Site
MyWebSite (Managed by Default App Pool v4)
The CustomWebSite version is hit on http 28000 port. The default one is just set up on 80 (this is not really hit)
Both the Web Sites are pointing to C:\inetpub\wwwroot. The Default Web Site version should not have been converted to an application in the first place. My question is how bad is it? Should I be separating the service asap?
My understanding is that IIS will handle the requests independently, so there should not be any danger in sharing code files. Other than it being untidy and allowing potential process issues, I don't think you have to remove it. On the same token, I believe you would be fine to remove it.
Let's take one case that i hosted my web application on window server 2008 R2 and one exe (console application) running on that server.
I can access that web application by URI:
<subdomain>.<domain>.net , is there any way to get subdomain and domain info from EXE (C#) ?
Thanks in Advance.
The answer is... it depends.
If you only have one site hosted on your box then you can just connect to the local instance via either the IP Address the website on the machine resolves too, or by using http://localhost etc.
When you have a URL, the situation becomes more complicated. The machine could be hosting several websites - how do you know which one you want to connect to? In this instance, I would advise just storing the url you want to connect to in config.
However, it should be possible to list the all of the domains from IIS - you'll need to use WMI.
I have a Sproutcore application which uses CouchDB hosted by Cloudant. In devenv I'm using Sproutcore proxy to forward requests to Cloudant (due to single origin policy I obviously can't call a arbitrary hosts from my JavaScript).
What would be your suggestion on hosting the app. CouchApps loading script is failing with obscure error (please note Sproutcore app is around 40 MB of JavaScript and resources).
The thing about hosting an app that talks directly to couchdb is that you are restricted by the same origin policy, so the server that serves up your SproutCore app, has to be on the same domain as you access your couchDB database. If your host provides a static file server, you could use that, but your best bet is probably just to save it as a couch app.
The Key with deploying SC as a couch app, is that you have to set up the URL's that sc-build generates to point to the correct location. This can be done with the buildfile setting something like this:
:url_prefix => '<database>/_design/<designDocument>/'
This way the links point to the right location.
You can also setup CouchDB url rewrites to get simpler urls if you wish. Have a look here for more discussion on this:
https://groups.google.com/d/topic/sproutcore/-D-5T5yPg3A/discussion
PS: 40mb seems overly large! do you have many images? I'd be concerned if you had that much JS/CSS.
Cloudant hosts its clusters (mainly) on EC2 in the us-east-1b or us-west-1b availability zones. If you cannot deploy as a CouchApp you should try to colocate your application layer next to your DB cluster. That will minimize the latency between the web server and the databases.
You can do this yourself by getting an EC2 instance and running a web server on it, or you can use a third party host that hosts on AWS (e.g. Heroku).
In both cases, you will need to run a small proxy from your web server to the database. That's why simply hosting on S3 is not an option at the moment.
Once you deploy your app to a web server, don't forget to check that your web server and your database are in the same AWS availability zone. If they're not, just ask Cloudant to move your account.