[SP-pm] [Announce]: Net::Squid::Auth::Engine & Net::Squid::Auth::Plugin::UserLis

André Garcia Carneiro andre.garcia.carneir em terra.com.br
Quarta Junho 11 04:38:41 PDT 2008


---------- Cabeçalho original -----------

De: saopaulo-pm-bounces+andre.garcia.carneir=terra.com.br em pm.org
Para: saopaulo-pm em mail.pm.org
Cópia: 
Data: Wed, 11 Jun 2008 12:22:49 +0200
Assunto: Re: [SP-pm] [Announce]: Net::Squid::Auth::Engine & Net::Squid::Auth::Plugin::UserLis

> Alexei Znamensky wrote:
> > Algumas considerações notívagas sobre o módulo:
> > 
> > 1. O tal do Catalyst tem uma bojuda lista de módulos de autenticação,
> >  é só procurar "authentication" que vem. Se der para usar os módulos 
> > deles sem muita dor de cabeça, estamos reinventando a roda
> 
> Hum, eu nem mesmo pensei nisso. Você pode ter razão. Mas isso quer dizer
> que eu tenho de carregar a infra-estrutura pesada do Catalyst para onde
> eu instalar esta coisa... não sei até que ponto um sysadmin quer lidar
> com aquele "monstrinho" para ter uma coisa mais simples. De qualquer
> forma, eu vou olhar para isso com cuidado na próxima interação.
> 

Estamos migrando algumas aplicações para Catalyst aqui onde eu trabalho. E posso dizer por experiência
própria(pois não temos um sysadmin 'formal'), que a facilidade na manutenção e a produtividade que o Catalyst
proporciona compensa esses detalhes. 

 
> > 3. Não necessariamente algo a se fazer agora, mas que poderia ser 
> > interssante no futuro, seria o conceito de "federar" repositórios: na
> >  configuração, especifica-se vários repositórios diferentes, e usa-se
> >  todos ao mesmo tempo. Claro, isso requer tomar mais algumas
> > decisões, mas, por exemplo, pode ser útil para prover um repositório
> > de usuários local (arquivo texto) e um remoto (LDAP?) ao mesmo tempo.
> > Se o LDAP/whatever estiver fora do ar, ainda temos alguns usuários 
> > locais que estarão acessíveis para usarmos de fail-over.
> 
> Eu adotei uma arquitetura de plugins para o sistema. Assim, quando
> houver um plugin de LDAP e outro de banco de dados, podemos construir um
> plugin "federado", que sabe instanciar outros plugins e procurar um
> usuário nestes. Não é complicado de fazer.
> 
> > 4. Me parece que o ideal seria fazer com que o hash de user/pw fosse
> >  "tied". Tied com o arquivo texto local (ha, mais um motivo para 
> > separar a config do repositorio de usuarios), tied com o LDAP, tied 
> > com XPTO, whatever.
> 
> Hum. Eu não gosto de tie-interfaces, o tratamento de erros não é muito
> óbvio, muita gente acha que uma atribuição para um valor num hash é uma
> operação livre de erros.
> 
> O problema é que numa base de dados representada por um tied-hash,
> falhas na base vão causar erros de leitura.
> 
> Quer dizer, isso:
> 
>     $value = $database_hash{'key'};
> 
> pode falhar, e deveria estar dentro de um eval():
> 
>     $value = eval { $database_hash{'key'}; };
>     die $@ if $@;
> 
> a mesma coisa pode acontecer com uma atribuição:
> 
>   $database_hash{'key'} = $value;
> 
> que também deveria estar dentro de um eval():
> 
>   eval { $database_hash{'key'} = $value; };
>   die $@ if $@;
> 
> Nem tão óbvio ou fácil de manter, mas eu sou ranzinza. ;)
> 

Não rola fazer  isso? 
<code>
use strict;
use Error;
my $value = undef.;

try{
       $value = $database_hash{'key'};
}
catch MinhaClasseTratError with  {
      my $exception = shift;
      #trate sua exceção aqui
};

package MinhaClasseTratError;
#Metodos aqui...

</code>

ou mesmo

<code>
use strict;
use Error;

my $value = undef;
eval{ $value = $database_hash{'key'};
throw MinhaClasseTratError -text =>'mensagem aqui'  if $@;

package MinhaClasseTratError;
#Metodos aqui...


</code>



> > 5. Eu prevejo uma necessidade futura de ter um outro componente 
> > plugável nesse framework, um que vá manipular a senha recebida para 
> > checagem. Por exemplo, no LDAP, é comum a senha fica disponível para 
> > consulta apenas como um hash (como no arquivo /etc/shadow no Linux), 
> > ou seja, comparar a senha em clear-text com o hash vai dar errado. 
> > Assim, teríamos de ter, para cada repositório, um "provider" de 
> > manipulacao da senha. Alguns exemplos prováveis: cleartext, MD5, 
> > SHA1, smokesigns, MORSE.
> 
> Isso é responsabilidade do plugin, Alexei. Deve fazer parte da
> implementação do método Net::Squid::Auth::Plugin::*::is_valid(). RTFM,
> meu caro... ;) é a única coisa que eu garanto que está correta, por agora.
> 
> > 6. Pensar nisso me leva a crer que o ideal seria fazer um framework 
> > de autenticação, flexível e extensível, do qual o 
> > Net::Squid::Auth::Engine - mas aí não somente ele - poderia se 
> > utilizar.
> 
> Isso pode ser interessante. Mas tem de englobar coisas mais complicadas,
>  como interfaces para o Open Authentication (www.openauthentication.org)
> e Bit Card (www.bitcard.org - Authen::BitCard), por exemplo. Uma
> proposta de arquitetura, por favor?
> 
> > 7. Eu já mencionei que o Catalyst parece ter uma solução bem 
> > abrangente? :-) Não, não li os docs nem vou fazer isso neste exato 
> > momento(!).
> 
> Você está falando da minha documentação, ou da documentação do Catalyst?
> Algum especialista de Catalyst da lista pode por favor postar uma
> declaração dizendo que os Models do Catalyst estão amarrados (como todo
> bom MVC) ao uso dos Views e do Controller correspondente? (Obrigado
> adiantado).
> 
> > Mas vou guardar isso no TO-DO list. Se essa parte de autenticação 
> > deles não estiver amarrada com o uso do Catalyst em si, parece algo 
> > interessante.
> 
> Eu tenho quase certeza de que você não pode fazer muito para usar a
> parte de autenticação de um MVC (que deve ser um /model/ ou um
> /controller/ dentro do sistema) sem o resto dele... mas eu posso estar
> enganado. Alguém pode por favor me confirmar isso? Eden, cadê você?
> 
> > Tudo que será necessário depois é fazer uma camada de interface entre
> > o Net::Squid::Auth::Engine e as classes deles. Muito "if" e pouco
> > código, yeah, eu sei.
> 
> A gente pode usar um /dispatch/ /table/, também ;)
> 
> > Chega, vou tirar uma soneca.
> 
> Obrigado pelas críticas, eu vou aproveitar algumas coisas daqui. ;)
> Putamplexos.
> -- 
> Luis Motta Campos (a.k.a. Monsieur Champs) is a software engineer,
> Perl fanatic evangelist, and amateur {cook, photographer}
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
> 

--
André Garcia Carneiro
Developer(Perl/PHP)
Member of "São Paulo Perl Mongers" - http://sao-paulo.pm.org



Mais detalhes sobre a lista de discussão SaoPaulo-pm