2009-08-14 30 views
7

Estoy trabajando para agregar autorización a una aplicación ASP.NET MVC y me he topado con un bloqueo de ruta. Finalmente pude conectar nuestro proveedor de membresía personalizado y obtener la autenticación trabajando para la aplicación. Ahora, como esperaba, si agrego el atributo [Autorizar] a mis controladores, el usuario debe estar autenticado para ver la página. También he probado con éxito [Authorize (Users = "{userName}")] que también funciona para restringir la página a ese usuario específico.HttpContext.Current.User.IsInRole (roleName) siempre devuelve falso

El problema es que [Autorizar (Roles = "{RoleName}")] no parece funcionar como estoy esperando. Si agrego ese atributo a un controlador, cada vez que intento acceder a la página correspondiente, me redirigen a nuestra página de inicio de sesión. Esto es lo que esperaría que sucediera si el usuario no tiene el rol requerido, pero está sucediendo incluso si el usuario tiene ese rol. He comprobado User.IsInRole ("{roleName}") y HttpContext.Current.User.IsInRole ("{roleName}") en una vista, un controlador y un método de ayuda y esto siempre devuelve 'False'.

He verificado que los usuarios con los que estoy trabajando tienen los roles con los que estoy intentando autorizar. También probé estos usuarios en una aplicación de WebForms que restringe el acceso a la página con los mismos roles y funciona bien. Me imagino que tengo algo mal configurado en alguna parte o me falta algo simple, pero después de buscar toda la mañana, no he encontrado nada que me haya acercado más a la solución, así que espero que alguien aquí pueda ayudarme.

+0

Oye, podría editar su respuesta para decirnos cuáles eran las configuraciones, podría ayudar a otros en el futuro. – sirrocco

+0

sirrocco - las configuraciones de configuración eran específicas de nuestra implementación y entorno, por lo que no serían de ninguna utilidad para nadie más. – Hamman359

+0

Su comentario me impulsó a verificar mi web.config y descubrí que el nodo roleManager tenía enabled = "false". Solo quería que la gente supiera que, si está deshabilitada, devuelve un valor falso para IsInRole en lugar de devolver una excepción de algún tipo como podría esperarse. –

Respuesta

4

Primero: utilice un generador de perfiles y cuando ejecute la línea HttpContext.Current.User.IsInRole ("{roleName}"), compruebe qué es la consulta sql.

Si no hace una consulta, probablemente tenga cacheRolesInCookie = "true" e IsInRole revisará el FormsAuthenticationTicket para UserData. Asegúrese de que cuando crea FormsAuthenticationTicket, establezca el parámetro userdata en una cadena delimitada por comas con las funciones del usuario.

+0

Gracias, esto no resolvió el problema, pero sí me llevó por un camino que finalmente lo hizo. Resultó que había algunas configuraciones de configuración adicionales que son necesarias para que el proveedor de roles funcione a pleno rendimiento y nadie se molestó en contarme nada. Una vez que me encontré con eso, todo 'mágicamente' comenzó a funcionar. – Hamman359

+1

¿Qué fue eso ?, tengo el mismo problema, ¿pueden informarme? –

0

Intente borrar la caché de cookies de su navegador. Pasé un tiempo golpeando mi cabeza en un problema similar, y limpiar mis galletas resolvió el problema.

0

En caso de que otros encuentran esta pregunta: ¿

me encontré con un problema similar y el problema fue espacios en el grupo de dominio. Usando lo que HttpContext.Current.User devuelve, las llamadas al IsInRole() parecen comparar usando el nombre del grupo anterior a Windows 2000 que no contiene espacios.

En mi caso pelando los espacios del nombre del grupo pasado a IsInRole() solucionó el problema.

Aquí está un método de extensión interesante que pueda hacer esto:

/// <summary> 
/// Removes all spaces from a string 
/// </summary> 
/// <param name="value">The string</param> 
/// <returns>The string without spaces</returns> 
public static string StripSpaces(this string value) 
{ 
    // my test using both long and short strings showed StringBuilder 
    // to be slightly faster at this than string.Replace() 

    StringBuilder b = new StringBuilder(value); 

    b.Replace(" ", string.Empty); 

    return b.ToString(); 
} 

otra posibilidad es utilizar el System.DirectoryServices.AccountManagement.UserPrincipal y llame IsMemberOf() que debe trabajar mejor con grupos de dominio que contengan espacios.

2

que tenía un problema similar al de la OP. Aunque esta es una publicación anterior, pensé que pondría lo que funcionó para mí. Lo que encontré fue que el proveedor de roles estaba deshabilitado en el web.config. Configuré habilitado como verdadero y resolvió mi problema.

<configuration> 
    <system.web> 
     <roleManager enabled="true" defaultProvider="myRoleProvider"> 
+0

Sí, jaja, eso fue todo. Todas estas soluciones complicadas y resulta ser un simple cambio. Gracias. –

1

Un poco de un viejo tema, pero tuve un problema similar y la causa fue en:

FormsAuthentication.SetAuthCookie(string, bool) 

que estaba usando testigo de identidad del usuario (GUID) como primer parámetro, ya que el código Estaba trabajando con una variable llamada token, pero en realidad debe ser un nombre de usuario válido. Descubrí esto después de usar el generador de perfiles y ejecutar manualmente el procedimiento almacenado de aspnetdb. El documento de MSDN también confirma esto.

También provoca que [Authorize(Roles="rolename")] falle, incluso si el usuario tiene el rol, aunque [Authorize] funciona.

Cuestiones relacionadas