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?
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.
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 ]
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 ]
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!
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.
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 ]
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....
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.