asp.net-mvc - studio - web deploy agent service

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

Hasta ahora he estado usando un Área MVC para la parte de administración de mis aplicaciones de mvc, pero recientemente he estado reconsiderando esto debido al hecho de que no se puede tener más de una configuración para la 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 la 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 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.

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

Si son administradores, configure esto como false , de lo contrario como 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 usuarios, puede devolver falso desde el método de autenticación si son la clase de usuario incorrecta y acceder a la página de inicio de sesión incorrecta.

Toda esta lógica debe ocurrir antes de configurar el token de autenticación.

La cookie de autenticación de formularios podría estar restringida a la ruta de acceso 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 utilizar admin.hostname.com o algo así, es usar una subaplicación en / admin, sin embargo, eso no necesariamente resolvería 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.

Nos hemos encontrado con los siguientes problemas:

La vista previa del contenido requiere cierta lógica que puede necesitar almacenar el nombre de host real para el sitio en algún tipo de configuración, con el fin de redirigir el administrador al sitio correcto, así como tratar con algún token de seguridad, etc. porque el usuario podría no ser 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).
Los sitios que pueden ejecutarse en múltiples servidores web simultáneamente (también conocido como, granja web) deben diseñarse con eso en mente. 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 motivos de escalabilidad, debería 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.

Prefiero mantener el sitio de administración separado por varias razones:

Los posibles riesgos de seguridad se reducen en gran medida, ya que el acceso a áreas sensibles sería más fácil de restringir y controlar.
En una buena solución, la Separation of Concerns entre las capas (servicio / datos, etc.) significa que debería 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 centran 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 AuthorizeAttribute , lo que significa que todas las acciones (¡excepto el 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.

Siempre estoy usando un sitio web separado 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 podrían modificar cosas que no deberían poder modificar, ya que esas partes no están integradas en el sitio web del usuario.

Actualizar

Me refiero a Layout with Razor o Masterpage con motor de vista de formularios web.

Usamos 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 eres como yo = un codificador perezoso :)