here

Vamos começar a organizar uma lista de pendências (TO DO List) do Mentawai.

Uma primeira demanda que tenho é o suporte a tag html TEXTAREA, já estou analisando o código para verificar como seria possível adicionar essa funcionalidade. Porém ainda não consegui mapear todas as questões que precisam ser tratadas.
Uma primeira dúvida que tenho é porque na classe Input existem estas duas linhas:
if (value != null) sb.append(" value=\"").append(value).append("\"");
else if (this.value != null) sb.append(" value=\"").append(this.value).append("\"");
Elas não são redundantes?
Essa nova tag deverá ser do tipo <mtw:textarea></mtw:textarea> ou <mtw:textarea />?

Outra questão conforme, conversado na última reunião do RioJUG, seria a criação de uma conceito de Autorização além da atual Autenticação. A minha sugestão seria a adição na tag <mtw:requiresAuthentication /> de um atributo onde fosse passado uma “chave”, a criação de um filtro que também tive essa “chave” como parâmetro, então no framework teria uma interface disponível para implementação que receberia o Objeto armazenado pelo setUserSession() e essa “chave” e este deveria retornar sucesso ou erro, caso o usuário tivesse a devida autorização (permissão) ou não, respectivamente.

Para começar a lista de pendências, são essas as minhas sugestões. Vamos completá-la, alterá-la e priorizá-la.

TO DO List
----------
- Tag para suporte a TEXTAREA
- Suporte a Autorização

Foi falado aqui no forum também (se eu não me engano foi vc mesmo) falando sobre o HIDDEN. Já foi implementado? Caso contrário é legal colocar no TO DO List.

Andre wrote:

Code:

 if (value != null) sb.append(" value=\"").append(value).append("\""); 
 else if (this.value != null) sb.append(" value=\"").append(this.value).append("\"");

Repare que this.value não é igual a value. Basicamente essa linha de código te permite setar um valor padrão na tag através do atributo value. Mas ele só é usado se não há outro valor para ser mostrado.

Falando agora de TextArea:

Deve ser uma tag com body, já que vc pode querer passar algum text default ali dentro. Entretanto nada te impede de usar ela sem body <mtw:textarea />, pois ela sempre vai cuspir a versão certa, ou seja, com corpo.

Eu já tenho algo mais ou menos pronto aqui para a TextArea e posso te mostrar para a gente trocar uma idéias.

Quanto a autorização acho que sua idéia é muito boa. Eu pensei como vc num esquema de ROLES, ou seja, vc cria roles como admin, guest, manager, etc

Daí quando vc coloca o cara na sessão, vc tem que indicar qual é o role dele. Talvez setá-lo com uma função setUserRole(String role) e aí a tag requiresAuthentication poderia ter um atributo roles="admin, manager" onde vc indicaria quem pode entrar ali.

E tb precisariamos de um filtro para checar os roles durante o acesso a action.

Vale pensar se esses Roles seriam simples strings ou algo hierarquizado. Acho que strings fica mais claro e simples o que acha?

Já foi implementado, está no CVS.

Glaucio wrote:

Foi falado aqui no forum também (se eu não me engano foi vc mesmo) falando sobre o HIDDEN. Já foi implementado? Caso contrário é legal colocar no TO DO List.

Já foi !!! Entra na versão 1.1 que vai ser lançada ainda essa semana.

A versão 1.1 está bem legal, principalmente com o suporte a IoC bem simples. Claro que isso só vai usar quem quiser e precisar. Quem não quiser pode ignorar sem problemas.

Interessante esse lance de Role.

Então utilizando string seria:<mtw:requiresAuthentication role="Admin" /> ??

Colquei no CVS o TextArea.java, que é o tag do TEXTAREA.

Não testei!!! Dá uma olhada André e veja se te agrada.

Vou almoçar agora...

Modifiquei tb o taglib.tld.

Segue em anexo...

Reparem que eu tive que modificar tb o PrintTag !!! (Logo não vai compilar se vc apenas jogar o TextArea.java no seu projeto)

Entendi o porque do IF, a preferência é que a tag traga o valor atual.

Acredito que a utilização de Roles seja uma boa idéia. Não acredito que precise em algo hierarquizado, poderiam sim, serem utilizadas Strings. Da forma que sugeri, novos Roles ou Chaves seriam criadas sob demanda.

Não sei se é uma boa colocar as Roles do usuário na seção, caso o sistema fosse mais complexo o usuário poderia ter diversos Roles.

Um prática que adoto para controle de autorização em sistemas Web, é a criação de 3 entidades Usuário, Grupo e Permissão, com relacionamento NxN entre Usuário e Grupo; e também Grupo e Permissão. Para cada nova funcionalidade (por exemplo: página JSP) que implemento coloco no inicio da página a chamada a uma função que recebe a identificação da permissão necessária para acessá-la e a identificação do usuário atualmente logado. E a função verifica se o usuário está associado a algum grupo, que por sua vez está relacionado à permissão.

Como isso, há uma flexibilidade muito grande. E único suporte que o framework precisaria prestar é associar a cada funcionalidade um ID de permissão.

