• Post Reply Bookmark Topic Watch Topic
  • New Topic

Supporting multiple companies in a web application

 
James Davison
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Has anyone created an application to support multiple companies in a web application? I thought it would be easy enough to declare my web context as "/" and then examine the URL to see what the current company is similar to a web context, e.g. a company 1 url might be /one/login whereas a company 2 url would be /two/login. However, whenever I declare the web context to be "/", my web application server seems to want to serve up everything including *.css, *.js, *.gif, etc. files in addition to HTML and JSP files. I am using WebSphere Application Server v6.1. Do I have something configured incorrectly? Or perhaps someone else has a better idea for handling this problem? Thanks.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a big question for a servlets forum.

Without going into all of your requirements, have you considered multiple web applications; one for each company? With a build tool like Ant, it's just as easy to create 100 war files from one code base as is is to create one.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a common requirement, but using different URLs (or different web apps) would be a very unusual approach to support it. Have clients log in (or pass a client ID as a URL parameter if you don't require users to log in), and then handle custom behavior according to that ID.

You might actually have different image and CSS directories that correspond to those IDs, if the look and feel of the web site changes for each client.

The exact approach depends on what kind of customizations you need to support for each client. Can you tell us a bit about that?
 
James Davison
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To answer Ben's question, I did consider creating multiple web applications but that could easily get out-of hand. There will be potentially dozens of companies using the application and I think multiple applications could create a testing/validation nightmare when rolled into production. I am not comfortable rolling out dozens of copies without testing each one.

To Ulf: How would you handle logins then? I do not want companies (users) under the corporate umbrella to to be aware that there are other companies using the same application. There will definitely be different stylesheets and images used in the application. Basically, I am charged with providing a different "look and feel" for different companies.

Do you not think using different URLs is feasible? I already have a test application up and running that uses a Front Controller to intercept and handle all requests. It is very easy to determine at that point the user's company as I have defined all the the valid contexts in a company table. From that, I can get the company id to segregate all other data.

Another possibility I considered was creating subdomains but I thought that I might have more flexibility using different URLs as the "web context" could contain one, two or more names.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by James Davison:
Do you not think using different URLs is feasible?


Have you considered the security implications of this approach?

The URL is user-facing. All company information should be handled on the server.

The main app I work on does just this. A user logs in with 3 pieces of info: username, email address and password. The email address is authenticated to the username/password and if correct is used to identIfy the company. It also allows us to namespace the usernames (in other words, company A can have user xyz, and so can company B).

This info along with the user credentials is stored in the session and is used to trigger the different branding and other behavioral differences of the app.

No URLs, no sub-domains, no separate web apps.
[ February 27, 2007: Message edited by: Bear Bibeault ]
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The login would link the user to a company - via the user information in the database. Each company has its own ID, which could correspond to physical directories (../webapps/MyApp/css/COMPANYID/...). If you need more flexibility, store the CSS and image data in the database as well. That has the added advantage that you can build a web-based editor for the style information, so the company can customize their look and feel - that makes for very slick demos!

Different URLs are feasible, as long as they are virtual, not physical. By that I mean that "http://www.server.com/MyApp/dell" and "http://www.server.com/MyApp/gateway" must not point to actual directories named "dell" and "gateway", but instead lead to the same code where "dell" and "gateway" become parameters. Whether there are physical directories for other resources like images and CSS is a separate decision (see above). Of course, any URL ".../dell" must only be accessible by someone authenticated as being from Dell. Also, if you give out URLs like ".../dell", then someone at Dell will think of going to ".../gateway", at which point you'll need to make sure that the login/user authentication system works properly.
[ February 27, 2007: Message edited by: Ulf Dittmer ]
 
James Davison
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To Bear: Yes I have considered the security implications. The concept of different URLs is really an illusion. The login page takes the "web context" from the URL and username/password combination entered by user to establish the company the user is associated with. Therefore, it is possible to have users with the same username for different companies in this application also. After the login page, the user and company information is stored in the session so the user is effectively segregated from other users/companies. The user cannot spoof the URL because the application always uses the user / company information on the server and warns if an attempt is made to change the URL (web context). After the login page, the URL is maintained just so it doesn't appear to the user that the site has changed.

To Ulf: That is more or less what I had in mind when I first started this application. I forgot to mention in my previous post that one of the reasons I was considering different URLs is that I wanted to create an application administrative user interface so new companies (and "web contexts") could be brought on-line incrementally without requiring any additional application configuration. However, I have considered creating a company administrative user interface as you suggest so that each company could specify its own styles, images, etc. similar to what you described The user authentication mechanism will work as I described above to prevent attempts to cross companies.

Thanks to all for your comments!
 
D Rog
Ranch Hand
Posts: 472
Linux Objective C Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I built an application with multitenancy support
Generally it uses your idea to have start url in form http://somedomain/accounting/webapp/companyname
After user signed in, extra part of URL can be omitted since a user id tied to a company. Major problem I have that all companies are sharing the same database schema, besides of potential security risk, it has a performance impact, because some company can actively use database and degrade response time for user of another company. I'd be interested in knowing how do you succeeded with your approach and any problems you met.
 
Ulf Dittmer
Rancher
Posts: 42970
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Major problem I have that all companies are sharing the same database schema, besides of potential security risk, it has a performance impact, because some company can actively use database and degrade response time for user of another company.


I consider it a good thing that the same database schema is used, because maintaining different schemas (or different databases having the same schema) leads to the same maintenance problems mentioned above for the web side with multiple directories.

Since all data is tagged with the company ID, security is generally not much of an issue, as the login ties the user to a company. Of course, if the authentication process is compromised, anything is possible, but in that case even having different schemas doesn't protect you.

As to the performance, supporting multiple companies in a DB should not create different problems than supporting multiple concurrent users of a single company. Or are you advocating having different physical servers for each company?
[ February 28, 2007: Message edited by: Ulf Dittmer ]
 
David Spector
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not use a full-stack framework like RIFE (www.rifers.org); it has support for both an internal content management framework, and for storing templates and CSS and other data in the database. Have the app intercept the URLs and then "do the right thing" depending upon what URL you receive?

You could even keep the application's DBs info in one DB and the individual company data in separate DBs, you could make it transparent so there's no re-coding per application....

reagrds,
David
 
James Davison
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To D Rog: My application is in its infancy stages right now. I'm not sure what the database performance will be right now but I have database guys to deal with that.

I agree with Ulf though in that I want to maintain a single database schema to support all. Mostly for the same reasons I want to maintain a single web application / set of source, i.e. to minimize maintenance on my part. All my tables are keyed by a company id + row id (autogenerated) to ensure data consistency and minimize security issues.

To David: Thanks for the info. I will take a look at RIFE.
 
D Rog
Ranch Hand
Posts: 472
Linux Objective C Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Specific of my application that it has relatively big load on database due that most of business logic implemented as stored procedures. I usually use a separate box for database, so certainly giving haeavy usage companies a separate database box can improve performance. A security risk in my case a bit specific, since the system gives users a possibility of creation custom reports, so users can deal directly with schema.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!