Web application Development - Subdomain

I'开发者_运维技巧m currently at the very early design stage of building a web app that will be used by companies. Each company will have many departments and each department many staff. Each department will manage its own application with staff logging onto the application.

There is the possibility that staff across different organisations will have the same staff id. For that reason, I'm thinking of going with subdomains. Each company will have its own subdomain. I've googled a bit about using subdomains and have seen a number of positives, however not too many negatives except for the SEO implications (which do not interest me really.. this app will require direct contact with each organisation.. it's very specialised)

Can anybody think of any other disadvantages to going with subdomains? Can anyone think of a better way of doing things?

Regards, Fiona

---

Your login information will presumably be in a database table somewhere. You will either need separate databases for each company and will need to identify which database to use. Or you will have all users in one table, with some sort of company id - and you will need to determine which company id to add to your login query.

You can make either of these determinations based on subdomain, or on a company-specific login page, or directory, or you can ask them to pick which company they want to log in to (which would be pretty ugly).

Subdomains should work fine. You'll have to do DNS setup every time you add a company, or work out some apache magic. You may need SSL certificates for each subdomain (I think - I'm not well versed on those). Other than that, I don't see any big disadvantages or advantages as far as code or architecture go. Marketing may have a stronger case for one over the other.

You'll still want to use other methods of making sure that users don't have access to other companies' data, especially if other subdomains are guessable.

We also have a multiple-company application, but decided to make all logins unique. This makes it a little easier for us to identify users uniquely at the expense of occasionally having to explain why some username is not available even though that user's company isn't using it.

---

using sub domains is a good idea, the only concern i have is regarding the authentication of the users. I am a .net guy so i am bringing up this query, i am not sure if you are using asp.net for your development. In case you are using asp.net for developing this website and you are using the asp.net membership, profiles and roles for authentication and authorization, you would end up having security problems. Because a user after logging into http://abc.site.com would have access to the site http://xyz.site.com also. This is the default way the asp.net membership thing works. So you would need to keep this in mind.

Rest i think the sub domain philosophy is good enough.

---

Subdomains might work just fine with asp.net membership. Because the was the tables are created for the membership provider there is a aspnet_applications table which has fields for te application name and description. In the aspnet_memberhip table, each user has a field for applicationID. If the application name is the subdomain then you could possibly limit which user can gain access to which application. XYZ subdomian would be one application with it's own ID, and ABC application would be another one.

Interesting domain problem. Good luck and share your results after it's creation.