Sistemas de autenticação - Talvez em debate...

0 views
Skip to first unread message

Pedro Fernandes Steimbruch

unread,
Mar 14, 2009, 12:13:23 AM3/14/09
to rail...@googlegroups.com
Boa noite,

Eu li a pouco um e-mail de alguma pessoa da comunidade. Infelizmente não me recordo ao certo o nome do mesmo.
No e-mail ele comenta que, assim como eu, está recém começando a desenvolver em Rails e questiona sobre um bom sistema de autenticação.

Eu gostaria de saber se é de valia o uso destes plugins ou se vocês, mais experientes, costumam desenvolver algo próprio de acordo com a situação. Porém caso usem algo pronto, poderiam, talvez, comentar um pouco sobre... vantagens e afins. ;)

[]'s Pedro F. S.

Davis Zanetti Cabral

unread,
Mar 14, 2009, 11:15:26 AM3/14/09
to rail...@googlegroups.com
Rapaz,

Eu estou usando o Authlogic com o Authorization num estudo com Rails
2.3.1 e estou achando muito bom. Achei ele mais simples e de fácil
compreensão do que o restful_authentication.
Ele só não tem um generator ainda, que facilite todo seu trabalho, mas
tem um tutorial e um projeto exemplo com seu uso que é muito bacana.

O autor só não é lá muito humilde hehe! Mas o cara manda super bem,
código muito conciso!

Abraço!

--Davis

Everton J. Carpes

unread,
Mar 17, 2009, 2:21:40 AM3/17/09
to rail...@googlegroups.com
Ola...
 
> Eu gostaria de saber se é de valia o uso destes plugins
 
Sinceramente considero praticos. Especificamente quanto a authenticacao, a solucao tende a ser simples, em geral pq a maioria das propostas nao eh mais do que um gerador e nao um plugin propriamente (diferencio, pq mesmo alguns sendo encapsulados como "plugins" nao obtem a maioria das vantagens agregadas a plugins, como possibilidade de atualizacao flexivel, etc).

Apesar desta caracteristcia/deficiencia, as solucoes que tem por aih foram amplamente testadas em ambientes de producao e a maioria oferece uma quantidade de testes automatizados com uma solida cobertura.

Uma critica que pode-se fazer eh que a maioria dos plugins limita-se a solucoes tradicionais, baseadas em modelos AR, conectando-se a base de dados da APP. A maioria das solucoes nao foi pensada de forma generica, para abarcar por exemplo uma authenticacao num LDAP, etc

Outro ponto complicado a ser questionado mas que acho importante eh frisar q a maioria das solucoes sao "covardes" em suas abordagens, fazem uma ampla discucao de que authenticacao nao tem nada a ver com controle de acesso e pregam que devemos nos limitar a manter as coisas completamente desacopladas.. Portanto nao espere nada de controle de acesso direto atraves de um destes plugins e qualquer que seja a camada de controle de acesso que pretendes acrescentar, te prepares para hackear o que os plugins oferecem.


> se vocês, mais experientes, costumam desenvolver algo próprio de acordo com a
> situação.

Eu normalmente uso o restful_authentication (e no passado seu antecessor que ateh jah esqueci o nome, hehe), como ponto de partida... o plugin eh absolutamente inutil depois que tu usou ele como esqueleto, mas para isso ele te soluciona o problema de forma pratica, entao serve bem a seu proposito.

A muito tempo eu tenho isolado e testado possibilidades diferentes quanto a authenticacao somado a controle de acesso. Com esses testes, tenho adquirido uma boa experiencia nesta area, e uma das "batalhas" que tenho considerado como concluidas eh a do desacoplar o controle de acesso da authenticacao. Na pratica isso eh uma falacia.. SE tu precisar de um sistema de controle de acesso solido, ele SERAH altamente acoplado tanto ao teu sistema de authenticacao (que - podem me malhar por isso - mas EH SIM UM MECANISMO DE CONTROLE DE ACESSO), quanto a outras partes da tua app. Alem disso este tipo de questao eh super integrada com a propria solucao da aplicacao que estas desenvolvendo. Generalizar as situacoes eh algo complicado e gracas a isso jamais tivemos "solucoes derradeiras" para ambos os problemas... alias, isso se aplicaca a tudo.

Muitas vezes vais sim precisar codar tudo, simplesmente pq o que tu esperas nao se encaixa exatamente no padrao seguido pela maioria. Em grande parte dos casos, vais poder pelomenos usar um plugin como ponto de partida.

