Несколько сайтов на одном веб-сервере против пользователей, указывающих организацию

Question

У меня есть веб-сайт, который поддерживает несколько организаций, в которые входят несколько пользователей. В настоящее время настройка работает так, что все посещают один и тот же сайт и предоставляют свою организацию, имя пользователя и пароль для входа в систему.

Вчера у меня возникла мысль, что было бы проще, если бы мы предоставили каждой организации свой собственный сайт на сервере. Так, например, вместо того, чтобы идти на www.example.com и вводить org1, user1, pwd1, они могут просто зайти на org1.example.com и вставить user1 и pwd1.

Казалось бы, это имеет следующие преимущества:

• Более простой интерфейс для пользователя. Они могут добавить свой сайт в закладки, и им нужно только ввести имя пользователя и пароль
• Более простое обслуживание. Изменения в файле web.config для одной организации или перезапуск сайта могут быть выполнены без влияния на пользователей других организаций.
• Более универсальный. Настройки могут быть разными для разных организаций

Тем не менее, мне интересно, какие, если таковые имеются, недостатки будут?

Answer 1

Не должно быть никаких недостатков, если сайты запрограммированы правильно.

Обратите внимание, что вам не нужно ничего менять в текущей настройке, кроме как предоставить одну страницу входа. После ввода имени пользователя и пароля все суб-сайты могут сходиться в той же части кода, что и сегодня, без необходимости разделения. Зарегистрированный суб-сайт может быть указан и распространен с помощью файлов cookie или дополнительного параметра во всех URL-адресах или каким-либо другим механизмом для глобальных данных.

Если вы выберете отдельные кодовые базы, вы столкнетесь с необходимостью распространения улучшений и разработок от одного к другому, и это будет становиться все более и более сложным с течением времени, и код продолжает расходиться.

Исходя из сложного опыта, я могу сказать, что выбор отдельных кодов может породить сайты, которые становятся все более сложными в обслуживании по мере того, как они продолжают размножаться, так что в конечном итоге соображения обслуживания и повторной синхронизации могут привести к тому, что разработка будет отложена или даже заблокирована, пока какая-нибудь храбрая душа не решит выбросить все это и перезапустить с нуля.