Estrutura dos Controllers em relação a autorização de usuários

[Everton Zamignan Pabon]

Olá pessoal, boa tarde.

Estou trabalhando num sistema onde em meu escopo de autorização os usuários podem assumir os seguintes papeis: "Administrador" ou "Normal". (haverá mais papeis futuramente).

Pelo perfil do sistema, as páginas (leia-se views) são praticamente iguais tanto para o Administrador como para o usuário Normal. 

Geralmente o Administrador tem apenas um ou dois botões a mais na View então eu uso a mesma View para ambos, exceto quando essa View for muito diferente/complexa.

Acontece que a todo momento as Actions tem que ficar decidindo o que fazer de acordo com o papel do usuário.

Essa minha introdução é pra perguntar se essa forma de trabalhar está correta ou 

eu devo criar Actions e Views (e até Controllers) distintas de acordo com a papel, não importando o fato de serem bem semelhantes.

Agradeço qualquer opinião.  

[Douglas J.A.M]

Acho eu que se a diferença é bem pequena, não custa nada apenas um if na view, isso até sobrecarregará menos o sistema.

Porém apenas ocultar o botão não impede de um hacking, lembre-se de tratar na action que processa tal url também tal permissão.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para kohan...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para kohana-php+...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/kohana-php?hl=pt-BR.

[Kaléu Caminha]

Uma opção que usei em casos semelhantes é a seguinte:

- Classe Abstrata User

- Classe Concreta User1

- Classe Concreta User2

Na abstrata ficam métodos que trazem dados dos pontos de flexibilização do sistema.

Ex: 

Classe Abstrata

- getButtons(): mixed

a view receberia um objeto da classe User e chamaria o método getButtons para pegar os botóes necessários.

Desvantagens:

- Trabalho inicial um pouco maior

- Risco da classe ter muitos métodos com o tempo (mas ainda acho melhor do que o código ter muitos ifs, e além do mais, a classe pode ser subdivida posteriormente) 

Vantagens:

- Adicionar novos tipos de usuários vai ser batata.!!!

- Você sempre sabe onde modificar dados específicos de um usuário.

- É ótimo se existem dados dependentes do usuário em mais de um lugar pois a sua arquitetura já está pronta para receber os métodos.

Conclusão

Usamos na Meritt essa estratégia para apresentar páginas muito semelhantes, mas para diferentes localidades. E queríamos um jeito de poder adicionar novos tipos de localidades no futuro e tenho gostado bastante do resultado.

[felipe bastos]

Vc criou um esquema usuario x grupo_usuario x permissao?

Inicialmente, eu faria diretorios diferentes... controller/ e controller/admin

E views diferentes ... views/ e views/admin

E criaria o diretorio classes/filter e criaria filtros de permissao a serem verificados na view, de acordo com o escopo da applicacao ..

Filter::factory("admin")-as_permission("permissao");

Se for uma verificacao mais complexa

as_permission_and_is_owner("permissao", $object);

E assim por diante.

Se for o caso .. criar o diretorio classes/view e criar um objeto view personalizado para aquela view

View_Product_Index extends View

Colocar alguns metodos .. e executar o metodo na view html

[Everton Zamignan Pabon]

O assunto é interessante.. percebo que cada um está tratando da forma que lhe convém melhor. 

Evito ao máximo if's na view então geralmente quando trata-se da mesma view faço algo assim na action:

if($usuario->permissao == 'Administrador')

$dados = ORM::factory('pedidos')->todos();

else

$dados = ORM::factory('pedidos')->porCliente($usuario->id);

$view = View:factory('pedidos')->bind('dados', $dados); 

[Kaléu Caminha]

Também não gosto de ifs para problemas que envolvem tipos (tipos de usuário, tipos de produtos, tipos de localidades) porque vou precisar alterar em muitos lugares diferentes se adicionar um tipo novo.

E acho que o mesmo problema se repete nas views. 

Se além do Admin e do user passarmos a ter um editor, terá que ser feita uma nova view para cada.

E por fim, eu acho bem chato ter mais de um ponto de alteração de código, algo que me parece inevitável trabalhando com duas views diferentes para coisas semelhantes.

A POO serve para resolvermos problemas que envolvem tipos.

--

Você está recebendo esta mensagem porque se inscreveu no grupo "Kohana Php" dos Grupos do Google.

Para ver esta discussão na web, acesse https://groups.google.com/d/msg/kohana-php/-/hLZC2HATerQJ.

[Jean O. Rodrigues]

Para as views gosto muito em cascata:

Ex.

views/admin/_default/menu.php

views/admin/_default/header.php

views/admin/regra1/header.php

views/admin/regra2/header.php

Onde caso não exista a views para a regra do usuário atual, busca uma view padrão na pasta _default

Enviado via iPhone