SessionManager - Histórico de revisão

Rodrigogml: /* SMInterceptor */

2020-10-22T21:17:14Z

SMInterceptor

← Edição anterior		Edição das 21h17min de 22 de outubro de 2020
Linha 138:		Linha 138:
	O SMInterceptor tem basicamente a função de testar a segurança da sessão antes de passar a chamada para os métodos e atua também como um verificador de RollBack. Sempre que o método da fachada retornar com uma exception, independente de qualquer tipo, ela forçará um Rollback de todas as ações controladas pelo container (EJB CMT).		O SMInterceptor tem basicamente a função de testar a segurança da sessão antes de passar a chamada para os métodos e atua também como um verificador de RollBack. Sempre que o método da fachada retornar com uma exception, independente de qualquer tipo, ela forçará um Rollback de todas as ações controladas pelo container (EJB CMT).


			{{nota\|Objetos Clonados depois da Fachada\|Note que para garantir o funcionamento da transação e do RollBack completo na Fachada todos os objetos que atravessam a fachada são clonados recursivamente ou com o clone() do java ou de forma mais eficiente implementando a interface '''BISRecursiveClonable'''. Embora não seja uma funcionalidade completa e não aceite ainda muitas estruturas do java, essa funcionalidade tenta garantir uma copia completa dos objetos para que quando o sistema execute um RollBack as alterações feitas no objeto pelo CRUD não sejam mantidas no objeto.

			Essa situação ocorre quando ambos os lados da fachada estão na mesma JVM, assim é a mesma instância na memória que cruza do lado Client para o Crud.

			Quando a mesma instância de um objeto está dentro de objetos distintos, passados em parâmetros diferentes do método, mas passados dentro da mesma chamada, o SMInterceptor é capaz de realizar a mesma montagem os objetos clonados.

			Isso garante por exemplo que, um objeto que esteja em uma lista e que seja usado como chave dentro de uma Hash, ainda possam ser recuperados comparando um objeto com outro.

			}}

	= Autenticação por Token =		= Autenticação por Token =

Rodrigogml: /* HASSESSION - Exige usuário autenticado */

2020-10-16T22:31:53Z

HASSESSION - Exige usuário autenticado

← Edição anterior		Edição das 22h31min de 16 de outubro de 2020
Linha 80:		Linha 80:
	== HASSESSION - Exige usuário autenticado ==		== HASSESSION - Exige usuário autenticado ==

	Este modo requer que o usuário esteja autenticado. Embora não ofereça nenhum tipo de filtro de acesso por usuário, apenas que seja um usuário com uma sessão válida no sistema. Em outras palavras, ao utilizar esse método todos os usuários autenticados do sistema terão acesso.		Este modo requer que o usuário esteja autenticado. Embora não ofereça nenhum tipo de filtro de acesso por usuário, apenas que seja um usuário com uma sessão válida no sistema. Em outras palavras, ao utilizar esse método todos os usuários autenticados do sistema terão acesso. Permite acesso tando para UUID quando para TOKEN.

Rodrigogml: /* Métodos Distintos para UUID e Token */

2020-10-16T19:46:00Z

Métodos Distintos para UUID e Token

