Existe uma maneira melhor de lidar com a lógica de controle de acesso em vez de estar na interface do usuário?

5

Durante a maior parte da minha experiência com desenvolvedores, nunca tive que lidar com muitas arquiteturas de controle de acesso.

Eles foram bem diretos:

Group [Create, Update, Delete]
    - User 1
    - User 2

Group [Update, Delete]
    - User 2

Que, para todos os efeitos, funciona bem. O problema que tenho é a implementação real dele. Todas as soluções em que trabalhei concede / nega a visibilidade de um link de menu, ou desabilita um botão etc. Tudo isso é controlado pela camada superior do aplicativo, seja uma interface Web ou WinForms.

Estou nos estágios iniciais de criação de um sistema WinForms bastante grande, portanto, gostaria de ter a arquitetura de segurança desde o início.

Embora eu não me veja impedindo visualmente o usuário de executar determinadas ações (desabilitando controles restritos, etc.), tenho certeza de que existem soluções melhores disponíveis, fazendo a maior parte do trabalho na interface do usuário.

Pelo que entendi (e estas podem ser limitadas pela minha ignorância), estas são as minhas opções:

  • Coloque a lógica para retornar e verificar os direitos do usuário na camada de negócios
  • No evento form_load, obtenha essas regras e ative / desative elementos da interface do usuário
  • Deixe os elementos da interface do usuário intactos e interrompa a operação de dentro da camada de negócios, se o usuário não tiver permissão para a ação (sujo!)

Certamente deve haver soluções mais elegantes do que isso. Alguém poderia me fornecer alternativas ou melhorias para as idéias acima mencionadas?

Estou pensando nisso incorretamente? Devo reavaliar meu design de banco de dados enquanto estou nisso?

    
por Daniel Minnaar 13.05.2013 / 22:09
fonte

3 respostas

5

O WPF encoraja strongmente o uso do padrão Command, que encapsula a lógica de um determinado pressionamento de botão ou item de menu em um objeto ICommand , em vez de um manipulador de eventos code-behind. A parte interessante desses objetos é que, além do método padrão Execute , também possui um método padrão CanExecute , que determina se o botão está ativado ou não. Esse método pode ser usado tanto pela lógica de validação quanto pela camada de permissões para determinar se o elemento da interface do usuário está ativo.

Isso permite que a lógica de permissão seja "do lado do servidor", como parte da lógica de negócios, e tenha a visibilidade, "ativação" e funcionalidade do elemento da interface do usuário vinculados a ela usando vinculação de dados, Elementos da interface do usuário e ativando / desativando-os.

Isso se encaixa com a filosofia geral do WPF de usar o padrão MVVM, usando vinculações de dados entre a interface do usuário e os modelos de visualização back-end para ocultar toda aquela feia "checar o nível de permissão e definir a propriedade do botão adequadamente".

    
por 13.05.2013 / 22:24
fonte
2

O que você descreveu é basicamente o que você precisará usar. (Desculpe)

Considere tratar cada seção principal de sua interface do usuário como módulos / formulários separados. Em seguida, tenha um formulário pai que possa ser usado para controlar se determinados formulários filhos serão ou não carregados com base em sua lógica de negócios.

Isso permitiria que você mantivesse a lógica de controle de acesso nas camadas de lógica de negócios e confiasse minimamente no code-behind. Esta camada de verificação de autorização pode ser limitada a show de granulação grossa | desativar | decisões tipo no-show.

Como o aplicativo winform será executado em um sistema fora de seu controle, você precisará ter graus adicionais de verificações em sua lógica de negócios que forneça uma interface para sua camada de banco de dados. É aqui que você aplicaria verificações de autorização mais refinadas.

Finalmente, considere o uso do WPF em vez do WinForms, se puder. O WPF é melhor estruturado para facilitar seu padrão de apresentação de escolha (MVC, MVVM, MVP, etc ...) do que o que o winforms fornece nativamente. Você ainda pode escrever um aplicativo seguro com winforms, basta um pouco mais de esforço.

    
por 14.05.2013 / 00:25
fonte
0

Acho que você está procurando o padrão Model View Controller , ou alguma ligeira variação do mesmo. No que diz respeito à segurança, há mais informações aqui: link

    
por 13.05.2013 / 22:21
fonte