Soh existe um ponto que eh regra geral: NUNCA aceite um plugin, componente, whatever apenas por sua popularidade... Leia todos os codigos do plugin, analise com calma cada teste que o mesmo tenha e verifique se a cobertura de testes dele eh conssistente! Verifiquei pq o author construiu o plugin e nao se deixe influenciar pelo mesmo. As vezes um plugin resolve bem um problema, isso nao quer dizer que ele resolverah sempre! Analise e absorva o melhor de cada plugin... Mesmo nao utilizando um plugin, ele ainda assim serve como referencia para (por exemplo), voce aprender possibilidades de melhorias na sua codificacao, isolamento de solucoes e as vezes do que NAO deve ser feito.

Em todos os casos, escolher se usa ou nao o plugin depende de pra que. O caso da authenticacao eh possivelmente o mais obvio e expressivo destes casos, jah que raramente dois sistemas tem as mesmas caracteristicas de controle de acesso.

A alguns meses o Zed palestrou sobre controle de acesso, ele questionou a possibilidade de conceitos como RBAC baseados em listas, em relacionamentos simples, etc. As criticas dele sao super pertinentes, uma vez que na maioria das vezes NAO temos regras simples de acesso, muitas vezes precisamos de regras que sao cheias de excecoes (a action de signup eh aberta, o pagina de login tambem, mas se tu precisar de um sistema de recuperacao de senha tambem terahs que abrir: o que temos aqui? um padrao! Toda action que te permite criar uma conta ou restabelecer seu estado deve ser aberta.. patindo desta logica, comecamos a categorizar actions, e por aih se segue). Segundo o Zed observa, nao deveriamos tentar contornar isso com solucoes simplistas, o problema em questao deve abarcar micro-linguagens (MSLs, DLSs, etc), ou talvez linguagens completas somente para esta tarefa, e o proprio Ruby provavelmente seja uma linguagem muito expressiva, a ponto de ser uma excelente alternativa ao controle de acesso mais complexo.

O ponto eh que, este tipo de controle eh complicado, reflete muito da natureza da tua aplicacao (e consequentemente do programador). Nao eh possivel ditarmos regras genericas.. Use plugins se te convier, mas nao se prenda a eles... criar uma solucao inteira tua eh facil, inclusive podes criar algo que se torne um futuro plugin, acredite, o processo eh super simples!

Controle de acesso /  authenticacao sao dois* problemas  que serao chaves para tua aplicacao: identificar quem esta vendo o que e deifinir quem ve ou nao cada coisa, quem vai a cada lugar da aplicacao e entre outras coisas, definir se alguem deve ou nao ver ese ou aquele link, se pode ou nao acessar esta ou aquela action e dependendo da app, incluindo/excluindo acessos devido inclusive ao formato (html? xml? json?) de cada actin, tudo isso precisa ser definido, pensado, etc. Estas definicoes podem/devem influenciar da obvia seguranca da aplicacao ateh o tempo que tu deves gastar codificando, pois nao eh possivel ignorarmos que se tu precisar  existe um direto impacto causado por tu nao poder criar um link dentro da tua aplicacao sem tapar ele de IFs na volta testando se essa ou aquela role pode acessar (NAO, eu NAO FACO ISSO!).

Sei que nao fui muito conclusivo em minhas observacoes e prefiro assim, pois ser vago nesta area acho que eh o melhor que podemos... espero que tenham sido pertinentes as observacoes.


--
Everton J. Carpes                    
Mobile: +55 53 9129.4593
MSN:    mas...@gmail.com
UIN:    343716195
Jabber: everton...@jabber.org

"If art interprets our dreams, the computer executes them in the guise of programs!" - Alan J. Perlis

Pedro Fernandes Steimbruch

unread,
Mar 17, 2009, 8:33:08 AM3/17/09
to rail...@googlegroups.com
Gostei muito da tua resposta, vou até favoritar para ler novamente alguma outra hora.
Quando iniciei a thread era esse tipo de resposta que eu esperava, me levando a refletir e entender um pouco mais da realidade do uso deste tipo de plugin. Lógico que não vou me basear inteiramente na tua reposta (não por não ser "boa", pelo contrário, como já falei, gostei muito), mas por ter vários outros pontos de vista e tal.

Obrigado,

Pedro F. S.
Reply all
Reply to author
Forward
0 new messages