Latest posts for the topic "Lista de Pendências"

Lista de Pendências

andredelorme — GMT

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 ou ? 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 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

Re:Lista de Pendências

Glaucio — GMT

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.

Re:Lista de Pendências

saoj — GMT

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 , 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?

Re:Lista de Pendências

andredelorme — GMT

Já foi implementado, está no CVS.

Re:Lista de Pendências

saoj — GMT

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.

Re:Lista de Pendências

Glaucio — GMT

Interessante esse lance de Role. Então utilizando string seria: ??

Re:Lista de Pendências

saoj — GMT

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)

Re:Lista de Pendências

andredelorme — GMT

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.

Re:Lista de Pendências

saoj — GMT

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: É isso ??? Não entendi muito bem pra que que serve a permissão ???

Re:Lista de Pendências

andredelorme — GMT

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 , 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.

Re:Lista de Pendências

saoj — GMT

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:

Re:Lista de Pendências

andredelorme — GMT

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.

Re:Lista de Pendências

saoj — GMT

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

Re:Lista de Pendências

saoj — GMT

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

Re:Lista de Pendências

andredelorme — GMT

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.

Re:Lista de Pendências

saoj — GMT

Groups = Roles = Admins, Managers, Users, etc Permissions = Permissõe = Deletar usuários, deletar notícias, ler notícias, etc. Como deveria ser se não assim ?

Re:Lista de Pendências

andredelorme — GMT

Entendi, então você acabou colocando todo o esquema que eu utilizo. Em cada funcionalidade da aplicação eu poderei colocar quais os Grupos e/ou permissões que o usuário precisa ter para acessar, certo? E eu terei que colocar na session que grupos e permissões o usuário possui. O porém disso é que, assim como o Tomcat registrarei no próprio framework os usuários, grupos e permissões. Como você pensa num futuro que um sistema possa ter um BD para controle de permições ou até utilizar sistemas mais complexos como LDAP? Detalhando minha idéia inicial pensei em algo como, registrar no aplicação uma classe para controle de autorização, por exemplo: registerAuthorizationManager(new AuthorizationManager()); Esta classe teria um método como: boolean checkAuthrization(Object user, Object key) O framework a cada vez que as TAGs ou fossem utilizados, ou ainda adicionado a uma Action um filtro como: ac.addFilter(new AuthorizationFilter(key)); O método checkAuthorization da classe AuthorizationManager seria chamado para verificar a autorização da usuário. A complexidade do esquema de autorização ficaria a cargo do desenvolvedor, a implementação padrão do framework seria simples como: return true; Num segundo momento outras classes poderiam ser criadas para incorporar no framework. O que você acha, Sergio? Entendeu?

Re:Lista de Pendências

saoj — GMT

Entendi e vc descreveu exatamente o que eu fiz. A class GroupManager será registrada no ApplicationContext. (Para evitar singleton que o pessoal hoje em dia condena...) Os groups e permissões serão inicialmente configurados na mão, mas nada te impede de estender GroupManager para que ele pegue isso do DB ou de outro lugar qualquer. Vc só precisa colocar os Grupos a que aquele usuários pertence na session, e não as permissões. Grupos contem permissões, logo vc não adiciona permissões a um usuário e sim adiciona o usuário a grupos. Certo ??? Entendi ??? Estou anexando as classes para vc ver... Ainda falta fazer as tags e os filtros...

Re:Lista de Pendências

saoj — GMT

http://mentaforum.lohis.com.br/posts/list/26.page