A project I am working on was once an internal intranet application, but now it is being ported over to a multi-tenant internet application. Usually, when deploying any web applications, we would use the format http://webapp.company.com which has existed long before I joined.
Since the project is now a multi tenant application, I am trying to decide between different architectures.
1) Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
2) Include the tenant as part of the routing and the tenant name will be included as a routing parameter
http://webapp.company.com/{tenant}/my/route/url/{param}
This approach, in my opinion, is 'messy' and I feel it is not the most-correct solution.
3) Keep the existing url of http://webapp.company.com and add specific bindings in IIS to point the requested url to the host location.
When the user enters the url http://tenant.company.com they will be served the application that resides at http://webapp.company.com The problem with this approach is that we may deploy additional applications and this is not scalable.
I am leaning towards approach number 1 as I have experience implementing it (without the extra domain). Is the 4th level domain ideal? Any ideas as to what approach is better than the other? Possibly a new approach? Any input is appreciated.
Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
Actually, you might be able to use a wildcard certificate for *.webapp.company.com, which would mean you can extend this scheme without additional IIS configuration.
In addition, this approach is the most elegant when it comes to routing. There is even a MVC-Subdomain-Routing project on GitHub that you can use for some direction (or as is if your requirements are met by the project).
Also see this question and this answer for some other approaches.
Related
As the title suggests, we are tasked with running a custom .NET MVC application in a virtual directory under the client's Orchard CMS installation. Now, I've successfully done this type of thing in the past with two custom .NET MVC applications, but never with Orchard. Orchard does some unique things behind the scenes, so I do not believe it would be possible.
Two things:
1. I can't build a new Orchard instance from source.
2. It must be a virtual directory on the same domain for SEO purposes. Running the site on a subdomain is bad for Google rankings. Therefore http://www.example.com/myportal is good, whereas http://myportal.example.com is really bad.
Yes you can. While this isn't specific to Orchard, you're likely going to run into some issues with web config inheritance. Depending on the individual scenarios you face (such as shared assemblies but different versions...duplicate config nodes etc) you should be able to search around on stackoverflow and resolve those easily though.
Resource: Virtual directory inside Orchard web application
I currently have a ASP.NET MVC 2 web application and would like to enhance the architecture to support a SAAS model. I plan on eventually building a number of web applications so would like to design the system accordingly.
The goal would be that when a client would hit the following url clientxyz.domain.com they would see an image of all their subscribed applications. This would essentially be a web page with a bunch of application icons. Once a client would click on a icon it would navigate to that actual web app at the following example url clientxyz.domain.com/application_name.
We currently use GoDaddy to host our domain and plan on using a Cloud based iLand server to host our application. We only plan on a few new clients a year due to the nature of our software.
I have a number of questions:
Is it possible to programmatically create subdomains on the fly using a .Net api. I'm pretty sure GoDaddy does not let you do it. So is there another provider that would let me create subdomains via C#. This may be the wrong approach and may not even need to physically create client subdomains. Instead I may be able to accomplish this using url rewriting in IIS/MVC?? If I use rewriting, it would have to satisfy the url requirements mentioned above. Any suggestions/links/examples?
Should I create a separate IIS website for each tenant/client? Or should I use URL rewriting and simply have a single website / application pool? Looks like you can programmatically spin up IIS websites (example: http://www.eggheadcafe.com/tutorials/csharp/d4bba585-b517-4834-8476-ff05b085d86e/iis--create-app-pools-virtual-directories-and-web-sites-c-net.aspx)
Since we are using a Virtual Server on iLand do I simply have to point GoDaddy to the nameserver at iLand.
I would like to automate the entire new client process if possible. To accomplish this, I would have to created the database (probably going to have single db per tenant), populate the global client/tenant table, create admin user account and subscription details in newly created database and create subdomain depending on approach. Am I missing anything?
thanks in advance.
Is there an easy way to share session between different war modules in jboss?
I have a Grails app running in jboss, but want to create a new Grails war module which looks & feels the same as the existing one (but, don't want user to login again). The domain will be same, for example, if I have war1 and war2, the domain should be
http://domain.com/war1 <-- login should be done here..
http://domain.com/war2
I searched through the web, but couldn't find an easy/or difficult way to do this.
Please help~.
No HTTP sessions are not shareable between servlets from different apps. What you really need is a Single Sign On solution. A poor man's SSO can be built with cookies but I wouldn't call it a very secure way. First session can set a cookie and the second session can read the same cookie - this will work as long as the domains are the same for both apps.
Good luck!
I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.
I've seen several similar scenarios explained here but not my particular one. I wonder if someone could tell me which direction to go in?
I am developing two (and more later) MVC2 apps. There will also be another (thicker) client later on (WPF or Silverlight, TBD).
These all need to share the same authentication. For the MVC2 apps they (preferably) need to be single log on - ie if a user logs in to one MVC2 app, they should be authorised on the other, as long as the cookie hasn't timed out.
Forms authentication is to be used.
All the apps need to use common business functionality and perform db access via a common WCF Service App. It would be nice (I think) if the WCF is not publicly accessible (ie blocked behind FW). The thicker client could use an additional service layer to access the Common WCF App.
What this should look like is:
MVCApp1 -> WCFAppCommon
MVCApp2 -> WCFAppCommon
ThickClient -> WCFApp2 -> WCFAppCommon
Is it possible to carry out all the authentication/authorization in the WCFAppCommon?
Otherwise I think I'll have to repeat all the security logic in the MVCApps and WCFApp2, whereas, to me, it seems to sit naturally in WCFAppCommon. On the otherhand, it seems if I authenticate/authorize in WCFAppCommon, I wouldn't be able to use Forms Authentication.
Where I've seen possible solutions (that I haven't tried yet) they seem much more complex than Forms Authentication and a single DB.
Any help appreciated,
Phil
I thought I should come back to this with what I've learned (and re-learned).
First the re-learned lesson - don't become fixed on an architecture and then try and make everything else fit. I'm fixed on .Net, SQL Server, WCF, MVC2, EF4, and IIS7. Fixing in my mind how I want these to fit together is slighly dumb! Better to go out and look at what guidance exists.
Which brings me to what I learned - here's a link:
http://wcfsecurityguide.codeplex.com/
I discounted this article a couple of times because it's a bit dated. However, I'd say it's actually very relevant and if you're starting a project remotely concerned with securing services go take a look. Part IV had everything I needed.
We are using WCF Web Application hosting Reporting system (we are accessing it from Silverlight) and since it's using same machine keys as our MVC application - we can share cookie authentication as well.
Otherwise, you have to send authentication ticket (custom or not) to your WCF application.