Download as
Browse Code »

Commit fea3484151d07dfe7aa8df12b3795fd97a2d5d75

Authored by rodrigorgs
1 parent c89055b1
Exists in master

Formata outros literais no cap. 15 da referência.

Showing 1 changed file with 15 additions and 15 deletions   Show diff stats
documentation/reference/pt-BR/security.xml
  Diff comments   View file @fea3484
... ... @@ -43,15 +43,15 @@ xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
43 43 </para>
44 44 <para>
45 45 O Demoiselle deixa o desenvolvedor livre para definir qual forma usar, de acordo com a sua conveniência e necessidade.
46   - A peça chave para tornar isso possível é o contexto de segurança, representado pela interface SecurityContext. Nessa
  46 + A peça chave para tornar isso possível é o contexto de segurança, representado pela interface <literal>SecurityContext</literal>. Nessa
47 47 estão definidos os métodos responsáveis por gerenciar os mecanismos de autenticação como, por exemplo, executar
48 48 login/logout de usuários e verificar se os mesmos estão ou não autenticados.
49 49 </para>
50 50 <para>
51 51 O contexto de segurança irá direcionar as requisições para a implementação definida pela aplicação. A autenticação será
52   - efetuada por uma classe que implemente a interface Authenticator, cujo método authenticate() é responsável por
  52 + efetuada por uma classe que implemente a interface <literal>Authenticator</literal>, cujo método <literal>authenticate()</literal> é responsável por
53 53 executar os passos necessários para validar a identidade de um usuário. Nesta mesma interface serão encontrados,
54   - ainda, os métodos unAuthenticate() e getUser(), responsáveis por, respectivamente, desautenticar e retornar o usuário
  54 + ainda, os métodos <literal>unAuthenticate()</literal> e <literal>getUser()</literal>, responsáveis por, respectivamente, desautenticar e retornar o usuário
55 55 autenticado.
56 56 </para>
57 57 <para>
... ... @@ -85,7 +85,7 @@ public class Credential {
85 85 }
86 86 }]]></programlisting>
87 87 <para>
88   - Neste caso, a interface SecurityContext e o bean Credential estão sendo injetados na classe utilizando o CDI.
  88 + Neste caso, a interface <literal>SecurityContext</literal> e o bean <literal>Credential</literal> estão sendo injetados na classe utilizando o CDI.
89 89 Dentro do método, ao definir o usuário e a senha e invocar <literal>context.login()</literal>, a implementação de segurança definida irá
90 90 tratar essa requisição de acordo com os critérios estabelecidos.
91 91 </para>
... ... @@ -98,17 +98,17 @@ public class Credential {
98 98 determinados recursos de um sistema. No modelo de segurança do Demoiselle 2, a autorização pode acontecer de duas
99 99 formas:
100 100 <itemizedlist>
101   - <listitem><para>Permissão por usuário, através da anotação @RequiredPermission</para></listitem>
102   - <listitem><para>Permissão por papel, através da anotação @RequiredRole</para></listitem>
  101 + <listitem><para>Permissão por usuário, através da anotação <literal>@RequiredPermission</literal></para></listitem>
  102 + <listitem><para>Permissão por papel, através da anotação <literal>@RequiredRole</literal></para></listitem>
103 103 </itemizedlist>
104 104 </para>
105 105 <para>
106   - Novamente a interface SecurityContext é a responsável pela interação entre as funcionalidades da aplicação e a implementação de
  106 + Novamente a interface <literal>SecurityContext</literal> é a responsável pela interação entre as funcionalidades da aplicação e a implementação de
107 107 segurança. Nela estão definidos os métodos que verificam se o usuário possui permissão para acessar um recurso ou se o
108 108 usuário está associado a um papel.
109 109 </para>
110 110 <para>
111   - A anotação @RequiredPermission pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais:
  111 + A anotação <literal>@RequiredPermission</literal> pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais:
112 112 <literal>operation</literal> e <literal>resource</literal>. O primeiro define a operação para a qual se deseja permissão e o segundo define em qual
113 113 recurso essa operação será realizada. Abaixo serão exemplificadas algumas formas de utilização:
114 114 </para>
... ... @@ -124,20 +124,20 @@ public class Credential {
124 124 }]]></programlisting>
125 125 <para>
126 126 Observe o método cuja anotação não possui parâmetros. Nesse caso serão considerados como recurso e operação o nome da classe e
127   - do método, respectivamente. Uma outra possibilidade seria utilizar a anotação @Name, tanto na classe como no método, de
  127 + do método, respectivamente. Uma outra possibilidade seria utilizar a anotação <literal>@Name</literal>, tanto na classe como no método, de
128 128 forma a possibilitar uma descrição mais amigável para o usuário.
129 129 </para>
130 130 <para>
131 131 Assim como na autenticação, o contexto de segurança possui métodos destinados a delegar as requisições de autorização para
132   - a implementação de segurança. No caso da anotação @RequiredPermission, o método hasPermission(String resource, String
133   - operation) executa esta tarefa. Para tanto, deve existir uma classe que implemente a interface Authorizer, cujo
134   - método hasPermission(String resource, String operation) verifica se o usuário logado possui permissão para executar
  132 + a implementação de segurança. No caso da anotação <literal>@RequiredPermission</literal>, o método <literal>hasPermission(String resource, String
  133 + operationliteral</p> executa esta tarefa. Para tanto, deve existir uma classe que implemente a interface Authorizer, cujo
  134 + método <literal>hasPermission(String resource, String operation)</literal> verifica se o usuário logado possui permissão para executar
135 135 uma determinada operação em um recurso específico.
136 136 </para>
137 137 <para>
138   - Ainda na interface Authorizer, pode-se notar a existência do método hasRole(String role), responsável por verificar se o
  138 + Ainda na interface <literal>Authorizer</literal>, pode-se notar a existência do método <literal>hasRole(String role)</literal>, responsável por verificar se o
139 139 usuário logado possui um papel específico. Este método é chamado pelo contexto de segurança, por meio do seu método
140   - hasRole(String role), para tratar as requisições que possuam a anotação @RequiredRole. Essa anotação possui um
  140 + <literal>hasRole(String role)</literal>, para tratar as requisições que possuam a anotação <literal>@RequiredRole</literal>. Essa anotação possui um
141 141 parâmetro obrigatório, no qual podem ser definidos uma simples role ou um array delas.
142 142 </para>
143 143 <programlisting role="JAVA"><![CDATA[class ClasseExemplo {
... ... @@ -169,7 +169,7 @@ public class Credential {
169 169 Após toda essa explicação, fica a dúvida: como implementar um esquema de segurança sem utilizar a extensão existente?
170 170 </para>
171 171 <para>
172   - O primeiro passo é criar classes para implementar as interfaces Authenticator e Authorizer. O <literal>Demoiselle</literal> detecta automaticamente
  172 + O primeiro passo é criar classes para implementar as interfaces <literal>Authenticator</literal> e <literal>Authorizer</literal>. O Demoiselle detecta automaticamente
173 173 a implementação, e torna essa classe a implementação padrão dessas interfaces:<!-- Essas classes devem ser
174 174 anotadas com @Alternative para que o CDI saiba que se trata de uma estratégia: -->
175 175 </para>
... ...