sexta-feira, 15 de abril de 2016

Login

Pergunta recorrente pelos desenvolvedores iniciantes, como desenvolver um login?
Esta é o primeiro muro que um desenvolvedor sofre ao se deparar com o Genexus, e muitas vezes a dificuldade não está na compreensão do processo em si, mas na escolha dos elementos necessários para realizar a operação.

Me desculpem os veteranos, mas no intuito de contribuir com os recém-nascidos, vamos responder isso de uma vez por todas, rs.

Use o GAM

A melhor opção que você poderá desenvolver é utilizando o GAM, pois é um recurso que já está disponível, foi desenvolvido mediante o protocolo OAUTH e protegerá todos os seus objetos expostos incluindo webservices.

Simples de utilizar, bastando nas Preferences ligar o Enable Integrated Security=Yes, em seguida trabalhar na configuração dos perfis (Roles) e usuários (Users).

O GAM poderá se comunicar com sistemas de login existentes por meio dos métodos de autenticação externa, que utilizará um webservice para conectar ao seu sistema remoto.

Maiores informações

Porque precisamos de Login?

Para os teimosos que pretendem escrever seus próprios mecanismos, vamos a uma estrutura básica.

Fazer login significa fornecer informações suficientes para que o script em execução no servidor possa identificar a pessoa que está utilizando o sistema. Desta forma será necessário ter algumas informações para que o controle possa ser efetuado. Previamente será necessário cadastrar as pessoas que serão identificadas, sendo que normalmente necessitamos de duas informações para proceder a identificação: usuário ou email e a senha. Uma transação serve a esta finalidade.
 

Algumas chaves possíveis para representar usuários:
  • Email: alguns sistemas utilizam email para identificar uma pessoa, o que não deixa de ser uma boa estratégia porém, muitas pessoas preferem ficar trocando de caixa de email de tempos em tempos, temos também pessoas que utilizam email de outra pessoa, como por exemplo, a namorada apaixonada que utiliza o email do namorado (acuado), claro que com primeiras intenções.
  • CPF: para os brasileiros temos o numero do CPF que também pode ser uma boa opção de chave, porém temos também algumas dificuldades, principalmente para pessoas que utilizam o CPF de terceiros (o filho que utiliza o CPF do pai ou do avô), e estrangeiros também não o possuem.
  • Palavras simples: apesar das críticas ainda acho que uma palavra definida pela própria pessoa seja a melhor estratégia para usuários. Colocando a palavra como chave primária teremos a garantia de que não será repetida, portanto, temos uma boa e livre opção.]
Teremos também a necessidade de identificar objetos (programas), perfis e associar tudo isso ao usuário.

 
 Veja que a complexidade vai aumentando, por isso a recomendação pelo GAM.

Processo de Login

Quanto uma pessoa utiliza um navegador de internet para se comunicar com um servidor Web se estabelece um registro da conexão que é a denominada chave de sessão. Trata-se de um valor randômico que inclui letras e números, único e que vai permitir entregar a comunicação de forma adequada para o requisitante.


A chave de sessão é criada  com ou sem operações de login, ou seja, é uma característica da Web, bastando chamar uma página ou script, que a mesma será criada. Localmente se criará um cookie e no servidor uma websession. Na imagem acima a chave é apresentada na variável Valor.

O servidor Web armazena esta chave em uma porção de memória chamada de websession, juntamente com outras informações que permitem estabelecer o contato com o cliente remoto. O endereço IP, e principalmente a data e hora da última comunicação com o servidor, de forma que depois de um certo tempo limite de inatividade (Time Session) o servidor pode destruir as sessões que expiraram (normalmente a sessão dura 20 minutos).

O processo de login normalmente utiliza o conceito do websession para armazenar alguma informação que determine que o cliente remoto passou pelo processo de identificação, para fins de controle de autorização para acesso aos objetos, normalmente o Perfil de acesso. A este perfil associa-se os objetos que possui privilégio de acesso, e por ai vai.

Operação de Login


A operação de login é simples, bastando um webpanel com duas variáveis e um botão.


E ao pressionamento do Confirm, a avaliação para saber se a pessoa informou corretamente os dois valores.

Event Enter
    &erro = ''
    for each
        where UsuarioId = &UsuarioId
        if UsuarioSenha <> &UsuarioSenha
            &erro = 'Senha incorreta'
        endif
    when none
        &erro = 'Usuário não encontrado'       
    endfor

    if &erro.IsEmpty()
        &websession.set('Usuario', &UsuarioId)
        Inicial()

    else
        msg(&erro)
    endif
Endevent


Observe que se o usuário e a senha estiverem corretos a página de ingresso no sistema Inicial(), será chamada, caso contrário a mensagem indicativa será exibida.

Na página Inicial() e em todos os objetos será necessário programar uma avaliação para se saber se existe alguma coisa registrada na variável Usuario na websession.

Event Start
    if &websession.get('Usuario').IsEmpty()
        Login()
    endif

Endevent






Esta é a estrutura mais básica que podemos construir. Falta ainda identificar o perfil, mas creio que daqui pra frente fica simples.

Considerações

Apesar da simplicidade temos muitas implicações relacionadas neste processo, recomendo inclusive que você estude um pouco a respeito da OWASP TOP 10, que trata dos problemas de vulnerabilidade que nossas aplicações poderão enfrentar.

  1. Recomenda-se que dados sensíveis como a própria senha do usuário seja gravada no banco em forma encriptada, praticamente dados pessoais devem sempre ser protegidos. Top A6: Exposição de dados sensíveis.
  2. A comunicação entre o navegador de internet e o servidor tem que ocorrer de forma encriptada por meio de um certificado SSL, e com protocolo HTTPS. Se não for desse jeito, qualquer pessoa poderá interceptar a comunicação e ler o usuário e senha transmitidas. Top A5 – Configuração Incorreta de Segurança, A2 – Quebra de autenticação e Gerenciamento de Sessão.
  3. Se não for avaliado o acesso em cada programa, e muitas vezes a verificação também tem que envolver os dados apresentados, estaremos quebrando mais um protocolo de segurança. Top A7 – Falta de Função para Controle do Nível de Acesso
  4. Normalmente nossas interfaces de login são submetidas a um mecanismo de invasão por força bruta onde um script busca criar as senhas para tentar ingressar. Deve haver um mecanismo de proteção para se evitar que sejam realizadas chamadas indiscriminadas em uma única chave de sessão. Uma estratégia é incluir um controle do tipo Captcha, para identificar um usuário humano. http://marketplace.genexus.com/product.aspx?captcha,en
  5. Os navegadores de internet tem a péssima funcionalidade de lembrar os valores de login. Se o procedimento não for corretamente implementado, poderá haver a possibilidade de um usuário ingressar no login de outro.
  6. Controles de segurança implementados em Javascript poderão ser facilmente quebrados, bastando o usuário desligar o privilégio de execução no seu navegador. Toda operação de segurança deverá ocorrer no servidor e não no cliente.

Poderíamos ficar discorrendo sobre esse assunto por várias páginas, mas acho que já deu pra dar uma noção. Eu particularmente acho que o GAM é a melhor solução, pois não precisaremos programar nada, e teremos mais tempo para desenvolver outras questões importantes relacionadas com segurança, que podem muitas vezes inviabilizar o sistema na web.

Este tema é profundo e requer não apenas atenção para se criar uma bela interface para realizar o login.

Bom trabalho!