O uso de condicionais de segurança em uma exibição é uma violação do MVC?

Freqüentemente, o que é exibido para um usuário (por exemplo, em uma página da web) se baseia parcialmente em verificações de segurança. Normalmente, considero a segurança no nível do usuário / ACL parte da lógica de negócios de um sistema. Se uma exibição verifica explicitamente a segurança para exibir condicionalmente os elementos da interface do usuário, ela está violando o MVC contendo lógica de negócios?

Pode haver dois tipos de condicionais de segurança, um no modelo e outro na exibição. A visualização controla a exibição de elementos relevantes, dependendo das permissões do usuário atual, mas o modelo controla o acesso aos dados subjacentes. Desde que o modelo tenha todas as verificações / validações corretas, mesmo que a visualização esteja ausente, ainda haverá segurança.

Normalmente, você precisa ter os dois, pois a visualização precisa mudar para diferentes níveis / funções. O controlador envia os dados relevantes que alterariam a exibição, mas a exibição ainda precisa fazer algo com esses dados para ocultar / exibir o conteúdo para o usuário certo.

É por isso que a maioria das estruturas de modelos tem elementos condicionais ( exemplo do guiador ):

{{#if isCurrentUserAdmin}}
    ....
{{/if}

Isso significa que não é uma violação, desde que as peças apropriadas estejam no lugar correto.

Sim e não.

Se a decisão de segurança real for tomada pela exibição, sim, você estará violando o MVC. Se, no entanto, a visualização delegar a decisão real ao modelo, você estará bem. Não há nada de errado em uma visualização tomar decisões sobre quais elementos exibir, com base nas informações do modelo.

Por exemplo, se você tiver um botão "editar" visível apenas para usuários com permissões de "editor", é bom que a exibição pergunte ao modelo quem é o usuário atual e se ele tem a permissão "editor". usando essas informações para decidir se mostra o botão ou não. Se, no entanto, a exibição fizesse a própria lógica de autenticação e autorização, você estaria violando o MVC.

Eu diria que não .

Mas por um motivo diferente do que o @rvcoutinho disse (embora ele cite a Wikipedia, o que me faz sentir errado no meu pensamento)

Eu diria que quaisquer preocupações de segurança relevantes devem ser compartilhadas pelo modelo fornecido à exibição (dependendo do número de combinações que você queira usar um ViewModel por esse motivo), pois você pode ter opções para os bits de segurança.

Isso permite a validação de segurança em duas camadas: na camada da interface do usuário para que um postback seja subvertido para o caso normal, bem como na camada do servidor para maus atores em que o modelo mantém o conhecimento de segurança dentro de si, para que o controlador entregue as informações para o modelo que o joga imediatamente fora.

Uma segurança de duas camadas como essa é o padrão do setor, e dessa maneira permite que sua lógica de segurança só precise existir em dois locais, portanto é um bônus, assim que você coloca a lógica de segurança em seu controlador, coloca-a lá e no diretório Interface do usuário e no modelo (o modelo precisa, pois é a última linha de defesa e especialmente importante para qualquer uso fora desse aplicativo Web MVC, como um cliente de desktop ou qualquer ferramenta de gerenciamento de servidor)

Eu diria que não .

Normalmente, esse tipo de verificação de segurança será realizada pelo controlador.

A partir da Wikipedia :

Um controlador pode enviar comandos para sua visualização associada para alterar a apresentação da visualização do modelo

E eu não acho que isso deva ser feito diretamente na visão. Se isso for feito via javascript, por exemplo, pode ser um problema de segurança (pode-se desativar o javascript e acessar dados com privilégios particulares).

Novamente, da Wikipedia :

Uma visualização solicita ao modelo as informações necessárias para gerar uma representação de saída .

Existem vários problemas envolvidos nesta questão.

1. A autenticação (esse usuário é quem ele diz ser) não deve ser uma preocupação da Visualização.
2. Autorização (o usuário atual tem permissão para fazer isso ) é uma preocupação da Visualização, pois pode afetar o que é apresentado ao usuário. Assim, o código para exibir um botão de edição pode ser cercado por um tipo condicional if model.userCanEdit() ... endif.
3. A determinação de quais atributos de autorização um usuário possui, ou seja, a lógica de negócios e deve ser colocada no Modelo. (Por exemplo, o privilégio 'editar' exige que você tenha 2000 reputação; ou que você deve ser o autor ou um moderador)

Se é apenas para exibir o elemento da interface do usuário, acho que está ok (de que outra forma você faria isso?). Se houver algum dado nesses elementos, o modelo deve ter certeza de que os contêineres estão vazios. E, é claro, o código para obter os dados da permissão deveria ter sido tratado antes da visualização, para que não haja acesso ativo ao modelo aqui.

Se uma exibição verifica explicitamente a segurança para exibir condicionalmente os elementos da interface do usuário, ela está violando o MVC contendo lógica de negócios?

Sim, é uma violação do MVC.

A visualização existe apenas para exibir elementos e a lógica deve estar no modelo. Ao fazer com que a visualização faça alguma coisa (no seu caso, verifique a segurança), você está colocando a lógica lá.