¿Dónde se aplican las reglas de autorización para mi solicitud en capas?

8

Esta pregunta trata sobre la aplicación de las reglas de mi solicitud que me confunden.

Mi controlador está utilizando el servicio y el servicio está utilizando el repositorio.

public class CommentController: ApiController{

    [HttpPost]
    public bool EditComment(Comment comment){
        commentService.Update(comment);
    }
}

public class CommentService{
    ICommentRepository repository;
    ....
    ....
    public void Update(Comment comment){
        repository.Update(comment);
    }
}

Si el usuario está autenticado, puede actualizar un comentario.

Pero un usuario debe editar sus propios comentarios.
Pero un administrador puede editar todos los comentarios.
Pero el comentario no se puede editar después de una fecha específica.
Editar por un departamento

Y tengo algo como estas reglas.

Si aplico la regla "usuario editando comentario propio" en la capa de servicio, cambiaré Actualizar methot y pasar el parámetro del controlador User.Identity.Name,

public class CommentService{
    ICommentRepository repository;
    ....
    ....
    public void Update(string updatedByThisUser, Comment comment){
        // if updatedByThisUser is owner of comment
        repository.Update(comment);
    }
}

Pero, ¿las verdaderas operaciones de servicio cambian por regla?

Estoy un poco confundido acerca de dónde puedo aplicar las reglas. En controlador o en servicio o en repositorio.

¿Hay alguna forma estándar de hacer esto, como los patrones de diseño?

architecture asp.net-mvc architectural-patterns

— barteloma
fuente

En mi experiencia, siempre es bueno aplicar la autorización a nivel de Controlador. Colocaría un atributo de autorización sobre el nombre de la clase Controlador de esta manera: [Authorize(Roles="member, admin")]y ahora todos los métodos de acción en el Controlador solo serían accesibles para los usuarios en el rol de "miembro" o "administrador".

— Alternatex

1

Pero, si necesito usar mi servicio en un proyecto de escritorio y un proyecto de sitio web MVC, debería aplicar las reglas de autorización de todos los proyectos nuevamente.

— barteloma

1

me gustaría

crear un PermissionService separado que implemente métodos como isUserAllowedTo(user, PermissionService.Permissiontype.Update, PermissionService.Topic.COMMENT, additionalContextRelevantParameters)
y llame a los PermissionServicemétodos en el controlador, donde está disponible la información de contexto necesaria (es decir, de la sesión).

Puede diseñar su arquitectura para llamar al servicio de permisos en el CommentService. Pero no recomendaría esto porque agregaría dependencias adicionales al servicio (es decir, sesión) que hace que las pruebas unitarias del servicio sean mucho más difíciles.

— k3b
fuente

1

Primero, tome un tiempo para considerar de qué es realmente responsable el servicio de comentarios. Esto dependerá de sus requisitos específicos, y posiblemente incluso de su mejor juicio.

Si la responsabilidad del servicio de comentarios se limita a actualizar cualquier comentario dado , entonces lo que ha escrito está bien. En este caso, deberá considerar alguna otra lógica condicional para verificar si se puede actualizar algún comentario. Probablemente haga esto en el controlador, o puede crear un subsistema separado para verificar si un Usuario puede publicar un comentario. Puede volver a usar esto tal como planea volver a usar el servicio de comentarios.

Si el servicio de comentarios es responsable de actualizar los comentarios de un usuario , entonces su servicio se convierte en Actualizar (Usuario de usuario, Comentario de comentario) y usted tiene flexibilidad para verificar las reglas comerciales dentro del propio servicio.

Ahora que tiene claro cuáles son sus intenciones de diseño, tendrá claridad sobre cómo implementar su solución.

— Price Jones
fuente