I’ve scoured the Internet via Google and could not find if it is possible to host ASP .Net and Ruby on Rails on the same server!
Do you know if it is possible?
If not, would I be able to do this?
– www.abc.com – redirects to Page A (hosted on Ruby on Rails server)
– jobs.abc.com OR www.abc.com/jobs - redirects user to Page B (hosted on ASP .Net server)
So from the user point of view, they’re both under the same domain name and appear seamless? So perhaps jobs.abc.com points to a different IP address.
Has anyone done this before?
Thank you all.
Yes, the same physical computer can host RoR and ASP.NET at the same time.
To merge two apps on separate platforms and make them appear as one seamless site is a little more challenging. One not very nice option is to use IFRAMEs to render one site (B) inside another's (A) pages, allowing the top-level URL to still show A's domain, etc.
It sounds like finding out more about the issue you are trying to solve would be a good idea, as going down this road is likely to create a mess in the future, and should be avoided if at all possible.
You can also use sub-domains like you suggested, so that the domain names are similar but not exactly the same.
You will also need to consider how to share authentication, etc., across sites.
You'll not find a host that supports both I guess.
I'm thinking of something similar. Seems a Windows VPS hosting is the way to go, and then I can install Ruby to IIS as FastCGI filter, or even have another server side by side but I don't expect this to work flawlessly when both servers will need to listen to port 80 (doable I guess, but probably troubling).
BTW, for the jobs.abc.com scenario you don't need the two apps on the same server. You can have them on two servers and manage the difference via DNS.
Related
I'm looking for some advice regarding a webservice.
I currently have 3 websites that do the same thing, just with a different branding. Each of the website integrates with a third party site via a webservice and there's quite a lot of config goes into each site.
All 3 sites are on the same server, each has it's own IP and runs under HTTPS.
I would like to move functionality to a central website and access it from my other websites via my own webservice. My initial thoughts are to create a new website using the default webserver as it's only internal to the sites, but it's the first time I've done something like this so I'm not entirely clear.
I've a few questions that I still haven't found the answer to, so would appreciate a nudge in the right direction.
Can this be done via the default website?
Do I need a separate IP from the ones currently allocated to my 3 sites?
Do I need another domain name or will localhost suffice?
Is there a better way?
Thanks in advance.
Your question gives a lot to think about. However, the quick answer is "yes". If you make a web service for yourself, you can host it on localhost, on the same server as your three web sites. You don't need any web address or IP address. Hard to believe that it is actually that simple, but for a locally hosted web service, it is.
After reading your entire question, it seems like your challenges will eventually be logical ones (once you run the traffic of three sites, into one WS). I'm sure you already know that.
I am going to need to host multiple websites in IIS, but will not have separate URLs setup in DNS for each one. Because of this, I will not be able to use the Aias/CNAME functionality in IIS to redirect traffic to individual Websites in IIS.
Would it be secure enough to publish all of my web apps to the same Website in IIS?
Example: under Default Website, there is a folder for each individual web app:
-Default Website
--[folder for webapp1]
--[folder for webapp2]
--[folder for webapp3]
URLs used to access each web app:
www.mydomain.com/webapp1
www.mydomain.com/webapp2
www.mydomain.com/webapp3
Is this sort of setup secure or a good idea (best practices)? It seems like a simple solution to the problem of not having a separate domain name in DNS for every web app (website).
What do you think?
I don't see any issue with that approach, in a way it does simplify things quite a bit actually.
Sites being secure is not going to be affected by this. Of course each application would be under it's own pool, it's always a great idea to run like this.
This being said, your main website is going to run under it's own application pool and if there is a problem with it all your applications will be affected. That's the one thing I would pay extra attention to so you might want to not actually use that top level app pool for anything.
In an upcoming version of a currently-in-development webapp, I need to serve multiple domains from a single site. The code on the site will recognize the individual domains and vary the content accordingly. I do not know all of the domains that we will be serving, as clients can add new domains to their site. The coding parts, I know how to do - when clients add a domain, there will be a corresponding entry into our database and that will act as a key to control which set of content is shown.
The thing is, I suck at system administration. The server already hosts a dozen different sites unrelated to this webapp, so it's not a situation where every domain that hits our server's IP can go through the code I describe above. If I knew the domains ahead of time, I could simply point them to our server's IP and then create bindings in IIS to handle each. But since I do not know the domains ahead of time, I'm rather at a loss. What can I do to enable my IIS7 server to support this situation?
After looking around a bit, I have found a few options for this.
1) Building It Into The Code
Probably the best option is to programmatically create bindings in IIS6 and in IIS7. This way everything is integrated into the webapp, meaning there's no muss or fuss outside of the app. It requires a bit more work in the app itself, but the benefits of keeping things clean and keeping all the functionality around this action inside the single codebase are almost definitely worth it.
2) PowerShell
Another option is to set up a script for powershell to have it handle this stuff based on the script detecting changes to the database. This would work well also, but has the drawback of creating two codebases to maintain.
3) Remove Domain Bindings
This answer led me to try removing the existing domain from the webapp's bindings in IIS. Making this change resulted in being able to reach my webapp by just visiting the IP address (so the binding was no longer an issue). And the one domain we have set for this webapp so far still reached the desired site as well. So it seems that the solution could be as simple as to have no host/domain listed in the bindings on IIS. As long as only one site does this, all traffic that does not match another binding loads that site. A big upside here is that it takes less time/effort than any of the coding solutions mentioned above. The downside is that you can only have one site on the server perform this way, and you can no longer have the server locked to only serving content with recognized domains.
Is it possible to add a extra ip address to the server?
This way you could let the IIS process all request on this IP address and run your logic for these request only. leaving the existing websites untouched.
I have two web site that are 99% similar. They share all of the same pages except the difference being that the logos change, a few of the links change, and the products that show up on either web site are flagged to show up on either or, or both. They use the same database.
I have written a utility method that essentially injects a where clause into any database access code I write throughout the app to determine which products to display depending on the current URL.
Problem: Website B gives the user a warning message that the site they are trying to go to is in fact Website A. I've read that the SSL cert needs a distinct IP.
Right now how I have everything set up is very clean on a maintenance perspective. I can update files in one place. Any suggestions on how to make the SSL behave, or am I looking at seperate IP's for the hosting(I really don't want to have to do this)?
If the latter, what do you suggest?
Site runs ASP.NET 4.0. Precompiled DLL.
UPDATE: Thanks to #GregS comment
If the sites share the same domain you can use a wildcard certificate
site1 - site1.somedomain.com
site2 - site2.somedomain.com
Otherwise you will need to get a UCC (United communications certificate) that will be for both domains.
You will need to configure IIS 7 from the command line because the GUI doesn't support setting different host headers for the same certificate. This tutorial shows how it can be done.
I setup another website in IIS that points to the same files as the first web site, got another SSL cert for the new site.
Poorly worded title, but what I want is to do essentially what StackOverflow does when someone types in www.stackoverflow.com: it redirects immediately to stackoverflow.com, eliminating the www. entirely.
Imo, this is the more modern way of doing things: the www. is redundant and (soon to be) archaic. It also breaks an important principle that I want to follow on my web application: that each unique and valid page be accessible by a single url only.
I realize this is a server thing, so I'm expecting the answer to be that the web host needs to take care of this. Since I don't run my own servers, my question is thus: is this possible to do on shared hosting or does one need to be running a dedicated server in order to configure IIS to do this?
The IIS URL Rewriter will allow you to easily set up a canonoical domain rule so all requests are either redirected to www or non www based on your choice. More info on how
Also, several .net shared hosting providers have this module installed so that you can configure this option like you could on your own iis server.
www. is not redundant or archaic if you are using other subdomains. There are issues with cookies that you have to deal with if you set stackoverflow.com as the root domain.
That being said, you would probably want to do something like my answer to a previous question here:
remove 'WWW' in ASP.NET MVC 1.0
Based on the similarities to this question, and based on your tags, I'm voting to close as a duplicate.
Most hosting providers give this for free. The trick itself is usually performed on the DNS level, by introducing a no-hostname A record in your domain.
And this principle of yours is unattainable in principle. At the very least, there's always the URL with IP address instead of name. Then, your server will, most likely, have a private name like server1334.hostingprovider.com, which is also accessible to the world.