← Edição anterior		Edição das 19h46min de 16 de outubro de 2020
Linha 151:		Linha 151:

	A recomendação é que os métodos, mesmo que tenham a mesma função, tenham chamadas diferentes na fachada quando forem para acesso por UUID ou quando forem por TOKEN. Assim evitamos alguns problemas de alteração na fachada e garantimos os tipos de segurança independentes.		A recomendação é que os métodos, mesmo que tenham a mesma função, tenham chamadas diferentes na fachada quando forem para acesso por UUID ou quando forem por TOKEN. Assim evitamos alguns problemas de alteração na fachada e garantimos os tipos de segurança independentes.



			= Obtendo a Sessão Corrente =

			Depois de passarmos pela fachada o SessionManager associa a thread em execução à sessão que foi passada pelo UUID. Em outras palavras, quando a fachada é chamada externamente o "ator" externo passará a UUID ou o Token conforme o tipo de segurança no método chamado. Uma vez que a autenticação foi aprovada, o '''SessionManager''' associará essa sessão à Thread corrente. Assim, para obter o objeto '''SessionVO''' de qualquer parte do sistema (depois de passada da fachada) basta utilizar o método:
			<pre>SessionManager.getSession()</pre>
			ou
			<pre>SessionManager.getSessionIfExists()</pre>

			A diferença entre um e outro é que o primeiro lança uma exception caso a Sessão não exista, já o segundo só retorna um 'null'. Apenas chamadas com o tipo de segurança 'SKIP' permitem que não se tenha uma sessão depois da fachada.

			== Execução em Paralelo e Lançamento de novas Threads ==

			Como a vinculação da sessão é realiza na Thread atual, sempre que o desenvolvedor se utilizar do recurso de lançar novas Threads para execução em paralelo a sessão não estará disponível na nova Thread. Mesmo que o desenvolvedor não use diretamente o conteúdo da sessão, outras ferramentas fazem uso dela em background com o [[FWLogger]], [[JobMonitor]] e até o [[BISDAO]].

			Para vincular a sessão atual nas novas Threads pode-se utilizar o método
			<pre>SessionManager.attachSessionToThread(...)</pre>

			Isso incluirá a sessão de autenticação na Thread e permitirá que os outros serviços encontre a sessão da mesma maneira como se estivesse aqui.


			Para fazer o efeito contrário, desassociar uma sessão de uma Thread pode-se utilizar o método '''cleanThread(...)'''. Embora isso possa ser útil em alguns casos, o SessionManager verifica temporariamente as Threads que estão vinculadas às sessões, e uma vez que elas apresentem o estado "State.TERMINATED", o próprio SessionManager removerá a referência para a Thread de forma a permitir que o GC colete essa Thread.

Rodrigogml: /* Interceptador da Fachada */

2020-10-16T19:36:00Z

Interceptador da Fachada

← Edição anterior		Edição das 19h36min de 16 de outubro de 2020
Linha 137:		Linha 137:

	O SMInterceptor tem basicamente a função de testar a segurança da sessão antes de passar a chamada para os métodos e atua também como um verificador de RollBack. Sempre que o método da fachada retornar com uma exception, independente de qualquer tipo, ela forçará um Rollback de todas as ações controladas pelo container (EJB CMT).		O SMInterceptor tem basicamente a função de testar a segurança da sessão antes de passar a chamada para os métodos e atua também como um verificador de RollBack. Sempre que o método da fachada retornar com uma exception, independente de qualquer tipo, ela forçará um Rollback de todas as ações controladas pelo container (EJB CMT).


			= Autenticação por Token =

			A autenticação por Token foi criada para a validação de autenticação de máquina, como uma API, um acesso que não dependesse de usuário/senha.

			Os tokens são String geradas pelo sistema da maneira que ele preferir, mas todas devem conter um prefixo, que permite que o SessionManager rapidamente distinga uma UUID do token. Recomenda-se algo curto (entre 3 e 6 letras) e um separador (como "-\|=:>"). Ex: "SToken:", "TK=", etc.

			Esse prefixo deve ser definido na inicialização do '''SessionManager''' e não deve mais ser trocado. Isso pq esse prefixo faz parte de todos os tokens informados nos sistemas externos. Trocar o prefixo fará com que todos os tokens dos sistemas externos se tornem inválidos.


			== Métodos Distintos para UUID e Token ==

			A recomendação é que os métodos, mesmo que tenham a mesma função, tenham chamadas diferentes na fachada quando forem para acesso por UUID ou quando forem por TOKEN. Assim evitamos alguns problemas de alteração na fachada e garantimos os tipos de segurança independentes.

Rodrigogml: /* HASTOKEN - Exige autenticação por TOKEN */

2020-10-16T19:29:59Z

HASTOKEN - Exige autenticação por TOKEN

