tag route net mvc data authorized asp all asp.net-mvc authorization

asp.net-mvc - route - authorized asp net mvc



autorizaciĆ³n de asp.net mvc utilizando roles (5)

Matt tiene razón.

Para qué sirve la autorización es para demostrar que pueden realizar esa función: lo que intenta hacer es decir si pueden realizar la función para esa ID en particular.

Entonces dos soluciones:

  1. Como dijo Matt, realice una acción que no requiera identificación, pero que busque el usuario conectado actual de la información de la sesión y los recupere.
  2. Realice una acción que requiera una identificación, pero que solo permita el acceso de los administradores, para que puedan modificar la información de otros usuarios si es necesario.

Pero para responder a la pregunta, la Autorización es solo para decir "Sí, esta persona puede usar la acción modificar usuario", no en función del parámetro ingresado.

La otra forma es que podría hacer que verifique que el usuario recuperó == el usuario actual, o redireccionar a otra acción diciendo que no puede editar ese usuario, pero sería mejor simplemente proporcionar una acción que no tome una acción. id, y solo obtiene el usuario registrado actualmente.

Estoy creando una aplicación asp.net mvc que tiene el concepto de usuarios. Cada usuario puede editar su propio perfil. Por ejemplo:

Nada particularmente emocionante allí ...

Sin embargo, me he encontrado con un problema con el esquema de Autorización. En este momento, solo hay dos funciones en el sistema, "Administrador" y "Usuario predeterminado", pero es probable que haya más en el futuro.

No puedo usar el atributo Autorizar normal para especificar Autorización porque ambos usuarios tienen el mismo rol (es decir, "Usuario predeterminado").

Entonces, si especifico el filtro Autorizar así:

[Authorize(Roles = "DefaultUser")]

entonces no hay efecto PersonID = 1 puede entrar y editar su propio perfil (como deberían), pero también pueden simplemente cambiar la URL a http: // localhost / person / edit / 2 y tienen acceso completo para editar PersonID = 2 perfil también (que no deberían poder hacer).

¿Esto significa que tengo que crear mi propio filtro de Autorización que verifica si la acción que el usuario está solicitando "les pertenece" antes de permitirles el acceso? Es decir, si la acción de edición, con el parámetro = 1, es solicitada por la persona que inició sesión actualmente, ¿debo hacer una verificación personalizada para asegurarme de que la persona que actualmente está conectado es PersonID = 1 y, de ser así, autorizarlos? y si no, ¿negar el acceso?

Siento que me falta algo obvio aquí, por lo que cualquier orientación sería apreciada.


Tal vez podría organizar la acción del controlador de forma que la URL sea más parecida a http: // localhost / person / editme y muestre el formulario de edición para el usuario que está actualmente conectado. De esta forma, no hay forma de que un usuario pueda hackear la URL para editar a otra persona.


Una solución más elegante sería escribir su propio filtro de acción de Autorización, extendiendo [Autorizar] o implementando IAuthorizationFilter, de la siguiente manera:

public class AuthorizeOwnerAttribute: FilterAttribute, IAuthorizationFilter { #region IAuthorizationFilter Members public void OnAuthorization(AuthorizationContext filterContext) { // add logic here that compares the currently logged in user, to the owner of the profile that is being edited // get currently logged in user info from filterContext.HttpContext.User.Identity; // get profile being edited from filterContext.RouteData or filterContext.Something } #endregion }

No estoy seguro de cuál sería la lógica real del método OnAuthorization, pero mis comentarios deberían darle un punto de partida. Tendría que buscar en Google para obtener más información: cómo redirigir al usuario a una vista diferente o si lanzar una excepción fuertemente tipada que se maneje en otro lugar (tal vez en un atributo [HandleError]).


Mi $ .02:

Autorizado y autenticado son dos cosas diferentes. En pocas palabras, la pregunta es ¿puedes hacer esto si supuestamente lo haces? Puedes elegir a tus amigos, puedes escoger tu nariz pero no puedes elegir la nariz de tus amigos. No es necesario verificar la autorización si todas las funciones pueden hacerlo (el usuario tiene la mano y la nariz). Tener un método de publicación para que los usuarios accedan a su propio perfil y prueben la identificación del perfil con los valores ocultos o la redirección del formulario (no su nariz, desaparece).

Obtenga un método de Get para editar otros perfiles y simplemente busque el rol de administrador aquí (soy médico, estoy autorizado a meterle la nariz) ...


Solución para este problema: http://nerddinnerbook.s3.amazonaws.com/Part9.htm

"Usar la propiedad User.Identity.Name al editar cenas

Agreguemos ahora alguna lógica de autorización que restrinja a los usuarios para que solo puedan editar las propiedades de las cenas que ellos mismos están organizando ... "