> 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.comUIN: 343716195
Jabber:
everton...@jabber.org"If art interprets our dreams, the computer executes them in the guise of programs!" - Alan J. Perlis