tag route page net asp asp.net security controls permissions

asp.net - page - asp route tag helper



Mejores prácticas para permisos de control? (4)

Hola a todos, necesito algunos consejos sobre esto ...

Tenemos ciertos permisos configurados en la base de datos para ciertos niveles de control que un usuario puede tener sobre la aplicación. Deshabilitado, ReadOnly y Edit.

Mi pregunta es: ¿hay formas más genéricas / mejores para manejar los permisos aplicados a un elemento de formulario en la página que escribir un método / verificación de seguridad por página para habilitar / deshabilitar / ocultar / mostrar los controles adecuados según los permisos permitidos?

¿Alguien tiene alguna experiencia manejando esto de diferentes maneras?

Editar:

Solo pensé en la posibilidad de agregar constantes para cada capa que necesita seguridad y luego agregar una función IsAuthorized en la clase de usuario que aceptaría una constante desde la forma en que está activado el control, y devolver booleano para habilitar / deshabilitar los controles, esto sería realmente reduciría la cantidad de lugares a los que tendría que golpear cuando / si alguna vez tuviera que modificar la seguridad para todos los formularios.

¡Aclamaciones!

Creo que hay más posibilidades de las que estás considerando.

  • Oculto / Visible - es el campo visible o no
  • Blanked / System / Unchanged: ¿el sistema establece inicialmente el valor en blanco, o en algún valor proporcionado por la regla de negocio, o se deja tal cual?
  • ReadOnly / Editable - ¿puede el usuario cambiar el valor?
  • Required / LeaveBlank / Optional - es el campo requerido para no estar en blanco, o puede dejarse en blanco suponiendo que estaba en blanco para comenzar, o es opcional y puede estar en blanco en cualquier caso

También debe tener en cuenta una gran cantidad de factores que intervienen en la toma de decisiones

  • Papel: generalmente el usuario tiene 1 o más roles, y esos roles pueden permitir o no diferentes posibilidades
  • Estado: el estado del objeto en cuestión a menudo controla qué campos son editables, independientemente del rol
  • Objeto: a menudo los valores del objeto en sí determinan lo que está permitido cuando, más allá de su estado
  • Tarea: puede desglosar la edición de cosas en algo más que solo leer y editar
  • Sección: a menudo quiero controlar las configuraciones para una sección completa del objeto o pantalla, y todos los controles heredan esas configuraciones, pero pueden anularlas de forma individual si es necesario

¿Implementación? Primero, asegúrese de tener una visión clara de cómo se maneja el ciclo de vida de la página. El mío suele ser algo como esto.

  • Obtenga el objeto que está editando, generalmente desde el estado de la sesión, a veces, si está realizando una operación "nueva", es posible que necesite crear una estructura de datos stub para que trabaje en ella.
  • Si esta es la primera vez que la página se carga, complete las opciones en los menús desplegables, esto generalmente es un proceso genérico, hecho solo una vez
  • Si se trata de una devolución de datos, actualice el objeto que se está editando leyendo en valores fuera de los controles
  • Procesar eventos como clics de botón
  • Ejecutar todas las ediciones de su negocio, estas deberían alterar la estructura de datos que están editando
  • Actualice la visibilidad y la capacidad de edición de los controles en función de todos los datos que tenga a mano
  • Llene los controles con los datos del objeto que se está editando, incluidos los mensajes de validación o los mensajes de error

Es posible que desee comprobar cómo maneja django los formularios y los valida . Los formularios se manejan como modelos, tienen su propia clase, por lo que su lista de campos, reglas de validación y lógica de visualización ya no están dispersos en la vista, el controlador y el ayudante. Con una estructura así, es bastante claro dónde pertenece la lógica oculta / de solo lectura / editable.

Parece que esa característica aún no está implementada en los rieles. No solo ahorra tiempo, sino que mantiene tu código limpio y estructurado. Puede comenzar creando una clase base para formularios, donde la validación está separada del controlador.

Perdón por ir un poco fuera de tema aquí, pero aprende de mi error:

Tenía una aplicación web simple una vez que estaba desarrollando y pensé que configuraría 3 niveles de seguridad: lectura limitada (pública), lectura limitada (usuario), lectura-escritura (administración). La tabla de usuarios tenía un nivel de seguridad y todo funcionó bien ... hasta que necesité un control más preciso sobre los niveles de seguridad a medida que crecía el proyecto. Todo comenzó con un usuario que necesitaba más que el control del usuario en un área del programa, pero no el control administrativo completo.

Lo que debería haber hecho fue configurar un sistema ampliable con un control más preciso, aunque al principio no lo necesité. Esto me habría ahorrado mucho tiempo.

Para funcionar correctamente, he encontrado que los niveles de acceso deben ser en este orden creciente: NINGUNO, VER, REQUERIDO, EDITAR.

Tenga en cuenta que REQUIRED NO es el nivel superior, ya que podría pensar que sería EDIT (tanto el permiso de llenado como el de llenado) es un privilegio mayor que el REQUERIDO (permiso de llenado solo).

La enumeración se vería así:

/** NO permissions. * Presentation: "hidden" * Database: "no access" */ NONE(0), /** VIEW permissions. * Presentation: "read-only" * Database: "read access" */ VIEW(1), /** VIEW and POPULATE permissions. * Presentation: "required/highlighted" * Database: "non-null" */ REQUIRED(2), /** VIEW, POPULATE, and DEPOPULATE permissions. * Presentation: "editable" * Database: "nullable" */ EDIT(3);

Desde la capa inferior (restricciones de la base de datos), cree un mapa de campos de acceso. Este mapa luego se actualiza (más restringido) en la siguiente capa (reglas de negocio + permisos de usuario). Finalmente, la capa superior (reglas de presentación) puede restringir aún más el mapa nuevamente si así lo desea.

Importante: El mapa debe estar envuelto de modo que solo permita que el acceso disminuya con cualquier actualización posterior. Las actualizaciones que intentan aumentar el acceso solo deben ignorarse sin provocar ningún error. Esto se debe a que debe actuar como un sistema de votación sobre cómo debería ser el acceso. En esencia, la posterior estratificación de los niveles de acceso como se mencionó anteriormente puede ocurrir en cualquier orden, ya que dará lugar a una marca de nivel de acceso bajo para cada campo una vez que todas las capas hayan votado.

Ramificaciones:

1) La capa de presentación PUEDE ocultar un campo (establecer el acceso a NINGUNO) para un campo de solo lectura especificado por la base de datos (VIEW).

2) La capa de presentación NO PUEDE mostrar un campo cuando las reglas de negocio dicen que el usuario no tiene al menos acceso de VER.

3) La capa de presentación NO PUEDE mover el acceso de un campo a "editable" (anulable) si la base de datos dice que solo es "obligatorio" (no admite nulos).

Nota: La capa de presentación debe estar hecha (etiquetas de visualización personalizadas) para representar los campos leyendo el mapa de acceso sin la necesidad de ninguna instrucción "if".

El mismo mapa de acceso que se usa para configurar la pantalla también se puede usar durante las validaciones de envío. Se puede escribir un validador genérico para leer cualquier formulario y su mapa de acceso para asegurarse de que se hayan seguido todas las reglas.

(También vea el hilo: Mejores prácticas para controlar el acceso a los campos de formulario )