ASP.NET MVC - область или отдельное веб-приложение для администрирования?

Ответ 1

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

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

Обновление

Я имею в виду Layout with Razor или Masterpage с движком просмотра webforms.

Мы используем http://admin.domainname.com и http://www.domainname.com для разделения сайтов. Довольно легко настроить.

Разделение сайтов также делает контроллеры и представления намного чище, поскольку они обрабатывают задачи только для администраторов или пользователей. Не нужно много ifs (что в противном случае может быть очень легко добавить, если вы похожи на меня = ленивый кодер:)

Ответ 2

Формы auth cookie могут быть ограничены путём для области администрирования, но это может дать вам некоторую головную боль при работе с аутентификацией, но может быть возможно.

Другой вариант вместо использования admin.hostname.com или что-то в этом роде - использовать субприложение в /admin, однако это не обязательно решит вашу проблему.

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

Мы столкнулись с следующими проблемами:

• Предварительный просмотр содержимого требует определенной логики, и вам может понадобиться сохранить фактическое имя хоста для сайта в какой-то конфигурации, чтобы перенаправить администратора на нужный сайт, а также обработать какой-либо маркер безопасности и т.д., так как пользователь не может быть аутентифицирован на сайте. Это намного проще, если вы находитесь на одном сайте (относительные пути и одна и та же проверка подлинности).
• Сайты, которые могут запускаться на нескольких веб-серверах одновременно (ака, веб-ферма), должны быть разработаны с учетом этого. Он включает такие вещи, как недействительность кеша, перезагрузку конфигурации или любые другие сохраненные данные приложения, которые могут быть "изменены" в вашем интерфейсе администрирования. Это, однако, проблема в любом подходе. Но если ваш сайт зависит от какой-либо запланированной работы или сторонней интеграции непосредственно в вашем веб-приложении, это может привести к некоторым проблемам, если ваш сайт/система администрирования запущен на нескольких серверах. Следовательно, может быть более целесообразным запустить административную систему в отказоустойчивом кластере HA IIS, но фактический веб-сайт (который подвержен высоким нагрузкам) на веб-ферме с балансировкой нагрузки. Это разделение настроек в пользу отдельных сайтов.

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

Ответ 3

Метод FormsAuthentication.SetAuthCookie позволяет вам контролировать, сохраняется ли он на всех сеансах или нет.

Если это админ, установите для этого параметра значение false, в противном случае - true.

Подробнее см. http://msdn.microsoft.com/en-us/library/twk5762b.aspx (второй параметр createPersistentCookie управляет этим).

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

Вся эта логика должна произойти до того, как вы установите токен аутентификации.

Ответ 4

Я предпочел бы сохранить сайт администрирования по ряду причин:

• Потенциальные риски безопасности значительно сокращаются, так как доступ к чувствительным областям будет проще ограничивать и контролировать.
• В хорошем решении Separation of Concerns между слоями (служба/данные и т.д.) означает, что должно быть относительно просто подключить admin для доступа к функциям, доступным на вашем основном сайте.
• Разработчики, как правило, меньше озабочены полировкой своего сайта администратора, поскольку компании обычно сосредоточены на своих интерфейсных сайтах. Это означает, что небрежные ошибки, которые влияют на сайт администратора, с меньшей вероятностью влияют на основной.
• Я использую базовый контроллер с AuthorizeAttribute, что означает, что все действия (кроме login!) не могут быть доступны внешним пользователям без соответствующих учетных данных. Индивидуальные действия затем переопределяются соответствующими учетными данными, если это необходимо, но в целом это подход "установить и забыть". Хотя у вас могут быть два базовых контроллера в односайтовом подходе, я считаю, что он будет немного менее управляемым.