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

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

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

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

Кто-нибудь в настоящее время использует отдельный проект 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!) не могут быть доступны внешним пользователям без соответствующих учетных данных. Индивидуальные действия затем переопределяются соответствующими учетными данными, если это необходимо, но в целом это подход "установить и забыть". Хотя у вас могут быть два базовых контроллера в односайтовом подходе, я считаю, что он будет немного менее управляемым.