Qual é a melhor maneira de lidar com vários tipos de permissão?

votos
17

Muitas vezes eu encontro o seguinte cenário onde eu preciso para oferecer muitos tipos diferentes de permissões. Eu uso principalmente ASP.NET / VB.NET com o SQL Server 2000.

Cenário

Quero oferecer um sistema de permissão dinâmico que pode trabalhar em diferentes parâmetros. Vamos dizer que eu quero dar um departamento ou apenas um acesso específico pessoa a um aplicativo. E fingir que temos um número de aplicativos que continua crescendo.

No passado, eu ter escolhido uma das seguintes formas que eu conheço para fazer isso.

1) Use uma única tabela de permissão com colunas especiais que são usados ​​para determinar uma forma de aplicar os parâmetros. As colunas especiais neste exemplo são TypeID e TypeAuxID. O SQL seria algo parecido com isso.

SELECT COUNT(PermissionID)
FROM application_permissions
WHERE
(TypeID = 1 AND TypeAuxID = @UserID) OR
(TypeID = 2 AND TypeAuxID = @DepartmentID)
AND ApplicationID = 1

2) Use uma tabela de mapeamento para cada tipo de permissão, em seguida, juntar-los todos juntos.

SELECT COUNT(perm.PermissionID)
FROM application_permissions perm
LEFT JOIN application_UserPermissions emp
ON perm.ApplicationID = emp.ApplicationID
LEFT JOIN application_DepartmentPermissions dept
ON perm.ApplicationID = dept.ApplicationID
WHERE q.SectionID=@SectionID
  AND (emp.UserID=@UserID OR dept.DeptID=@DeptID OR
 (emp.UserID IS NULL AND dept.DeptID IS NULL)) AND ApplicationID = 1
ORDER BY q.QID ASC

Meus pensamentos

Espero que os exemplos fazem sentido. I paralelepípedos-los juntos.

O primeiro exemplo requer menos trabalho, mas nenhum deles se sente como a melhor resposta. Existe uma maneira melhor de lidar com isso?

Publicado 04/08/2008 em 18:46
fonte usuário
Em outras línguas...                            


5 respostas

votos
10

Concordo com John Downey.

Pessoalmente, eu às vezes uso uma enumeração sinalizado de permissões. Desta forma, você pode usar AND, OR, NOT e operações XOR em itens da enumeração.

"[Flags]
public enum Permission
{
    VIEWUSERS = 1, // 2^0 // 0000 0001
    EDITUSERS = 2, // 2^1 // 0000 0010
    VIEWPRODUCTS = 4, // 2^2 // 0000 0100
    EDITPRODUCTS = 8, // 2^3 // 0000 1000
    VIEWCLIENTS = 16, // 2^4 // 0001 0000
    EDITCLIENTS = 32, // 2^5 // 0010 0000
    DELETECLIENTS = 64, // 2^6 // 0100 0000
}"

Depois, você pode combinar várias permissões usando o operador AND bit a bit.

Por exemplo, se um usuário pode visualizar e editar usuários, o resultado binário da operação é 0000 0011 que convertido em decimal é 3.
Você pode então armazenar a permissão de um usuário em uma única coluna do banco de dados (no nosso caso seria ser 3).

Dentro de seu aplicativo, você só precisa de mais uma operação bit a bit (OR) para verificar se um usuário tem uma permissão especial ou não.

Respondeu 04/08/2008 em 19:23
fonte usuário

votos
10

A maneira que eu normalmente ir sobre sistemas de permissão de codificação é ter 6 mesas.

  • Usuários - este é bastante simples é a sua tabela de usuários típicos
  • Grupos - isso seria sinónimo de seus departamentos
  • Roles - esta é uma tabela com todas as permissões geralmente incluindo também um nome legível e uma descrição
  • Users_have_Groups - esta é uma tabela do que grupos many-to-many um usuário pertence
  • Users_have_Roles - outra mesa de quais os papéis que são atribuídos a um usuário individual many-to-many
  • Groups_have_Roles - a mesa final do que papéis cada grupo tem muitos-para-muitos

No início de uma sessão de usuários que você iria correr alguma lógica que puxa para fora todos os papéis que eles têm atribuído, seja diretório ou através de um grupo. Então você codificar contra esses papéis como suas permissões de segurança.

Como eu disse isso é o que eu normalmente fazer, mas o seu millage podem variar.

Respondeu 04/08/2008 em 18:56
fonte usuário

votos
2

Honestamente, o Membership ASP.NET / Roles características iria funcionar perfeitamente para o cenário que você descreveu. Escrever suas próprias tabelas / procs / classes é um ótimo exercício e você pode obter muito bom controle sobre detalhes minuciosos, mas depois de fazer isso eu mesmo cheguei à conclusão que é melhor usar apenas o construído em material .NET. Um monte de código existente é projetado para trabalhar em torno dele que é bom no poço. Escrever a partir do zero me levou cerca de 2 semanas e foi não onde perto tão robusto como .NETs. Você tem que codificar tanta porcaria (recuperação de senha, bloqueio automático, criptografia, papéis, uma interface de permissão, toneladas de procs, etc) e o tempo poderia ser melhor gasto em outro lugar.

Desculpe se eu não responder à sua pergunta, eu sou como o cara que diz para aprender c # quando alguém faz uma pergunta vb.

Respondeu 07/08/2008 em 03:23
fonte usuário

votos
2

Além das soluções de jdecuyper John Downey e, eu também acrescentou uma "negação explícita" pouco no final / início do bitfield, de modo que você pode executar permissões aditivos por grupo, associação de função, e em seguida, subtrair permissões baseadas em negação explícita entradas, bem como NTFS funciona, permissão-wise.

Respondeu 04/08/2008 em 19:39
fonte usuário

votos
0

Uma abordagem que eu usei em várias aplicações é ter uma classe PermissionToken genérico que tem uma propriedade de valor mutável. Em seguida, você consulta a aplicação solicitada, diz-lhe que PermissionTokens são necessários, a fim de usá-lo.

Por exemplo, o aplicativo de envio pode dizer-lhe que ele precisa:

new PermissionToken()
{
    Target = PermissionTokenTarget.Application,
    Action = PermissionTokenAction.View,
    Value = "ShippingApp"
};

Isso pode, obviamente, ser estendido para criar, editar, apagar, etc, e, por causa da propriedade Value costume, qualquer aplicativo, módulo ou widget pode definir suas próprias permissões necessárias. YMMV, mas esta sempre foi um método eficiente para mim que eu encontrei para dimensionar bem.

Respondeu 04/08/2008 em 19:03
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more