Implementando “UC003 Consultar/Imprimir Ficha Funcional!"
- Entendendo o “Modo de Visualização de Documento”
A consulta e impressão da “Ficha Funcional”, nosso próximo desafio, pede basicamente a apresentação de todos os dados da Agregação de “Funcionario” (portanto, presentes no formulário de manutenção que já fizemos), mas desta vez em um formato mais adequado para usuários consultarem e imprimirem. Além disso, temos ainda algumas políticas de segurança específicas. Veja pela Figura B11.1, que:
o Somente usuários com papel “RH” podem manter funcionários.
o Somente usuários com papel “RH” e “FolhaPagamento” podem consultar Ficha Funcional.
Figura B11.1. Diagrama de Casos de Uso da Versão 1.0 do RH Tut orial.
Vamos começar buscando uma solução para a consulta em si.
E o reúso deve ser nossa primeira opção: Será que podemos reutilizar a manutenção de funcionários, para atender a este Caso de Uso? Todos os dados estão presentes na manutenção. E mesmo que somente 80% estivessem, digamos, ainda assim compensaria reutilizar.
Mas o leiaute é um problema notório: O uso de Tab-Folder torna o documento visualmente bem segmentado para os usuários, evitando rolagens de página, mas é totalmente inadequado para impressão ou consulta analítica, que exige a apresentação de todos os dados simultaneamente.
Na sua forma de visualização padrão, um formulário de manutenção em Tab-Folder não está em um “leiaute” adequado para consultas analíticas e impressão, muito embora já possua o mais difícil: os critérios de recuperação (seleção) e o conteúdo do documento em si adequados e funcionais.
Capítulo
11
6Disponibilizando
Formulários para
“Consulta Apenas”
Em vez de desenvolvermos novos formulários e Colaborações com alto índice de redundância, podemos utilizar técnicas de gestão de leiautes para tentar reaproveitar código. E o jCompany FS Framework já traz uma opção automatizada que irá nos auxiliar muito nestes casos: o “Modo de Visualização de
Documentos”.
Já fomos apresentados a esta facilidade quando falamos sobre “Entrada de Dados em Lote” no capítulo anterior. Vamos conhecer agora algumas extensões que nos permitirão obter uma solução de consulta e impressão imediatamente funcional para quaisquer formulários de manutenção sem esforço.
1. Selecione um funcionário (acesse via Favoritos do Navegador!).
2. Em seguida, clique no botão “Vis. Documento”. Um resultado como o da Figura B11.2 deverá aparecer.
Figura B11.2. Modo de “Visualização de Documento”.
Neste formato, o nosso formulário se aproxima bastante do leiaute de um documento de negócio típico, impresso, pois alguns ajustes automatizados já foram feitos:
#1. O Tab-Folder é substituído por tags HTML “Fieldset” ou “Table” (dependendo do estilo do formulário escolhido pelo usuário, em Personalizar Formulário. Respectivamente, “Elegante” ou “Clássico”) e os componentes do formulário são organizados na vertical.
#2. O botão de ajuda do calendário não é mais exibido. #3. O botão de seleção para “vínculos” não é mais exibido.
#4. O componente com o botão para anexar arquivo também não é exibido (somente o nome do arquivo ou imagem, se houver um anexado).
#5. A imagem, o título e as caixas para marcação de exclusão de Detalhes também não são exibidos.
Podemos considerar este como um leiaute já apropriado para consulta. Mas não para a impressão! Se formos imprimir esta página pelo comando “Arquivo -> Imprimir...” (ou “File -> Print...”) do Navegador, imprimiríamos, junto com o formulário, o topo, a barra de ações com botões e o rodapé do leiaute principal. Além disso, as setas para seleção das listas de valores (combos) também não fazem sentido em uma impressão.
- Leiaute para impressão
A figura abaixo mostra um leiaute com topos e rodapés ajustados para impressão, sem barras de botões, com campos de entrada transformados em textos.
Figura B11.3. Formulário visualizado com a primeira opção de impressão, com leiaute apropriado.
#1. O topo, a barra de botões e os rodapés do leiaute original são substituídos apenas por um topo de impressão, que pode ser customizado especializando-se a página
“/fcls/geralImpressao.xhtml”. A imagem apresentada como padrão é declarada nos metadados globais – e a mesma utilizada na janela de login (se não informada, o default é
“/plc/midia/login-logo-empresa.png”).
#2. Funções Javascript do jCompany alteram os campos de entrada, transformando-os em textos simples.
#3. Somente os componentes do tipo “Botões de Rádio” e “Caixa de Marcação” não são modificados, pois se comportam bem em impressão.
#4. Os títulos também sofrem adequações incluindo um reforço de negrito, que comporta bem em todas as peles padrões disponibilizadas com o jCompany.
Antes de imprimir, o usuário pode ainda alterar o título com um simples clique no mesmo, conforme ilustra a Figura B11.4.
Figura B11.4. Alterando o título via DHTML com um simples clique na área do topo.
- Customizando Comportamentos em “Modo de Visualização” - Edição de Camada Controle IV
Para maximizar nossas chances de reúso, podemos exibir ou omitir certas informações, somente em “Modo de Visualização”, simplesmente testando a presença do indicador “visualizaDocumentoPlc” em escopo de requisição.
A Figura B11.5 traz um exemplo de teste para esconder a linha arquivos de currículos somente quando em “Modo de Visualização”:
Figura B11.5. Testando “Modo de Visualização” em páginas.
Mas e se quisermos acrescentar algum tipo de informação que exija programação Java, somente em “Modo de Visualização”?
Neste caso, bastaria especializarmos o método de extensão “editaVisualizaDocumentoApos()” em nossa classe de controle “FuncionarioMB” utilizando um mecanismo similar ao que fizemos para ajustar os argumentos de idade para data, no último Caso de Uso.
Vamos fazer um exemplo acrescentando o último pagamento recebido, ao lado do campo “observação”. Somente conseguiremos finalizar esta programação quando implementarmos o Caso de Uso de “Cálculo da Folha de Pagamento”, já que não temos salários recebidos ainda (somente os valores nominais de base). Mas já podemos adiantar a sua fôrma básica, o que já atende ao nosso propósito didático.
1. Edite a classe FuncionarioMB e implemente um método como o da Figura B11.6.
Figura B11.6. Método de controle que executa processamento somente em “Modo de Visualização”.
#1. Método de Extensão de "editDocumentView".
#2. Teste do modo. A presença do flag VISUALIZA_DOCUMENTO_PLC em request indica este modo..
#3. O retorno "null" mantém o usuário na mesma página (default). - Conferindo a implementação com Tomcat Hot Deploy – Depuração e Logging I
Neste momento vamos testar a implementação de nosso método de controle, mas desta vez sem
realizar nenhuma tarefa de liberação Maven. Note que XHTMLs, CSS, Javascript e mídias em geral
podem ser liberadas de forma instantânea pelo “jCompany Hot Deploy” - mas e no caso da classe “FuncionarioMB”?
O plugin para Tomcat chamado Sysdeo, homologado pelo jCompany Configuration Management, é capaz de realizar liberações “a quente” para classes Java. Es tas liberações são um pouco mais complexas
do que uma cópia simples de um arquivo “FuncionarioM.class”, do Eclipse para o Tomcat. Elas exigem um recarregamento desta classe por parte do “Class Loader”, que é o módulo dos Application Servers
encarregado de instanciar e manter estratégias de caching para códigos interpretados pela JVM*. Portanto, podemos testar imediatamente implementações em classe Java, sem esperas, desde
que tenham sido liberadas uma primeira vez via Maven. Em alterações de uma forma geral, que
são 95% das demandas, esta facilidade nos será bastante útil.
1. Chame a aplicação, edite um Funcionário e aperte o botão de “Visualizar Documento”. 2. Confira a console, procurando a mensagem de log como na Erro! Fonte de referência não
encontrada..
Figura B11.7. Mensagem de depuração aparecendo na Console.
Se a mensagem não apareceu, pode haver algum problema na configuração do “Source Path” para o Tomcat Sysdeo. Vamos conferir.
3. Abra a lista de projetos Eclipse que estão marcados para reconhecimento pelo Tomcat Sysdeo, em “Windows -> Show View -> Servers” e clique no arquivo "Tomcat".
4. Clique em "Open Launch Configuration" e irá abrir uma popup, clique na aba Source. 5. Confira se sua configuração está como a da Figura B11.8.
* T ambém é pos s ível s e realizar c onfigurações do WT P 2 .0 em projetos jCompany para permitir “H ot Deploy” para outros A pp
Figura B11.8. Projetos marcados no Tomcat Sysdeo para liberação imediata e reconhecimento em depuração.
Se ela estiver sem os projetos desejados, adicione-os através do botão "Add..." e reinicie o
Tomcat, para que passem a valer nas próximas modificações. Se esta configuração está correta e a mensagem ainda não apareceu, um outro ponto importante para conferir são os níveis de logging do Log4j.
6. Perceba na Erro! Fonte de referência não encontrada. que a classe de exibição da mensagem foi [AppMB], já que a classe de logging utilizada está definida no ancestral de “FuncionarioAction”, como mostra a Figura B11.9.
Figura B11.9. Classe de log declarada no ancestral de Controle da Aplicação.
No padrão que enviamos com ‘log.debug(“mensagem”)’ a mensagem somente é exibida se o nível de exibição para sua “classe de logging” está como “DEBUG”.
Confira o seu arquivo “log4j.properties” com a Figura B11.10. O jCompany Configuration
Management pré-configura este arquivo com nível DEBUG para todas as classes de logging
Figura B11.10. Arquivo de def inição de dispositivos, classes e níveis de logging do Log4j.
#1. Arquivo padrão chamado “log4j.properties”.
#2. A classe “rootLogger” é a ancestral geral, com nível “INFO”. Mudá-la para “DEBUG” liga o logging de todas as mensagens contidas em classes cujos pacotes não estão declarados neste arquivo, mas que se encontram presentes na aplicação.
#3. Para o Hibernate, a classe de log “org.hibernate.type” é especialmente importante, pois se alterada para DEBUG exibe os argumentos enviados em “Prepared Statements” (?) que aparecem nos SQLs! Por ser muito útil, é pré-configurada aqui pelo jCompany.
#4. Classes do framework do jCompany são declaradas como INFO.
#5. Classes da aplicação são declaradas como DEBUG (do contrário não veríamos a mensagem que fizemos).
#6. Definição da saída padrão para todas as mensagens na Console do Application Server. - Customizando em “Modo de Visualização para Impressão”
Já vimos como é possível se customizar o conteúdo apresentado em “Modo de Visualização”, que entra em cena quando o usuário clica no botão “Visualiza Documento”. É neste modo que se deve acrescentar ou remover informações, motivo pelo qual existem inclusive variáveis de controle e Template Methods dedicados a isso.
Mas vejamos agora um pouco sobre a customização em “Modo de Visualização para Impressão”. Para ajustes, é preciso que se compreenda sua característica especial de renderização: ao contrário do “Modo de Visualização”, que exige uma nova ida ao servidor para uma nova remontagem geral da página, a entrada em “Modo de Visualização para Impressão” não renderiza toda a página
novamente, para evitar sobrecarga desnecessária.
O mecanismo utilizado é basicamente o seguinte:
1. A página “/f/fcls/geralImpressao.xhtml” é chamada diretamente por todos os formulários no
jCompany, por meio de uma função Javascript que lhe passa, como parâmetro, todo o conteúdo da
página chamadora que se encontra dentro de duas “marcações padrões” (tokens). Esta marcações existem no template de formulário genérico "/f/fcls/template/PlcFormSubTemplate.xhtml" (utilizado para todos os formulários) delineando o trecho significativo para impressão, como abaixo:
<!-- INI -->
// Corpo do Formulário Útil para Impressão
2. Portanto, quando o usuário dispara a chamada para impressão, somente o topo de impressão é baixado, pois é o único conteúdo relevante da página “/f/fcls/geralImpressao.xhtml”. Esta pequena página é ultra leve, realizando a inclusão do conteúdo do formulário "chamador", passado como parâmetro, abaixo do novo topo.
3. Em seguida, esta página chama as rotinas Javascript do jCompany que realizam a troca dos componentes de formulário por textos mais apropriados para impressão.
Este esquema é tremendamente otimizado, comparado a uma nova renderização completa, mas trazem algumas consequencias importantes:
o Customizações mais profundas (acréscimos ou retiradas de informações dos formulários) devem ser realizadas no “Modo de Visualização” (como fizemos no tópico anterior) e não no de “Modo de Visualização para Impressão”, já que este não realiza processamento significativo no servidor. o Programações no “Modo de Visualização para Impressão” são possíveis somente via Javascript. Em “Modo de Visualização para Impressão”, de uma forma geral, podem ser utilizados os seguintes recursos para customização:
o Para alterar o topo ou o leiaute como um todo: Especializar a página “/src/main/webapp/fcls/geralImpressao.xhtml”, salvando-a do projeto “jcompany_view” para a Camada Bridge* ou para um projeto específico.
o Para alterar estilo CSS: Para alterações em estilos que devam ocorrer somente neste modo,
deve-se utilizar a declaração CSS "body.plc-impressao" como seletor, antes de qualquer outro estilo. Ex.: "body.plc-impressao span.af_outputLabel {}" possibilita alterar-se o estilo de rótulos somente em modo impressão.
- Reutilizando Formulários para ‘Somente Consulta’
Já deu para perceber que, com pequenos ajustes, os recursos generalizados no jCompany FS
Framework nos livrarão de redundar muitos elementos de manutenção na nossa desejável consulta; e
de um retrabalho que eliminaremos por inteiro:mais um bocado de XHTMLs, declarações no faces-config.xml, metadados etc.
Mas ainda precisamos responder a uma questão: Como tornar tudo isso transparente para o usuário final?
Muitos usuários não poderão inclusive manter funcionários, então entrar através da opção de
manutenção para depois comandarem consultas e impressões nã o seria muito apropriado. Mesmo que impedíssemos estes usuários de alterar, escondendo botões e impedindo submissões (“POSTs”) de manutenção, a chamada via menu não seria muito intuitiva.
Portanto, como podemos disponibilizar este nosso reúso para atender à especificação do Caso de Uso “UC003 Consultar/Imprimir Ficha Funcional!” em um item de menu próprio de modo que abra
diretamente a nossa “Ficha do Funcionário”?
Vamos responder a esta questão simplesmente declarando um novo item de menu e chamando nossa mesma Colaboração de Manutenção “/funcionariomdt”, passando alguns parâmetros especiais na URL:
1. Edite o arquivo “geralMenu.xhtml” (Control+Shift+R) copiando o seguinte bloco de código:
* A c amada Bridge foi introduzida no c apítulo 4 , s obre arquitetura. É um módulo c orporativo que atua em grande parte c omo uma
c amada (layer), s ervindo para generalizações de arquitetura es pecíficas da empres a que oc orrem após o jC ompany e antes das aplic ações.
Figura B11.11. Copiando item de menu no editor
2. Em seguida, altere o título chave para “menu.funcionario.con.titulo”. Agora altere o hiperlink de chamada, incluindo o sufixo
“&amp;mfPlc=t&amp;mcPlc=v”.
Note que o trecho em negrito acima é necessário pois queremos que seja renderizado no Navegador como simplesmente “&mfPlc=v&mcPlc=t”. O uso de “&” no lugar de simplesmente um “&” deve-se ao fato de desejarmos passar parâmetros de URL que não afetarão o formulário de seleção, apenas do de manutenção, que será transformado no de consulta. Então o token "&amp;" é o separador padrão para esta técnica.
Figura B11.12. Alterando o hiperlink para realizar chamada de f ormulário de manutenção em modo consulta.
o mfPlc=v (Modo Formulário = Visualiza). Abrir uma seleção passando este parâmetro, ou diretamente uma manutenção, faz com que o formulário se abra em “Modo de Visualização de Documento”.
o mcPlc=t (Modo Componentes = Texto). Abrir uma seleção passando este parâmetro, ou
diretamente uma manutenção, faz com que os componentes do formulário se abram com componentes convertidos para textos.
3. Defina o rótulo para a entrada de menu em “ApplicationResources_pt_BR.properties”. Lembrete: Não se esqueça de tabular após informar o texto neste editor. Se acionar o salvamente sem uma tabulação, o último texto não será gravado.
Figura B11.13. Rótulo para item de menu.
4. Salve os arquivos e faça uma nova liberação “Rápida para Tomcat com Reinicio”. 5. Entre na aplicação e clique em nosso novo item de menu. A mesma página de seleção de
Figura B11.14. Novo item de menu, reutilizando a mesma seleção do anterior.
6. Agora selecione em um objeto. Desta vez, ele já aparece apresentado em “Modo de Visualização”.
Figura B11.15. Novo item de menu, reutilizando a mesma seleção do anterior.
#1. Página de consulta aparece logo na entrada da edição e dentro do leiaute normal. #2. A Barra de Ações é ajustada para consulta apenas, restando somente o botão “Abrir”. #3. O leiaute do formulário aparece em “Modo de Visualização” e com campos em “Modo Texto”,
uma mistura com o leiaute de impressão.
Perceba que, diretamente neste modo, eventuais programações de ajuste específicas já são executadas evitando um clique adicional para o usuário. Constatamos isso pela ausência do campo observação, que ajustamos para não ser exibido em tópicos anteriores.
Importante: Quando reutilizando uma mesma Colaboração de Seleção para dois objetivos diferentes
seleção da manutenção esteja passando como parâmetro “fwPlc=<urlmanutenção>” (Ex.: fwPlc=funcionariomdt).
- Garantindo Acesso Somente para Consulta – Controle de Acesso II
Em nosso exemplo de consulta, se um usuário com papel “FolhaPagamento” quiser ver os campos de formulário em modo de manutenção, basta manipular a URL, retirando os parâmetros especiais que colocamos, para que consiga! Seria uma falha grosseira de segurança se estivéssemos considerando nossa implementação deste ponto de vista.
Ajustes visuais em aplicações Web não podem ser considerados como “segurança”. Considere-os sempre como um “conforto visual” bem desejável, mas implemente alguma verificação de segurança efetiva,
necessariamente no servidor.
Vamos agora cuidar da segurança começando por utilizar o que há disponível no padrão Java EE. E este padrão oferece recursos declarativos e suficientes para se restringir direitos de gravação e/ou consulta para determinados papéis em determinadas URLs:
1. Edite o arquivo “web.xml” e clique direito em “Security Roles”, como na Figura B11.16.
Figura B11.16. Def inindo “Atores” UML como “Roles” Java EE no web.xml.
Figura B11.17. Atores do negócio em amarelo. Membros e AreaTecnica são utilizados pelo jCompany.
3. Em seguida, defina uma primeira restrição, que irá impedir o acesso de gravação em funcionários, chamando-a de “Funcionário – Somente Consulta”.
Para tanto, clique direito acima de “Security Constraints” e adicione um “Web Resource Collection” contendo “/f/n/funcionariomdt” como URL pattern e “GET” como protocolo HTTP.
Em seguida, adicione a role “FolhaPagamento” a esta restrição. Confira o resultado com a Figura B11.18.
Figura B11.18. Restrição para acesso de “somente consulta” para usuários com role “FolhaPagamento”
#1. Nome da restrição.
#2. Nome dos recursos (conjuntos de URLs, basicamente) a serem protegidos.
#3. Padrões de URL que serão protegidas, podendo ter “*” como coringa. Em nosso caso, temos somente uma URL (apesar de chamada de dois modos diferentes).
#5. Lista de papéis (roles) de usuários que podem utilizar os recursos protegidos. No nosso caso, somente “FolhaPagamento”.
#6. Campo opcional para inserir uma descrição da "Web Resource Collection".
4. Defina a restrição para permitir manutenção somente para usuários com papel “RH” de uma forma similar, mas agora sem incluir nenhum protocolo definido. Deste modo, a restrição vale tanto para GET quanto para POST.
Novamente: Em Colaborações de Manutenção, o jCompany utiliza GET para a edição e POST para gravações.
Figura B11.19. Restrição para acesso de “consulta e manutenção” (todos os comandos HTTP) role “RH”.
5. Faça, como exercício, a definição da segurança para os dois primeiros Casos de Uso que desenvolvemos, restritos apenas ao papel “Administrador”.
6. Para teste, precisaremos criar novos usuários, papéis (roles) e associações apropriadas. Para isso, edite o arquivo “[jcompany]/servers/tomcat/conf/tomcat-users.xml” e altere-o, conforme a Figura B11.20.
Importante: O jCompany Configuration Management pré-configura no arquivo “web.xml”
uma primeira restrição geral que exige no mínimo o papel de “Membros” para qualquer usuário que queira acessar qualquer página da aplicação. E também uma segunda que exige o papel
“AreaTecnica” para usuários que terão acesso às funções do Menu “Área de TI”. Portanto, a menos que se queira modificar esta política, deve-se também atribuir pelo menos o primeiro papel aos novos usuários de teste.
Figura B11.20. Cadastramento de usuários, papéis (roles) e associação ent re ambos no arquivo Realm de teste.
8. Faça, então, testes com todas as variações.
Experimente autenticar com “joao", que não possui role “RH”, e acessar a manutenção. Perceba que ainda assim será possível a edição e consulta (já que sua role “FolhaPagamento” lhe dá acesso de “GET” para consulta). Porém, ao apertar “Novo”, “Gravar”, “Excluir” ou qualquer outra ação que envie comandos de “POST” para a URL “/f/n/funcionariomdt”, uma mensagem padrão para restrição de segurança aparece refletindo a proteção.
- Personalizando Menus com Declarações Facelets – Edição de Camada Visão IV
Com o resultado da segurança que implementamos no tópico anterior, invertemos nossa situação: agora temos políticas de segurança “mais refinadas do que os ajustes de conforto visual”. Usuários podem ver botões e itens de menu, mas disparam estes eventos, recebem mensagens de acesso negado.
Como já discutimos, a maioria das empresas exige que haja alguma “personalização” da
Interface com o Usuário, condizente com a segurança. Isto significa somente apresentar ao usuário
aqueles itens de menu, abas, botões e campos de formulário, em conformidade com o seu perfil de acesso.
É uma preocupação que, na verdade, serve a dois propósitos: o de facilitar a vida do usuário, que passa a não ver o que não tem direito de acessar; e o de reforçar ainda mais a segurança, não dando
informações iniciais que possam “despertar” iniciativas ilegais de invasão.
No nosso caso presente, a primeira necessidade óbvia é esconder itens de menu de usuários que não possuem direitos de acesso a eles. Vamos fazê-lo aproveitando a edição do menu para melhorar a sua organização geral.
Vamos começar criando mais blocos de menu de primeiro nível, separando as opções de manutenção da estrutura organizacional das que lidam com funcionários. Isso irá nos facilitar, por exemplo, a aplicar restrições de segurança ao primeiro bloco, que somente pode ser utilizado por usuários com papel “Administrador” (veja Figura B11.21).
1. Edite o arquivo “geralMenu.xhtml”.
2. Primeiramente, vamos fazer uma cópia do primeiro bloco do menu. Selecione o bloco “app.m.inicial”, para em seguida copiá-lo.
Figura B11.21. Copiando bloco de menu.
3. Utilize “paste” para colá-lo abaixo do bloco copiado.
4. Ao colar, denomine o novo bloco de “app.m.func” e, em seguida, retire os itens de chamada indesejados em cada um dos dois blocos resultantes, conforme ilustra a Figura B11.22.
Figura B11.22. Resultado da clonagem de bloco de menu já com alterações.
#1. Exclusão de itens de funcionário do “app.m.inicial”.
#2. Alteração do título (rótulo que aparecerá) para “app.m.func”. #3. Exclusão de itens de unidade organizacional do “app.m.func”.
Vamos agora modificar textos I18n. O rótulo de “app.m.inicial” pode ser modificado de “Menu Inicial” para “Unid. Organizacional”. E a nova entrada para “app.m.func” criada como “Funcionário”. Edite o arquivo “ApplicationResources_pt_BR.properties” (Control+Shift+R). Após a abertura do editor, no campo name busque por “app.m.inicial”. Altere o rótulo para “Unid. Organizacional”. Em seguida, clique no botão “Add” para adicionar uma linha e acrescente o novo rótulo, conferindo com a Figura B11.23.
Figura B11.23. Mensagens para a nova organização do menu.
5. Agora com uma melhor reorganização funcional do menu, podemos implementar facilmente nossa primeira “restrição de conforto visual” para permitir acesso ao primeiro bloco de funções de Estrutura Organizacional, somente a usuários com papel “Administrador”. Para tanto, basta usar uma função Facelets especial do jCompany, chamada "plct:execOneArg".
Esta função permite que se chame métodos de qualquer objeto disponível passando até 1 (um) argumento, de dentro de arquivos XHTML/Facelets. Ela é suficiente para chamarmos o teste padrão Java EE para "roles" do usuário corrente, que em uma classe Java seria
"request.isUserInRole("<ROLE-X>");". E pode ser utilizada para qualquer componente visual em diversas granularidades, seja em nível de “blocos” de menu, seja para cada item.
Edite a tag de menu "<li>" do “app.m.inicial” e informe a propriedade "style" com o código abaixo: <li style="#{plct:execOneArg(request,'isUserInRole','Administrador')?'':'display:none;'}">
Note que há um teste (finalizado por "?") que, se avaliado como "true" não irá renderizar nada no "style", deixando que o trecho seja apresentado. Se for "false", porém, ele renderiza "display:none;" no HTML, o que torna o elemento e todo o seu conteúdo invisível. O mesmo raciocínio pode também ser utilizado para o item de menu de manutenção de funcionário, que somente deve ser exibido para usuário com role "RH".
Por fim, tudo isso somente irá funcionar após declararmos o uso da biblioteca "plct" no documento Facelets. Veja abaixo as três modificações:
Figura B11.24. Opções diversas para itens de menu, inclusive segurança para blocos.
#1. Declaração para uso de funções especiais do jCompany, através do prefixo "plct". #2. Teste que irá exibir ou não a primeira seção de menu (Unidade Organizacional) em
conformidade com as roles do usuário. No caso, somente se ele tiver role "Administrador". #3. Teste adicional que irá exibir ou não a opção de menu para edição de funcionário, somente
sendo permitida para usuários com role "RH". - Testando “Conforto Visual” associado à Segurança
Com a finalização da programação, vamos liberar mais uma vez a aplicação para testar se as “políticas de segurança” e o “conforto visual” estão coerentes.
1. Libere utilizando “Liberação Rápida para Tomcat com Reinicio”.
2. Entre com o usuário “maria”, que não tem o papel “RH”, mas tem o de “Administrador”. O resultado esperado deve ser o da Figura B11.25.
Figura B11.25. Acesso para o perf il de “maria”.
Perceba que ela ainda vê o bloco de menu “Funcionários”, mas não tem acesso visual à opção de manutenção de funcionários, que é um “conforto visual”.
Mas o que acontece se ela tenta “furar a segurança”?
3. Consulte um funcionário e, em seguida, altere a URL da edição, retirando os parâmetros que forçam a exibição em consulta. Ou seja, deixando somente uma URL com
“.../f/n/funcionariomdt?chPlc=[Object-Id]”. Perceba que este funcionário aparece editado para manutenção, teoricamente “furando a segurança”.
4. Tente agora gravar o registro. Se a política de segurança foi definida corretamente no arquivo “web.xml”, aparecerá a mensagem da página “/plc/erros/erro403.html”, exibida na Figura B11.26. Esta página é registrada como padrão, também no arquivo “web.xml”, para exibir mensagens de segurança.
Neste caso, a explicação mais técnica é “Maria tentou dar um POST não permitido para seu perfil, na URL ‘/f/n/funcionariomdt’ ”.
Figura B11.26. Mensagem padrão para erro http 403 para segurança averiguada no servidor.
Dica: Para se customizar esta página de erro, bem como todas as páginas para erros padrões
HTTP*, deve-se alterar o registro das páginas de erro no “web.xml” apontando para uma específica.
5. Entre agora com o usuário “jose”, que tem o papel “RH”. O resultado esperado é o da Figura B11.27. Ele não tem acesso visual à barra de menu de unidade organizacional, mas tem acesso às funções de funcionário.
Figura B11.27. Acesso para o perf il de “jose”, mais restrito que o de “maria”.
6. Entre agora com “joao”, que tem o papel “FolhaPagamento” mas não tem “RH” ou “Administrador”. O acesso visual é o mais restrito. Até agora, a única função que este perfil pode executar na aplicação é consultar funcionários.
* N ote que o número 4 0 3 é um padrão http para erros de s eguranç a. E xistem vários outros c ódigos para variadas situações e cada
Figura B11.28. Acesso para o perf il de “joao”, o mais restrito de todos. Segurança e Conforto Visual integrados com jCompany Security!
- A problemática da segurança em aplicações Web
Discutimos, neste capítulo, a importância de se manter em sintonia as declarações e programações de segurança com as customizações de “conforto visual”. Praticamos também algumas técnicas que nos permitiram atingir este objetivo.
Porém, apesar da aparência simples em um pequeno exemplo, o trabalho para se manter estas duas dimensões de esforço, em todas as políticas que surgem em aplicações reais, não costuma ser nada desprezível. Além disso, estas aplicações podem exigir:
o Uso de certificados digitais de cliente para determinados perfis de usuário que devem apresentá-los para operar determinadas opções mais críticas.
o Manutenções frequentes de políticas de segurança, incluindo a necessidade da criação de
novos papéis (Roles) e novas políticas de restrição. Realizar novas alterações no arquivo
“web.xml”, novas montagens e liberação da aplicação toda vez que uma política é alterada está fora de questão... Mas seria necessário, no esquema utilizado até aqui*!
o Manutenção de políticas de segurança por usuários finais que devem possuir uma “IDE de Administração” já que não é viável alterarem políticas via edições do “web.xml”.
o Proteção contra hackers (no pior sentido), proibindo programações para implementação de políticas de segurança – o que por si, já é um importante flanco de segurança.
- Utilizando o jCompany Security
O jCompany Suite, apresentado no capítulo 1, traz diversos outros produtos que são oferecidos em separado do jCompany Developer Suite, mas que funcionam de forma imediatamente integrada. O
jCompany Security é um deles.
Com o jCompany Security (também chamado de jSecurity), todos os passos de programações e
declarações que fizemos neste capítulo, tanto para a “segurança efetiva”, via controle de acesso no
servidor, quanto para o “conforto visual”, se tornam desnecessários!
O jSecurity disponibiliza uma aplicação de administração de segurança, amigável para uso por usuários finais do negócio, que os permite criar papéis dinamicamente, além de definir e alterar políticas de acesso - somente nas aplicações sob sua responsabilidade. Isso tudo sem que haja necessidade de intervenções de programação e, portanto, exposição de políticas de segurança a profissionais de tecnologia. As restrições dinâmicas podem chegar até o nível de “campo de formulário” (Ex.: esconder campo X para usuários de perfil Y), pedir e gerenciar certificados digitais de cliente, dentre outras sofisticações.
* M es mo que alguma implementação de A pp Server permita a modificação das declarações de s egurança do “web.xml” em tempo
de exec ução, s em exigir remontagem e reliberação (ou s eja, “a quente”), não é razoável que profis s ionais da área téc nica tomem c iênc ia destas modificações de política. E es tas opç ões via App Server nunc a s ão amigáveis o s uficiente para que os devidos res pons áveis pela s egurança pos sam operá-las.
Além disso, uma única restrição de segurança cadastrada via jSecurity resulta tanto no registro dinâmico da segurança em si (utilizando padrão JAAS), como também em customizações dinâmicas de GUI (via integração com leiautes e componentes visuais do jCompany)! Com isso, se ganha
duplamente: em produtividade e também em qualidade da segurança na medida em que erros potencia is relacionados a esta “sincronia” são eliminados.
O jCompany Security é um produto comercializado em modelo Open Source Gerenciado, como o
jCompany Developer Suite. Se não for de interesse utilizá-lo, deve-se considerar o desenvolvimento
de alguma aplicação de administração de segurança similar, especialmente quando se trabalha com desenvolvimento corporativo, em larga escala.
Sumário
Neste capítulo encerramos o desenvolvimento do Caso de Uso “UC003 Co nsultar/Imprimir Ficha
Funcional”, reutilizando totalmente os nossos artefatos desenvolvidos para manutenção de funcionários através da utilização de opções dinâmicas do jCompany FS Framework, que permitem variações dinâmicas em leiautes e formatos de campos.
Vimos como é possível se customizar detalhes corporativos dos leiautes de impressão, tais como o padrão logotipo e cabeçalho padrão para impressões; e também como customizar detalhes necessários em cada Caso de Uso, tais como apresentar ou omitir informações, no modo e consulta ou impressão. Pela primeira vez implementamos regras de controle de acesso de acordo com o padrão Java EE, baseado em declarações de políticas de segurança definidas no arquivo “web.xml”. Complementamos esta
implementação com customizações na parte de Interface com o Usuário, escondendo ou exibindo itens de menu e/ou de formulários, em conformidade com as políticas de segurança estabelecidas.
Um desenvolvedor experiente deve levar em torno de 2 (duas) horas para produzir uma consulta de formulário, com qualidade para impressão inclusive, a partir de uma manutenção já existente, como pequenas customizações como fizemos.
No próximo capítulo do módulo C iremos realizar uma manutenção típica, pela primeira vez, e introdução os Casos de Uso Padrões de nível secundário.