← Edição anterior		Edição das 19h29min de 16 de outubro de 2020
Linha 118:		Linha 118:
	}		}
	</syntaxhighlight>}}		</syntaxhighlight>}}


			= Chaveiro de Acesso =

			Chamamos de chaveiro de acesso o conjunto de chaves que um usuário possui, ou que são atribuídas à uma sessão. Quando o '''SessionManager''' cria uma sessão e recebe do sistema uma implementação do objeto '''SessionVO''', este tem dois método '''hasAccess()'''.
			* '''hasAccess(String seckey, Long objID)''' - Inclui além da chave de acesso um ID de objeto, que tem a finalidade de definir chave de acesso que dão permissão não apenas à uma ação, mas também a alguns objetos do sistema e outros não. Por exemplo imagine que o sistema tenha diferentes contas bancárias cadastradas, mas queremos que um usuário tenha acesso à uma e não a outra. Para esses casos utilizamos este método e a utilização de chaves dinâmicas. Este método não é utilizado pela validação automática da fachada, e a verificação de acesso deve ser realizada dentro do método.
			* '''hasAccess(String key)''' - Este método por sua vez é chamado passando a chave do método. Se a implementação '''SessionVO''' retornar true é permitida a chamada do método, caso contrário é lançada uma exception por falta de acesso.


			= Interceptador da Fachada =

			Para que o SessionManager tenha acesso a intermediar a chamada da fachada precisamos incluir o '''SMInterceptor''' como interceptador da fachada. Para isso precisamos definir a seguinte annotation na classe da fachada do sistema:
			<pre>@Interceptors(SMInterceptor.class)</pre>

			Ao realizar esta declaração na classe da fachada, o Servidor de Aplicação chamará a classe do Interceptor antes de passar a chamada para a Fachada.

			== SMInterceptor ==

			O SMInterceptor tem basicamente a função de testar a segurança da sessão antes de passar a chamada para os métodos e atua também como um verificador de RollBack. Sempre que o método da fachada retornar com uma exception, independente de qualquer tipo, ela forçará um Rollback de todas as ações controladas pelo container (EJB CMT).

Rodrigogml: /* Fluxo de Autenticação */

2020-10-16T19:18:18Z

Fluxo de Autenticação

← Edição anterior		Edição das 19h18min de 16 de outubro de 2020
Linha 44:		Linha 44:
	# O '''SessionVO''' recebido do próprio sistema também é retornado pelo '''SessionManager''' e este objeto normalmente é retornado para o ator. Pois dentro dele constará o UUID que o ator precisará para chamar qualquer método que requeira uma autenticação.		# O '''SessionVO''' recebido do próprio sistema também é retornado pelo '''SessionManager''' e este objeto normalmente é retornado para o ator. Pois dentro dele constará o UUID que o ator precisará para chamar qualquer método que requeira uma autenticação.


			{{nota\|Fluxo de Autenticação por Usuário/Senha\|O fluxo de autenticação citado acima é referente apenas para o LogIn através do par usuário/senha. Autenticação feita por Token não exige a ação do Login.

			Embora ao receber um Token o '''SessionManager''' cria uma sessão válida com um UUID válido vinculado, normalmente os métodos destinados para comunicação diretamente com outra máquinas passam sempre o Token como primeiro método e não o UUID.}}

	== Autenticação nos Métodos ==		== Autenticação nos Métodos ==

Rodrigogml: /* HASTOKEN - Exige autenticação por TOKEN */

2020-10-16T19:15:13Z

HASTOKEN - Exige autenticação por TOKEN

← Edição anterior		Edição das 19h15min de 16 de outubro de 2020
Linha 103:		Linha 103:

	== HASTOKEN - Exige autenticação por TOKEN ==		== HASTOKEN - Exige autenticação por TOKEN ==

			Este modo requer apenas que o usuário tenha uma autenticação por Token, ou seja, ao invés de enviar um UUID no primeiro argumento, deve ser enviado um Token de autorização de máquina (API).


			{{java\|Exemplo Método com Exigência de Autenticação\|<syntaxhighlight lang="java">
			@Override
			@Security(action = SecurityAction.HASTOKENSESSION)
			public void apiMethod() {
			...
			}
			</syntaxhighlight>}}

Rodrigogml: /* HASKEY - Exige uma chave específica */

2020-10-16T19:13:24Z

HASKEY - Exige uma chave específica

← Edição anterior		Edição das 19h13min de 16 de outubro de 2020
Linha 91:		Linha 91:

	== HASKEY - Exige uma chave específica ==		== HASKEY - Exige uma chave específica ==

			Este modo requer não apenas que o usuário tenha uma sessão válida, como requer também que o usuário tenha acesso a uma chave de acesso determinada. A chave de acesso deve ser definida no atributo '''key''' da annotation. E embora seja uma String, é recomendável que seja uma constante em alguma classe estática do sistema, de forma que a mesma constante seja usada tanto na fachada quando na montagem do "chaveiro de acesso" do usuário.

			{{java\|Exemplo Método com Exigência de Autenticação\|<syntaxhighlight lang="java">
			@Override
			@Security(action = SecurityAction.HASKEY, key = System.SECKEY_DANCE)
			public void danceInTheRain() {
			...
			}
			</syntaxhighlight>}}

	== HASTOKEN - Exige autenticação por TOKEN ==		== HASTOKEN - Exige autenticação por TOKEN ==

