CONCEITO DE PERMISSOES

FBUR 05/10/2009 17:48:38
#324495
Boa tarde!

Estou desenvolvendo um sistema um pouco complexo. é um pequeno sistema integrado onde todos os departamentos vão trabalhar.

A questão é como montar o processo de permissões no sistema.

Hoje tenho alguns sistemas (não tão grandes e não tão integrados quanto este) que já implementei uma lógica para o controle de permissões.
Desenvolvi um software para controlar todos os softwares que crio, que batizei de GUPS (Grupos, Usuários, Permissões e Softwares). No GUPS cadastro todos os usuários, coloco eles em grupos, cadastro os softwares e os seus formulários.

Ou seja, se um cliente tem 5 softwares desenvolvidos por mim, as permissões destes 5 softwares são controladas pelo GUPS.
Deu um trabalhinho no começo mas ajuda bastante. Através dele gerencio todas as senhas dos usuários de uma vez só, além de definir quem acessa o quê, e como acessa (leitura, gravação ou acesso negado).

A lógica do GUPS é assim:
- Primeiro salvo em uma tabela do GUPS todos os softwares e em outra os seus respectivos formulários.
- Também existe uma tabela de Grupos (claro que no GUPS existe um formulário para atrelar um usuário ha um ou mais grupos)
- E por fim, uma tabela que guarda as permissões de cada grupo ao formulário. Assim:

tabela_formulários ---> tabela_permissões <--- tabela_grupos

Vamos supor que um usuário que acesse o software X clique no menu [Ô]Clientes[Ô]. Esse clique chama a rotina de verificação de permissão, que verifica quais permissões o grupo que aquele usuário pertence tem para o formulário acessado.

é isso. Desta forma que hoje controle as permissões.

A questão é que eu estava pensado em mudar o método de verificação de permissão.
Eu gostaria de no login do usuário, já serem verificadas todos os grupos e permissões que estiver associados ao usuário, sobre o software que ele está tentando acessar. Mas esse eu ainda não sei como fazer... Talvez criando uma tabela temporária no banco com todas as permissões... talvez fazer com array bidirecional... Não sei.

Gostaria da opinião de vcs. Como vcs fazem o controle de permissões? A cada clique? No load? Guardam as permissões em um vetor? Na memória? Tabela temporária?

[]'s
TECLA 07/10/2009 19:51:03
#324745
Creio que se você alimentar um ARRAY (com as PERMISSÕES) no ato do LOGON, sua aplicação ganhará muito em termos de PERFORMANCE.
LCSD 08/10/2009 02:45:43
#324764
Bom, nos meus SOFTWARES que já desenvolví e tinha que trabalhar com permissões de acesso, fazia da seguinte forma:

No hora de fazer o LOGON, no sistema, verificava se o usuário tinha PERMISSÃO de utilizar aquele sistema.
Se o USUÁRIO tinha permissão, montava os MENUS (ou mostrava os botões) somente das TELAS ao qual ele tiver acesso.
Nas TELAS, verifico quando aberta, se o usuário tem permissão para INCLUIR/ALTERAR/EXCLUIR o registro.


Portanto, no meu sistema de GERENCIAMENTO, eu tinha o APLICATIVO
Dentro da [Ô]ARVORE[Ô] APLICATIVO, tinha uma árvore de MENUS
Dentro da [Ô]ARVORE DE MENUS[Ô], tinha as permissões que o usuário poderia ter ou não

E conforme abria o EXECUTÁVEL, eu ia montando conforme ele fosse utilizando.
FBUR 08/10/2009 08:48:35
#324773
é assim que eu faço tb LCSD. A diferença é que todos os menus são carregados, e conforme o usuário clica neles, o programa consulta a tabela de permissões para ver qual permissão ele tem. (gravação, leitura, acesso negado).

Um problema que eu esbarro é quando existem diferentes tipos de permissão dentro de um MESMO formulário.
Por exemplo, se um usuário (na verdade são grupos) tem permissão total e outro também, exceto excluir, aí complica. Pois teria que implementar via código.

Mas fiz uma adaptação do seu exemplo, agora estou trabalhado da seguinte forma:
Já que no meu sistema de gerenciamento guardo a identificação do software e os seus respectivos formulários, alterei as permissões (que eram muito genéricas) de:

- gravação
- leitura
- acesso negado

para:

- gravar
- alterar
- excluir
- leitura
- negado

Que são mais abrangentes.

Ou seja, quando o formulário for carregado, as todas essas permissões também serão carregadas. Desta forma o sistema de permissões fica melhorado e consigo contornar o problema de um grupo ter acesso total e outro exceto excluir, ou um grupo não pode apenas gravar e outro apenas atualizar.

Nos testes realizados, desta forma me dá uma flexibilidade muito grande. Dá pra fazer praticamente qualquer combinação.
OBS: Esses exemplos que dei são apenas testes. Alguns testes que fiz não tem sentido, mas mostrou grande flexibilidade.

A questão agora é como carregar as permissões no logon do usuário ou a cada clique nos menus / botões.

A princípio vou manter o método [Ô]por clique[Ô] pois ocorre o seguinte:
Suponhamos que um usuário que está acessando o formulário [Ô]clientes[Ô], pertença a dois grupos diferentes: VENDAS e COMPRAS. O grupo VENDAS pode gravar novos registros, já o grupo COMPRAS não pode.

Desta forma, ao verificar as permissões, o sistema é obrigado a verificar todos os grupos que o usuário pertence, pois se forem checadas apenas as permissões um grupo, (por exemplo COMPRAS) um usuário que teria permissão de gravação, ficaria apenas como leitura.

Ou seja, o sistema deve buscar todos os grupos que o usuário pertence e considerar as permissões menos restritivas que encontrar.

Assim ficaria complicado carregar no logon todas as permissões para todos os formulários do sistema. Da maneira antiga (gravação, leitura, acesso negado) até seria possível pois elas são permissões que valiam para todos os botões do formulário. Já desta nova maneira, as permissões podem variar bastante.

Mas é isso! Acho que agora o sistema de permissões ficou muito bom! Gostei dos resultados!

De qualquer forma, vou tentar melhorar o algoritmo para carregar as permissões no logon, pois agora a performance deve cair um pouco porque as permissões serão verificadas a cada clique nos botões.

[]'s
Tópico encerrado , respostas não são mais permitidas