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

Question

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

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

Спасибо.

Answer 1

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

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

Обновление

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

См. http://msdn.microsoft.com/en-us/library/twk5762b.aspx для получения дополнительной информации (второй параметр createPersistentCookie контролирует это).

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

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