Magoo para web struts e assimilados
Marcelo Mrack
O Magoo é orientado para aplicações desktop (swing) e web baseadas
no JSF. Porém, como muita gente ainda insiste em criar sistemas web
com frameworks como o Struts, eu dei uma pensada em como suportar isso.
As idéias preliminares são as seguintes:
1. Queremos transparência, ou seja, aplicar o controle de acesso sem
que precisamos modificar o código existente do sistema ou, caso o
sistema esteja em construção, construí-lo sem pensar na existência
de um controle de acesso. Nada de códigos como "if (user in
("admin","owner") then { btnSalvar.setEnabled(true) } " ou coisas
similares...
2. Para permitir isso, meu raciocínio é mais ou menos assim: O magoo
está empacotado em um arquivo .jar, que é sua API, nada mais. Esse
.jar é adicionado ao classpath do sistema quando a aplicação inicia.
Se for uma aplicação enterprise, como um .ear, o magoo será
deployado dentro desse ear; se for uma aplicação light, como um .war,
o magoo é deployado dentro do classpath desse war; se for uma
aplicação standalone, o magoo é deployado no classpath da
aplicação e, via *premain* (sabem o que é isso?) ele é inicializado
no bootstrap da aplicação. Vamos supor que ele deve ser usado dentro
de um .war.
3. Quando é deployado no sistema, o magoo procura por classes de
interface de usuário no classloader do sistema. São as classes que
extendem JFrame, JDialog e coisas assim no Swing. Na web são as JSPs.
Localizando essas classes, ele varre, via reflexão, o conteúdo dessas
classes procurando por objetos que representam controles de tela, como
botões, caixas de texto, etc. recursivamente. Em aplicações desktop
é simples. Em aplicações web, precisamos de javascript, mais
precisamente ajax.
4. A necessidade do javascript é justamente por não usarmos o JSF na
web. Se usássemos JSF, seria simples utilizar uma das fases de
renderização do sistema, interceptá-la e adicionarmos as entradas de
controle de acesso. Como a idéia aqui é o suporte a coisas que não
são JSF, vou continuar.
5. Via ajax (ou javascript), o magoo varre a estrutura DOM do arquivo
HTML, procurando pelos elementos de interface. Encontrados todos os
controles da tela do usuário, seus IDs são enviados para o servidor.
O servidor então inicializa a base de controles e as permissões
iniciais (sejam elas permissivas ou restritivas). Nesse ponto, a base
de permissões está inicializada e o administrador do controle de
acesso pode ajustar as permissões a sua vontade.
6. Percebam que no passo anterior, não bloqueamos nada via javascript,
até mesmo porque isso não é seguro. Apenas usamos ele para
inicializar os elementos do sistema.
7. Eventualmete, alguns controles podem não ser inicializados na
primeira fase. Isso ocorre porque alguns deles podem não ter sido
renderizados ainda. Por exemplo, o controle txtSalario somente é
renderizado quando o campo chkEmpregado for marcado. Como esse campo
não foi marcado, o controle txtSalario não existe na página JSP e,
por isso, o magoo não conseguiu restringir ele. Dessa forma, é
necessário que o passo 5 seja continuamente repetido no sistema, e
monitore constantemente as alterações da página. Cada novo controle
que aparecer é enviado via javascript para a base do controle de
acesso. Esses controles podem ser macados lá com uma cor ou qualquer
coisa diferente que indique ao adminstrador que eles não estavam
presentes quando ele fez sua configuração inicial de permissões.
Nota-se que isso é um processo iterativo. Técnicas e padrões da
empresa podem definir o quanto esse processo deve estender.
8. Uma vez inicializada as permissões dos controles, o próximo passo
é aplicar as permissões. Isso deve ocorrer, sempre que possível, na
camada do servidor durante a renderização do controle. Quando se usam
taglibs para criar os controles, o que é o padrão em frameworks como
o Struts, esse trabalho é facilitado. O magoo entra em cena
interceptando as taglibs e aplicando as permissões. Isso é possível
porque, independente do tipo da taglib utilizada, ela segue um padrão:
ou implementa uma interface, ou estende uma classe ou baseia-se em
convenções de métodos. Para cada tipo de taglib, o magoo terá um
interceptador.
9. O interceptador do magoo é muito simples. Ele simplesmente
confronta a saída da taglib com o controle de acesso. Se a taglib
estiver renderizando algo que não é permitido, o magoo sobreescreve a
saída da taglib. Por exemplo, se a taglib tentar renderizar um
controle txtNome e o controle de acesso informar que txtNome é oculto
para o usuário atual, o magoo simplesmente aplica
txtNome.setVisible(false) para esse controle (desculpem, mas não sei
HTML e por isso não sei qual é o código equivalente).
10. Outra característica do Magoo é o foco na interface do usuário.
Assim, as restrições do magoo são simples: ou pode ver, ou pode
interatir. "pode ver" significa que o usuário verá ou não o controle
na tela. O "pode interagir" significa que o usuáriio irá ou não
alterar o conteúdo do controle (em um botão, é o clicar; em um
checkbox é o marcar/desmarcar; em uma caixa de texto é digitar alguma
coisa, etc.). Regras simples do controle de acesso são
habilitar/desabilitar diretamente esses valores. Regras complexas podem
interagir com inúmeros servições e condições de negócio até
identificar um resultado. Esse resultado, porém, nada mais é do que
habilitar/desabilitar o valor do controle na tela. O magoo é muito
flexível nesse aspecto.
11. Notamos até aqui, a gerência de permissões por controle de tela,
a mais granular possível. Controle por página é bem mais simples,
sendo suportada pelo próprio container web ou pelo framework.
Entretanto, nenhum desses controles é transaparente. Em outras
palavras, não podemos alterar seu comportamento durante a execução
do sistema. Isso somente seria possível se fosse criado um servlet que
monitorasse uma base de controle de acesso e, a cada requisição do
browser, ele fizesse a checagem da página solicitada. Felizmente, é
justamente isso que o magoo faz. Configurando um servlet controlador na
aplicação permite efetuar a gerência por nível de página.
Novamente, basta ir no módulo gerenciador do controle de acesso e
aplicar as permissões.
12. Ainda, é possível dinamizar o sistema. Em outras palavras,
aplicar permissões e tê-las refletidas instantaneamente na tela do
usuário. Novamente, devemos lançar mão do ajax para isso. O
princípio é o mesmo do passo 5, mas agora, quando a página é
varrida pelo javascript, a função de callback aplica as permissões
durante a varredura. Importante salientar que algumas operações podem
desestruturar a página do usuário. Por exemplo, ele pode estar
digitando em um campo quando simplesmente esse campo é desabilitado
pelo controle de acesso (obviamente, poderíamos evitar o campo com
foco e desabilitá-lo somente depois que o usuário sair dele). Mas tem
casos piores, como ocultar um painel, o que pode realmente destruir o
layout da tela exibida. Assim, permissões dinâmicas são possíveis,
mas trazem riscos inerentes.
Bom, falei bastante para esse primeiro post. Espero ter sido claro pelo
momento.
Att,