Merge pull request #27 from rodrigorgs/doc-seguranca

Corrige erros de programação e problemas de formatação no capítulo 15 da referência

Merge pull request #27 from rodrigorgs/doc-seguranca
Corrige erros de programação e problemas de formatação no capítulo 15 da referência
Emerson Oliveira
2 parents 9e299a1d 61f3e63d
Showing 1 changed file with 23 additions and 23 deletions Show diff stats
documentation/reference/pt-BR/security.xml
@@ -20,7 +20,7 @@
 	<section>
     	<title>Configurando</title>
     	<para>
-    	Para um correto funcionamento do Demoiselle é necessário inserir os interceptadores de segurança no arquivo <filename>src/main/WEB-INF/beans.xml</filename>.
+    	Para um correto funcionamento do Demoiselle é necessário inserir os interceptadores de segurança no arquivo <filename>src/main/webapp/WEB-INF/beans.xml</filename>.
     	</para>
 		<programlisting role="XML"><![CDATA[<beans xmlns="http://java.sun.com/xml/ns/javaee" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -43,15 +43,15 @@ xsi:schemaLocation=&quot;http://java.sun.com/xml/ns/javaee
 		</para>
 		<para>
 			O Demoiselle deixa o desenvolvedor livre para definir qual forma usar, de acordo com a sua conveniência e necessidade.
-			A peça chave para tornar isso possível é o contexto de segurança, representado pela interface SecurityContext. Nessa
+			A peça chave para tornar isso possível é o contexto de segurança, representado pela interface <literal>SecurityContext</literal>. Nessa
 			estão definidos os métodos responsáveis por gerenciar os mecanismos de autenticação como, por exemplo, executar
 			login/logout de usuários e verificar se os mesmos estão ou não autenticados.
 		</para>
 		<para>
 			O contexto de segurança irá direcionar as requisições para a implementação definida pela aplicação. A autenticação será
-			efetuada por uma classe que implemente a interface Authenticator, cujo método authenticate() é responsável por
+			efetuada por uma classe que implemente a interface <literal>Authenticator</literal>, cujo método <literal>authenticate()</literal> é responsável por
 			executar os passos necessários para validar a identidade de um usuário. Nesta mesma interface serão encontrados,
-			ainda, os métodos unAuthenticate() e getUser(), responsáveis por, respectivamente, desautenticar e retornar o usuário
+			ainda, os métodos <literal>unAuthenticate()</literal> e <literal>getUser()</literal>, responsáveis por, respectivamente, desautenticar e retornar o usuário
 			autenticado.
 		</para>
 		<para>
@@ -77,16 +77,16 @@ public class Credential {
 	private SecurityContext context; 
  
 	public void metodo1() { 
-		credential.setLogin(“usuario1”);
-		credential.setSenha(“123”);
+		credential.setLogin("usuario1");
+		credential.setSenha("123");
 		context.login(); 
 		// codigo do metodo 
 		context.logout(); 
 	} 
 }]]></programlisting>
 		<para>
-			Neste caso, a interface SecurityContext e o bean Credential estão sendo injetados na classe utilizando o CDI.
-			Dentro do método, ao definir o usuário e a senha e invocar “context.login()”, a implementação de segurança definida irá
+			Neste caso, a interface <literal>SecurityContext</literal> e o bean <literal>Credential</literal> estão sendo injetados na classe utilizando o CDI.
+			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á
 			tratar essa requisição de acordo com os critérios estabelecidos. 		
 		</para>	
 	</section>
