single code base responding to multiple urls?

[J. Adam White]

I am putting together an application that will be used by different companies. I would like to be able to figure out which company is accessing my application based on url. This would allow me to load company specific information (eg skin). For example:

mydomain.com/companyA
mydomain.com/companyB

even the following would work:

mydomain.com/myApp/companyA
mydomain.com/myApp/companyB

Problem is, I don't know if this can be done. Is there a better way of achieving this goal?

Regards,

Joshua

[Bear Bibeault]

You could certainly map multiple contexts to the same app and use the context path to differentiate. That wouldn't prevent companies from using each others URLs, but they'd have to know about them to do so.

Without more info, it's difficult to try to suggest alternatives.

[J. Adam White]

Thanks for the reply!

In short, I am looking to have one code base serve multiple organizations. When they hit my site, I need to distinguish which organization is which so I may "skin" the applicaion appropriately.

Configuring the application to listen to multiple contexts should work. I would like to avoid tweaking the deployment settings every time I need to add a new organization though.

Any other suggestions?

[Bear Bibeault]

One of the apps I work on sounds like it has similar requirements.

The login credentials not only include a username and a password, but a company id as well. Anyone logging in to a company gets a particluar "skin" as well as any company-specific perferences applied to their accounts. The company id is kept in the user's session along with their user credentials.

Pretty simple. Everything is database-driven, and the usernames are name-spaced to the company (in other words, the same username can be used in different companies).

[J. Adam White]

Bear,

Problem is, not everyone is required to log in. People are required to log in to change data. Not everyone has this privilege. This complicates things considerbly. Any other ideas?

Regards,

Joshua

[Bear Bibeault]

Without a login, your options are obviously more restricted.

Does everyone "come in" through the same page? If each "company" had a unique start page, you could tag the session (or register a cookie) there. But that approach could run into trouble if people bookmark pages within the app and not enter through the "start" page.

Your original idea of mapping multiple contexts to the same app should also be workable. There's just something about relying on the context path for identification that violates my architectural sensibilities.

Anyone else want to weigh in with some ideas? Or explain why my "goo-o-meter"* should not be going off for the context path idea?

* "goo" being my highly scientific and precise term for anything that violates my architectural sensibilities. As in, "keep the goo off the pages".

[J. Adam White]

Bear,

Thanks again for the reply. I understand the "goo-o-meter" completely.

Another idea was to make it a build/deploy problem. Create multiple wars deployed to their own context, each with a different startup parameter indicating the appropriate organization that would let the rest of the application figure out which organization it should be dealing with.

I am still not getting a good vibe from any of these solutions. Any other thoughts?

Regards,

Joshua

[Ulf Dittmer]

if you can require people to use different URLs, you can give everyone a company ID or something, so they would come in through .../yourapp/?id=12345. With a long enough ID, this is relatively secure from guessing (so-called security by obscurity). They don't need to remember the ID, after all, they can bookmark it. Of course, you'd still need a cookie/a session, unless you want to include the ID in every URL afterwards.