2011-09-05 7 views
5

Cuando se crean/eliminan roles, no me gustaría modificar el código.¿Cómo trabajar con Roles (asp.net) sin hardcoding?

if (HttpContext.Current.User.IsInRole("Super Admin") || 
    HttpContext.Current.User.IsInRole("Admin") || 
    HttpContext.Current.User.IsInRole("Support")) 
{ 
    if (HttpContext.Current.User.IsInRole("Admin")) 
    { 
     ListBox1.DataSource = Roles.GetAllRoles().Except(
      new[] { "Super Admin" }); 

    } 
    if (HttpContext.Current.User.IsInRole("Support")) 
    { 
     ListBox1.DataSource = Roles.GetAllRoles().Except(
      new[] { "Super Admin", "Admin" }); 
    } 
    fillDropDownCustomers(); 
} 

Respuesta

2

Los roles funcionan asignando un valor a algo que un usuario puede hacer. Los Roles no cambian, pero el comportamiento de esos roles sí lo hace. Las soluciones ultra dinámicas tienden a ser excesivas.

Así que tal vez tienen las siguientes funciones

  • superadministrador
  • Soporte
  • administración

Puede tener diferentes acciones (esto dependerá de su sistema)

  • Ver
  • Editar
  • Aprobar

Etc

  • Superadministrador [Ver, editar, aprobar]
  • Soporte [Ver]
  • administración [Ver, Editar]

La parte dinámica viene en la asignación de Acciones. Al hacer las cosas de esta manera, no te importa en qué personaje esté, sino qué acciones tienen. Las acciones son el aspecto dinámico en esta relación. Cuando se realiza una solicitud que va a utilizar el papel usuarios a buscar las acciones asignadas a ese papel (Base de datos manejada para hacer modificable)

la incorporación de este en su estructura de base de datos como "papel tiene muchas acciones", significa que si las cosas cambian en el futuro, deberá actualizar la relación en la base de datos, pero no el código.

Una estructura de base de datos podría ser algo como esto, depende de sus necesidades.

  • UserRole [ID, nombre de usuario RoleID] (Si el usuario se asigna más de un rol que heredan todas las acciones, que podrían ser duplicados y por lo tanto seleccionarse distintos o evitar esta situación, pero creo que el primero proporciona una mayor flexibilidad sin complejidad y limitación. NOTA: la tabla UserRole podría desnormalizarse aún más para hacer que UserNames sea único.)
  • papel [ID, Nombre]
  • Acción [ID, Nombre]
  • RoleAction [ID, RoleID, ActionID] (Clave única restricción sobre RoleID y ActionID)

Cuando se hace una solicitud , se identifica al usuario, etc Nombre de usuario, Luego del entrenamiento, que Rol (s) que están en quering por la RoleAction y por lo tanto su carga asociada acciones

que usarían enumeraciones para sus valores de acción y de rol. Esto hace que sea más fácil trabajar con. Para asegurarse de que la Base de datos y el Código están en el receptor, asegúrese de escribir una Prueba de unidad para conciliar los valores de la base de datos con los valores enum.

+0

Creo que sin el uso de constantes como las otras respuestas han sugerido, entonces esto aún requeriría una codificación rigurosa de los roles en el código. –

+0

Sería sí, pero el uso de roles como se ilustra en la pregunta no se entiende bien y, por lo tanto, el deseo de extender los roles en algo dinámico, cuando en realidad es su comportamiento que es dinámico. – Jonathan

+1

Muchas gracias por esta respuesta. Es realmente útil ya que estaba habilitando/deshabilitando usuarios en cada parte donde necesitaba hacer una acción en lugar de preguntar a la base de datos si podían o no. Sin embargo, todavía me pregunto qué sucede si un usuario en particular puede crear ciertos registros, pero no todos: la creación de una acción llamada "crear" no sería la solución más eficiente, ¿verdad? ¿Tendré que crear relaciones entre las acciones de la tabla y el resto de las tablas? ¡Muchas gracias por tu ayuda! – aleafonso

4

poner esos valores en la clase estática:

public static class MyRoles 
{ 
    public const string Admin = "Admin"; 
    public const string SuperAdmin = "Super Admin"; 
    public const string Support = "Support"; 
} 

Ahora puede volver a utilizarlos como esto:

if (HttpContext.Current.User.IsInRole(MyRoles.SuperAdmin) || 
    HttpContext.Current.User.IsInRole(MyRoles.Admin) || 
    HttpContext.Current.User.IsInRole(MyRoles.Support)) 
{ 
0

respuesta simple es el uso de constantes. La respuesta más contextual es usar IoC para llevar la lógica a otra clase donde puede administrar las relaciones de configuración o base de datos.

0

O bien como las otras respuestas han sugerido, como variables constantes. Sin embargo, aún tendría que cambiar el código y republicarlo si tuviera que cambiar el nombre de uno de los roles.

Otra opción sería agregar los nombres de las funciones en un archivo de configuración. Utilizará la configuración de la aplicación o una clase de configuración personalizada que hereda de ConfigurationSection. Mire aquí cómo http://msdn.microsoft.com/en-us/library/2tw134k3.aspx

De esta manera puede cambiar los nombres de las funciones dentro del archivo web.config y no tendría que actualizar ningún código o republicar el proyecto.

Cuestiones relacionadas