@@ -98,18 +98,18 @@ public class Credential {
 			determinados recursos de um sistema. No modelo de segurança do Demoiselle 2, a autorização pode acontecer de duas
 			formas:
 			<itemizedlist>
-				<listitem><para>Permissão por usuário, através da anotação @RequiredPermission</para></listitem>
-				<listitem><para>Permissão por papel, através da anotação @RequiredRole</para></listitem>
+				<listitem><para>Permissão por usuário, através da anotação <literal>@RequiredPermission</literal></para></listitem>
+				<listitem><para>Permissão por papel, através da anotação <literal>@RequiredRole</literal></para></listitem>
 			</itemizedlist>
 		</para>
 		<para>
-			Novamente a interface SecurityContext é a responsável pela interação entre as funcionalidades da aplicação e a implementação de
+			Novamente a interface <literal>SecurityContext</literal> é a responsável pela interação entre as funcionalidades da aplicação e a implementação de
 			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
 			usuário está associado a um papel.
 		</para>
 		<para>
-			A anotação @RequiredPermission pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais:
-			“operation” e “resource”. O primeiro define a operação para a qual se deseja permissão e o segundo define em qual
+			A anotação <literal>@RequiredPermission</literal> pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais:
+			<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
 			recurso essa operação será realizada. Abaixo serão exemplificadas algumas formas de utilização:
 		</para>
 		<programlisting role="JAVA"><![CDATA[class ClasseExemplo { 
@@ -124,20 +124,20 @@ public class Credential {
 }]]></programlisting>
 		<para>
 			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
-			do método, respectivamente. Uma outra possibilidade seria utilizar a anotação @Name, tanto na classe como no método, de
+			do método, respectivamente. Uma outra possibilidade seria utilizar a anotação <literal>@Name</literal>, tanto na classe como no método, de
 			forma a possibilitar uma descrição mais amigável para o usuário.
 		</para>
 		<para>
 			Assim como na autenticação, o contexto de segurança possui métodos destinados a delegar as requisições de autorização para
-			a implementação de segurança. No caso da anotação @RequiredPermission, o método hasPermission(String resource, String
-			operation) executa esta tarefa. Para tanto, deve existir uma classe que implemente a interface Authorizer, cujo
-			método hasPermission(Object resource, String operation) verifica se o usuário logado possui permissão para executar
+			a implementação de segurança. No caso da anotação <literal>@RequiredPermission</literal>, o método <literal>hasPermission(String resource, String
+            operationliteral</p> executa esta tarefa. Para tanto, deve existir uma classe que implemente a interface Authorizer, cujo
+			método <literal>hasPermission(String resource, String operation)</literal> verifica se o usuário logado possui permissão para executar
 			uma determinada operação em um recurso específico.
 		</para>
 		<para>
-			Ainda na interface Authorizer, pode-se notar a existência do método hasRole(String role), responsável por verificar se o
+			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
 			usuário logado possui um papel específico. Este método é chamado pelo contexto de segurança, por meio do seu método
-			hasRole(String role), para tratar as requisições que possuam a anotação @RequiredRole. Essa anotação possui um
+			<literal>hasRole(String role)</literal>, para tratar as requisições que possuam a anotação <literal>@RequiredRole</literal>. Essa anotação possui um
 			parâmetro obrigatório, no qual podem ser definidos uma simples role ou um array delas.
 		</para>
 		<programlisting role="JAVA"><![CDATA[class ClasseExemplo { 
@@ -159,7 +159,7 @@ public class Credential {
 			disabled="#{!securityContext.hasPermission('contact', 'insert')}" />]]></programlisting>
 		<para>
 			Nesse caso, a habilitação de um botão está condicionada à existência de permissão para o usuário autenticado no momento
-			executar a operação “insert” no recurso “contact”.		
+			executar a operação <literal>insert</literal> no recurso <literal>contact</literal>.		
 		</para>
 	</section>
  
@@ -169,7 +169,7 @@ public class Credential {
 			Após toda essa explicação, fica a dúvida: como implementar um esquema de segurança sem utilizar a extensão existente?
 		</para>
 		<para>
-			O primeiro passo é criar classes para implementar as interfaces Authenticator e Authorizer. O <literal>Demoiselle</literal> detecta automaticamente
+			O primeiro passo é criar classes para implementar as interfaces <literal>Authenticator</literal> e <literal>Authorizer</literal>. O Demoiselle detecta automaticamente
 			a implementação, e torna essa classe a implementação padrão dessas interfaces:<!-- Essas classes devem ser
 			anotadas com @Alternative para que o CDI saiba que se trata de uma estratégia: -->
 		</para>
@@ -201,7 +201,7 @@ public class Credential {
 	} 
  
 	@Override 
-	public boolean hasPermission(Object resource, String operation) { 
+	public boolean hasPermission(String resource, String operation) { 
 		// Escreva aqui seu codigo de verificação de permissao 
 		return false; 
 	} 
@@ -228,6 +228,6 @@ frameworkdemoiselle.security.authorizer.class=projeto.MeuAuthorizerPadrao&lt;/progr
 	<caution> <para>O Demoiselle também oferece o componente 
 	<ulink url="http://demoiselle.sourceforge.net/docs/demoiselle-guide-components/1.2.0/html/authorization-master.html">Authorization</ulink> 
 	 que facilita o uso de segurança com JAAS. Obviamente, não é possível utilizá-los ao mesmo tempo. Há arquétipos Maven que já trazem esse componente 
-	 como dependência, por isso sempre confira o arquivo POM.XML e se for o caso retire essa dependência.</para> </caution>
+	 como dependência, por isso sempre confira o arquivo <literal>pom.xml</literal> e se for o caso retire essa dependência.</para> </caution>
  
 </chapter>
 \ No newline at end of file
...	...	@@ -20,7 +20,7 @@
20	20	<section>
21	21	<title>Configurando</title>
22	22	<para>
23		- Para um correto funcionamento do Demoiselle é necessário inserir os interceptadores de segurança no arquivo <filename>src/main/WEB-INF/beans.xml</filename>.
	23	+ Para um correto funcionamento do Demoiselle é necessário inserir os interceptadores de segurança no arquivo <filename>src/main/webapp/WEB-INF/beans.xml</filename>.
24	24	</para>
25	25	<programlisting role="XML"><![CDATA[<beans xmlns="http://java.sun.com/xml/ns/javaee"
26	26	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
...	...	@@ -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>
...	...	@@ -77,16 +77,16 @@ public class Credential {
77	77	private SecurityContext context;
78	78
79	79	public void metodo1() {
80		- credential.setLogin(“usuario1”);
81		- credential.setSenha(“123”);
	80	+ credential.setLogin("usuario1");
	81	+ credential.setSenha("123");
82	82	context.login();
83	83	// codigo do metodo
84	84	context.logout();
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.
89		- Dentro do método, ao definir o usuário e a senha e invocar “context.login()”, a implementação de segurança definida irá
	88	+ Neste caso, a interface <literal>SecurityContext</literal> e o bean <literal>Credential</literal> estão sendo injetados na classe utilizando o CDI.
	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>
92	92	</section>
...	...	@@ -98,18 +98,18 @@ 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:
112		- “operation” e “resource”. O primeiro define a operação para a qual se deseja permissão e o segundo define em qual
	111	+ A anotação <literal>@RequiredPermission</literal> pode ser utilizada tanto em classes como em métodos e possui dois parâmetros opcionais:
	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>
115	115	<programlisting role="JAVA"><![CDATA[class ClasseExemplo {
...	...	@@ -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(Object 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 {
...	...	@@ -159,7 +159,7 @@ public class Credential {
159	159	disabled="#{!securityContext.hasPermission('contact', 'insert')}" />]]></programlisting>
160	160	<para>
161	161	Nesse caso, a habilitação de um botão está condicionada à existência de permissão para o usuário autenticado no momento
162		- executar a operação “insert” no recurso “contact”.
	162	+ executar a operação <literal>insert</literal> no recurso <literal>contact</literal>.
163	163	</para>
164	164	</section>
165	165
...	...	@@ -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>
...	...	@@ -201,7 +201,7 @@ public class Credential {
201	201	}
202	202
203	203	@Override
204		- public boolean hasPermission(Object resource, String operation) {
	204	+ public boolean hasPermission(String resource, String operation) {
205	205	// Escreva aqui seu codigo de verificação de permissao
206	206	return false;
207	207	}
...	...	@@ -228,6 +228,6 @@ frameworkdemoiselle.security.authorizer.class=projeto.MeuAuthorizerPadrao</progr
228	228	<caution> <para>O Demoiselle também oferece o componente
229	229	<ulink url="http://demoiselle.sourceforge.net/docs/demoiselle-guide-components/1.2.0/html/authorization-master.html">Authorization</ulink>
230	230	que facilita o uso de segurança com JAAS. Obviamente, não é possível utilizá-los ao mesmo tempo. Há arquétipos Maven que já trazem esse componente
231		- como dependência, por isso sempre confira o arquivo POM.XML e se for o caso retire essa dependência.</para> </caution>
	231	+ como dependência, por isso sempre confira o arquivo <literal>pom.xml</literal> e se for o caso retire essa dependência.</para> </caution>
232	232
233	233	</chapter>
234	234	\ No newline at end of file
...	...