Rodrigogml: /* HASSESSION - Exige usuário autenticado */

2020-10-16T13:42:20Z

HASSESSION - Exige usuário autenticado

← Edição anterior		Edição das 13h42min de 16 de outubro de 2020
Linha 77:		Linha 77:

	Este modo requer que o usuário esteja autenticado. Embora não ofereça nenhum tipo de filtro de acesso por usuário, apenas que seja um usuário com uma sessão válida no sistema. Em outras palavras, ao utilizar esse método todos os usuários autenticados do sistema terão acesso.		Este modo requer que o usuário esteja autenticado. Embora não ofereça nenhum tipo de filtro de acesso por usuário, apenas que seja um usuário com uma sessão válida no sistema. Em outras palavras, ao utilizar esse método todos os usuários autenticados do sistema terão acesso.


			{{nota\|HASSESSION é o Nível de Segurança Padrão\|Quando a annotation Security não é definida em um método de fachada que esteja sendo controlada pelo SessionManager, a segurança padrão definida no método será a HASSESSION. Ou seja, qualquer método sem nenhum tipo de anotação de segurança exige que o usuário esteja no mínimo autenticado, e consequentemente deve ter no seu primeiro parâmetro o UUID.}}


	{{java\|Exemplo Método com Exigência de Autenticação\|<syntaxhighlight lang="java">		{{java\|Exemplo Método com Exigência de Autenticação\|<syntaxhighlight lang="java">
Linha 85:		Linha 89:
	}		}
	</syntaxhighlight>}}		</syntaxhighlight>}}

	{{nota\|HASSESSION é o Nível de Segurança Padrão\|Quando a annotation Security não é definida em um método de fachada que esteja sendo controlada pelo SessionManager, a segurança padrão definida no método será a HASSESSION. Ou seja, qualquer método sem nenhum tipo de anotação de segurança exige que o usuário esteja no mínimo autenticado, e consequentemente deve ter no seu primeiro parâmetro o UUID.}}

	== HASKEY - Exige uma chave específica ==		== HASKEY - Exige uma chave específica ==

	== HASTOKEN - Exige autenticação por TOKEN ==		== HASTOKEN - Exige autenticação por TOKEN ==

Rodrigogml: /* SKIP - Sem Segurança */

2020-10-16T13:42:04Z

SKIP - Sem Segurança

← Edição anterior		Edição das 13h42min de 16 de outubro de 2020
Linha 61:		Linha 61:

	Por não exigir uma autenticação, os métodos com segurança SKIP são os únicos que não necessitam (nem faz sentido) ter o primeiro atributo como sendo String para o envio do UUID.		Por não exigir uma autenticação, os métodos com segurança SKIP são os únicos que não necessitam (nem faz sentido) ter o primeiro atributo como sendo String para o envio do UUID.


	{{nota\|Métodos Públicos em Fachada Diferente\|Perceba que por questões de segurança, quando se trata de métodos realmente publicos para acesso em massa de desconhecidos e não de sistemas controlados o mais prudente é ter uma fachada diferente da principal com os métodos de manipulação e acesso ao sistema.}}		{{nota\|Métodos Públicos em Fachada Diferente\|Perceba que por questões de segurança, quando se trata de métodos realmente publicos para acesso em massa de desconhecidos e não de sistemas controlados o mais prudente é ter uma fachada diferente da principal com os métodos de manipulação e acesso ao sistema.}}


	{{java\|Exemplo Método sem Segurança\|<syntaxhighlight lang="java">		{{java\|Exemplo Método sem Segurança\|<syntaxhighlight lang="java">
Linha 71:		Linha 73:
	}		}
	</syntaxhighlight>}}		</syntaxhighlight>}}


	== HASSESSION - Exige usuário autenticado ==		== HASSESSION - Exige usuário autenticado ==