Bom dia!
Explicar como funciona um sistema comercial não é nada legal e nem divertido, pois a sua forma de funcionamento sempre está amarrada às regras de negócio que a empresa adota.
Então começar falando como é a baixa de um título, a emissão de duplicatas ou como a repimboca da parafuseta tributa o ICMS de cada produto e blá blá blá não é o alvo deste post. Irá ser demonstrado como é possível moldar a regra de negócio como se quer, mas isso posteriormente.
Hoje vamos iniciar uma série de posts falando da tecnologia interna utilizada no Lunar ERP, numa linguagem não muito técnica e procurando ser a mais clara possível, perdoem-me se assim não for.
1) CONEXÃO COM O BANCO DE DADOS
O que vemos por aí, comumente, é que a maioria dos sistemas comerciais (notavelmente os proprietários), conectam no banco de dados como super usuário, isto é, como administrador deste mesmo banco.
Como estamos oferencendo um sistema Open Source para que qualquer empresa possa utilizar, temos que quebrar esse conceito existente em diversos lugares de que a aplicação cliente é super usuário. Imagina o dono de uma empresa com o seguinte pensamento: “O sistema tem código fonte aberto, será que outras pessoas observando-o podem comprometer os dados do meu banco?”. No atual sistema de conexão implementado pela maioria, sim.
No sistema proposto pelo Lunar ERP (e que vários outros utilizam, não é nada novo aqui), não. Então conseguiremos assim fazer com que a segurança esteja do lado certo -> do servidor.
Ora, na forma atual de conexão da maioria dos sistemas, onde o super usuário fica no cliente, implementam assim, no mínimo, duas coisas:
- Facilidade para se desenvolver o sistema, pois o desenvolvedor não precisa se preocupar com GRANT’s e REVOKE’s;
Neste modo, o sistema tem seu próprio método de permissões. Ele conecta no banco como super usuário, e verifica as credenciais do usuário Fulano e senha Ciclano dentro de uma tabela interna.
- Risco de algum bug no software ou uma pessoa com capacidade em observar o binário e pegar a senha de conexão de super usuário.
Um bug no software poderia transformar um DELETE de um item em algo bem mais amplo podendo apagar uma tabela inteira por exemplo. Ou ainda mais grave se o desenvolvedor não se preocupou e facilitou um SQL injection sem intenção. No caso da pessoa em pegar a senha dentro do binário, nem se comenta, essa parte é a mais fácil de todas e a mais perigosa.
No Lunar ERP, cada usuário tem um nome e senha cadastrado no banco de dados, e o servidor mediante procedures e triggers) cuida das permissões emitindo GRANT e REVOKE aonde for necessário e de acordo com o que cada usuário é permitido.
No entanto, para que um usuário não se conecte diretamente ao banco com seu login e senha (para evitar os fuçadores), a senha armazenada neste mesmo é uma mesclagem da senha mestra com o hash de retorno apos o login pedindo permissao de entrada. Sei que ficou bagunçado, mas no esquema a seguir, fica mais fácil de se entender:
- Conecta no banco com o usuario lunar e senha ****** (sempre usando SSL)
Esse usuario lunar tem apenas acesso a algumas funções e mais nada, não é super usuário, e serve justamente para facilitar o login.
- Executa a função doLogin(Fulano, Ciclano) -> retorna hash
Esta função verifica nas permissões se o usuário pode logar e outras dependências. Se para ele for possível, retorna a senha hash (um md5) que o cliente usará para logar, ou ainda, se precisar de um número de cartão de acesso, similar ao encontrado nos bancos, a função retornará o pedido do valor X no cartão e a função chamada será a doLoginCartao(Fulano, Ciclano, Número), sendo este número a resposta do primeiro pedido.
- Assume senha = md5(senha_mestra + hash)
A senha mestra fica compilada dentro do binário, e serve só como um grau a mais de proteção para evitar que o usuário conecte-se diretamente de forma não assistida
- Reconecta no banco agora como usuário Fulano e com o resultado da senha
Vale lembrar que a hash nunca será a mesma após cada conexão, pois o sistema tem um tempo de vida para cada uma gerada (isso é configurável) e cria uma nova quando for necessário
Depois disso o sistema procede com as verificações de permissões e etc.
O mais importante aqui não foi falar da conexão em si, e sim frisar que a segurança fica é do lado do servidor, isto é, não podemos deixar de forma alguma que se existam super usuários do lado do cliente e nem formas fáceis para ele se conectar sem ser pelo sistema. Claro, este método está longe de ser perfeito e adequado, mas irá evoluindo com o tempo.
Este foi o processo de conexão. No próximo post explicarei mais detalhes sobre outros aspectos do sistema, no caso, sobre o sistema interno de permissões.
Obrigado 
