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

Luis Motta Campos luismottacampos em yahoo.co.uk
Quarta Junho 11 03:22:49 PDT 2008


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.

> 2. Fields, arquivo de configuração é uma coisa, repositório de 
> usuários é outra. É muito mais esquema no arquivo de configuração 
> você indicar o(s) tipo(s) de repositório(s)(*vide próximo item) que 
> você vai usar, e no caso do UserList, indicar o arquivo que contém a 
> lista. Particularmente útil para você poder dar permissão read para a
>  config, mas root-only para informação sensitiva.

Se você está falando do Net::Squid::Auth::Plugin::UserList, lembre-se de
que isso é o plugin de exemplo. É mais para eu consegui rodar testes do
que para colocar em produção.

Isto está documentado de acordo, apenas não está ESCRITO EM MAIÚSCULAS E
PISCANDO. ;)

> 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. ;)

> 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}


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