Utilizadores Vs Membros

Question

Este é mais como uma pergunta para um aconselhamento em vez de uma resposta precisa...

Na minha CakePHP app, vou ter de back-end usuários e frontend membros.Eles completamente diferentes funções e permissões (usuários são de aplicação gerentes, os membros são os visitantes que se registrar no site, sem qualquer acesso ao aplicativo de back-end).Devo usar tabelas diferentes para estes dois tipos de autorização, ou devo apenas gerenciá-los com um parâmetro de função e vincular tabelas para seus perfis dependendo dela, e por isso é uma solução melhor do que a outra?

Answer 1

Utilizar a mesma tabela e role ou type de campo.Você terá apenas um login e vai ser fácil para gerenciar as contas.

Use a ACL ou um sistema de permissão personalizados para permitir-lhes a diferentes controladores/ações.

Answer 2

Para permissões, eu tenho 3 maneiras de o fazer :

O estrito-papel maneira : Cada função do seu aplicativo tem acesso a funções com seu prefixo, mas não qualquer outro prefixo.

Ex : admin tem acesso a admin_edit, mas não customer_edit

Adicionar uma função varchar ou enum em seu users , a tabela de prefixos de roteamento no Config/core.php e você, permitir o acesso em um AppController::beforeFilter :cada função é permitido o acesso ao seu prefixo só.

A forma hierárquica: Sua aplicação os papéis de são ordenados de maneira hierárquica, onde a função tem acesso ao seu prefixo e todos os prefixos sob-lo.

Ex : admin tem acesso a admin_edit e customer_edit, mas cliente não tem acesso a admin_edit

Adicionar uma função varchar ou enum em seu users , a tabela de prefixos de roteamento no Config/core.php e você, permitir o acesso em um AppController::beforeFilter verificando para cada $this->request->params['prefix'] as funções que podem tem acesso a ele.

A maneira personalizada: Você precisa de seu administrador para acesso a algumas funções, mas não todos.Você precisa de outra função para acesso a algumas funções de administrador pode acessar, e algumas funções de administrador não é possível.

Ex : admin pode aceder a admin_edit e customer_edit, mas não customer_create ou user_stat. cliente pode ter acesso a customer_edit, customer_create e user_stat, mas não admin_edit ou user_edit

Use a ACL.Não é a maneira mais fácil para gerenciar permissões para o aplicativo, mas se você quiser permissões específicas, é a melhor forma.Então lembre-se disso : apenas use a ACL se você realmente precisa dele.

Answer 3

Eu concordo com Cornelb: apenas uma tabela.Aqui estão algumas razões adicionais:

• Se você adicionar restrições de chave estrangeira, pode ser confuso para fazê-los se referir à tabela de gerenciadores de aplicativos e na tabela de visitantes.Sempre quando você quiser apontar para um usuário, você precisaria de 2 campos, em vez de 1 (um campo apontando para a tabela de gerentes, e uma para a tabela de visitantes - e exatamente uma delas tem que ser nula).E se você precisar de dois campos de ID do usuário em uma linha, com chaves estrangeiras?Então você de repente precisa de 4 campos.Simper com todas as chaves apontando para apenas uma tabela (e o tipo de usuário decidido pelo campo acima mencionado).

• Às vezes, você pode querer que o ID do usuário seja parte de uma chave primária - mas isso é mais complicado, se você tiver dois campos de ID do usuário diferente, um em cada tabela.Porque então o banco de dados não pode garantir que cada ID do usuário seja exclusivo - você teria que fazer você mesmo no nível do aplicativo.