E fica a cargo do desenvolvedor criar, assim como eu, essa entidade Grupo ou não, criar outras entidades como sub-grupos para um controle de permissão mais complexo, utilizar grupos hierarquizados. As possibilidades são ilimitadas e o suporte do framework o mesmo.

Espero ter sido claro, se não, estou a disposição para explicações.

Fala André,

Estou acabando aqui. Para ter certeza que eu entendi a sua idéia, me dá alguns exemplos de grupos e permissões.

Grupos seriam: Managers, Users, Administrators, etc

E permissões seriam: modify, read, delete, etc

É isso ????????

Daí teríamos:

<mtw:requiresAuthentication permission="delete" />

É isso ???

Não entendi muito bem pra que que serve a permissão ???

Esse conceito é bem abrangente mesmo. Lembrando que os Grupos não seriam responsabilidade do Mentawai, apenas as permissões. Talvez estejamos falando quase a mesma coisa.

Alguns exemplos:

Grupos: Administrador, Imprensa.
Permissões: Administrar Usuários, Administrar Produtos e Administrar Notícias.
Onde o grupo Administrador teria todas as permissões e o grupo Imprensa somente de Administrar Notícias.
É claro que as “chaves” das permissões seriam adm_usr, adm_prod e adm_not; ou ainda usrs, produtos e notícias; e em último caso 1, 2 e 3.
E mais, nesse caso, todas as funcionalidades relativas a Notícias, por exemplo, teriam a mesma identificação de permissão.

Grupos: Gestores e Usuários
Permissões: incluir matérias, alterar matérias, excluir matérias
Onde os Gestores teriam as 3 permissões, mas os usuários comuns apenas direito de inclusão.

Grupos: Cliente X e Cliente Y
Permissões: Dados Financeiros do cliente X (financ_x), Dados financeiros do cliente Y (financ_y)

Aproveito aqui para adicionar mais uma consideração, também seria necessária a adição de um tag como <mtw:hasAutorization key=”xxx”></mtw:hasAutorization>, onde os dados só seriam apresentados para os usuários que tivessem essas permissão, ele deveria ser usado para envolver, por exemplo, um link para acessar uma página que é restrita a usuários com direto a permissão: xxx.

Vou tentar redigir com mais calma uma descrição completa, de como seria a para um usuário que utilizasse o Mentawai, essa parte de Autorização.

Acho que já entendi tudo André !!!!

Por ser N por N vc pode autorizar tanto por Grupo quanto por permissão. De um lado ou de outro.

A tag que vc falou faz todo o sentido...

Estou acabando aqui...

Tags:

<mtw:requiresAuthentication groups="admins, managers" />
<mtw:requiresAuthentication permission="delete, read" />

<mtw:hasAuthorization groups="admins" />
<mtw:hasAuthorization permission="delete" />

As TAGs seriam essas mesmas. Porém não ficou claro para mim, se essas roles e permissions ficariam armazenadas na session. Se não, de que forma a verificação seria feita.

Quanto ao TEXTAREA, já coloquei aqui, e aparentemente está tudo certo. Só tenho uma pequena consideração. Como o campo pode ser longo, talvez fosse interessante já iniciar o StringBuffer interno da classe com uma capacidade maior que 200, talvez 2000, ou até 20000.

Estou terminando o org.mentawai.authorization.Group e o org.mentawai.authorization.GroupManager.

O GroupManager vai ficar no escope da applicação (ApplicationContext) e vai ser acessado pelas tags e filtros.

Acho que vai ficar legal...

Vc vai configurar os Groups/Permissões no ApplicationManager.java. Nada te impede depois de fazer algo para puxar isso do banco ou de um arquivo. Não vejo muito problema em manter hardcoded ali no ApplicationManager, mas fica a critério do projeto em questao.

Quanto ao TextArea vou alterar !!! Boa observação...

Na verdade acho que os tags devem ser separados do tag de autenticação, para não confundir as bolas.

Code:

 
 <mtw:requiresAuthorization groups="admins, managers" />
 
 <mtw:requiresAuthorization permissions="delete, read" />
 
 <!-- Nao faz muito sentido, mas se o cara quiser ele vai checar por ambas as condições (AND) -->
 <mtw:requiresAuthorization groups"admins" permissions="read" />
 
 <mtw:isAuthorized groups="admins, manager">
 </mtw:isAuthorized>
 
 <mtw:isAuthorized permissions="read, write">
 </mtw:isAuthorized>
 
 <!-- Nao faz muito sentido, mas se o cara quiser ele vai checar por ambas as condições (AND) -->
 <mtw:isAuthorized permissions="read, write"  groups="admins, manager">
 </mtw:isAuthorized>

Acho que as TAGs seriam estas mesmas, porém agora eu fiquei na dúvida. Para vocês qual seria a diferença entre groups e permissions?

Ainda não está claro que tipo de configuração seria feita no ApplicationManager, mas vou aguardar você terminar essa nova funcionalidade para analisar melhor.

Forum Read-Only! Check the new site and forum here!