ASP.NET MVC: ¿área o aplicación web separada para administración?

Question

Hasta ahora he estado utilizando un MVC Área para la administración parte de mis aplicaciones MVC, pero recientemente he estado reconsiderando este debido al hecho de que no se puede tener más de una configuración para autenticación de formularios por aplicación.

Esto se ha convertido en un problema porque en un proyecto reciente quise configurar las cookies de autenticación para que no expiraran para los usuarios, pero no quiero esto para los usuarios de administración. Tampoco quiero que la página de inicio de sesión del usuario se use para acceder a las herramientas de administración.

Estoy considerando la posibilidad de configurar un proyecto MVC independiente en la solución puramente para herramientas de administración. Esta me parece la mejor opción, pero me pregunto acerca de las complicaciones con el despliegue. (Actualmente estoy usando un proyecto de implementación web en VS2008 para administrar la compilación).

¿Alguien actualmente utiliza un proyecto separado de MVC para la sección de administración? ¿Algún problema? ¿Otras opiniones sobre por qué esto no es una buena idea?

Gracias.

Answer 1

Siempre estoy usando un sitio web para la administración. Pero es principalmente porque la administración de mis sitios es totalmente diferente del uso y, por lo tanto, requiere un diseño diferente.

Otra cosa positiva es que no tiene que preguntarse si los usuarios pueden modificar cosas que no deberían poder modificar, ya que esas partes no están integradas en el sitio web del usuario.

actualización

quiero decir Disposición con la maquinilla de afeitar o formularios web Maestra con vista motor.

Utilizamos http://admin.domainname.com y http://www.domainname.com para separar los sitios. Muy fácil de configurar.

La separación de los sitios también hace que los controladores y las vistas sean mucho más limpios, ya que solo manejan tareas para administradores o usuarios. No hay necesidad de muchos ifs (que de otra manera puede ser muy fácil de agregar si usted es como yo = un codificador perezoso :)

Answer 2

El método FormsAuthentication.SetAuthCookie le permite controlar si persiste en todas las sesiones o no.

Si son administradores, configúrelo en false, de lo contrario, en true.

Consulte http://msdn.microsoft.com/en-us/library/twk5762b.aspx para obtener más información (el segundo parámetro createPersistentCookie controla esto).

En términos de una página de inicio de sesión diferente para diferentes clases de usuario, puede devolver falso desde el método de autenticación si son la clase incorrecta de usuario y acceder a la página de inicio de sesión incorrecta.

Toda esta lógica debería ocurrir antes de configurar el token de autenticación.

Answer 3

prefiero mantener el sitio de administración independiente para una serie de razones:

• riesgos de seguridad potenciales se reducen en gran medida el acceso a zonas sensibles sería más fácil para restringir y controlar.
• En una buena solución, Separation of Concerns entre las capas (servicio/datos, etc.) significa que debe ser relativamente simple conectar su sitio de administración para acceder a la funcionalidad que está disponible en su sitio principal.
• Los desarrolladores tienden a preocuparse menos por pulir su sitio de administración, ya que las empresas generalmente se enfocan en sus sitios de front-end. Esto significa que es menos probable que los errores descuidados que afectan el sitio de administración afecten al principal.
• Utilizo un controlador base con el AuthorizeAttribute, lo que significa que todas las acciones (excepto login!) No pueden ser accedidas por usuarios externos sin las credenciales adecuadas. Las acciones individuales son anuladas con credenciales relevantes donde se requiere, pero en general, es un enfoque de "configurar y olvidar". Aunque podría tener dos controladores base en un enfoque de sitio único, creo que sería un poco menos manejable.

Answer 4

La cookie de autenticación de formularios podría tener una ruta de acceso restringida para el área de administración, pero eso le daría un poco de dolor de cabeza al tratar con la autenticación, pero podría ser posible lograrlo.

Otra opción en lugar de usar admin.hostname.com o algo similar, es usar una subaplicación en/admin, sin embargo, eso no resolvería necesariamente su problema.

Desarrollamos nuestra aplicación web como dos sitios diferentes, principalmente porque queríamos la opción de dividir la administración del sitio real, y también por razones de escalabilidad. Queríamos poder escalar el sitio web real en cuestión, y no la parte de administración.

Hemos llevado a cabo en las siguientes cuestiones:

1. de vista previa del contenido requiere cierta lógica que puede que se necesitan para almacenar el nombre de host real para el sitio en algún tipo de configuración, con el fin de redirigir al administrador el sitio correcto, así como tratar con algún token de seguridad, etc. porque el usuario podría no estar autenticado en el sitio. Esto es mucho más fácil si se encuentra en el mismo sitio (rutas relativas y la misma autenticación).
2. Los sitios que pueden ejecutarse en múltiples servidores web simultáneamente (también conocido como, granja web) deben diseñarse teniendo esto en cuenta. Implica cosas como la invalidación de caché, las recargas de configuración o cualquier otra aplicación almacenada de datos que puedan ser "modificados" en su interfaz de administración. Esto, sin embargo, es un problema en cualquier enfoque. Pero, si su sitio depende de cualquier trabajo programado o integraciones de terceros directamente en su aplicación web, podría presentar algunos problemas si su sitio/sistema de administración se ejecuta en varios servidores. Por lo tanto, podría ser más apropiado ejecutar el sistema de administración en un clúster de conmutación por error de HA IIS, pero el sitio web real (que es propenso a grandes cargas) en una granja de servidores web con equilibrio de carga. Esta separación de configuraciones está a favor de sitios separados.

Creo que por razones de escalabilidad, debe considerar separar las preocupaciones, sin embargo, todo depende del diseño de su aplicación si es posible o no. Estamos construyendo un marco para un cierto tipo de sitios web, lo que significa que la implementación real del diseño difiere de cada uno de los clientes, pero queríamos una forma estandarizada para administrar el sitio, por lo que fue la opción lógica para nosotros.