Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Bom dia galera,
estou trabalhando em um projeto que consiste em dois sistemas, um em PHP/Ajax e o outro em Angular 5, ambos fazem requisição em um webservice (Apigility). O banco é postgres.
A questão é que quando a pessoa logar na tela de login sistema PHP, ele automaticamente logue no sistema Angular, que basicamente a "session" é guardada no localstorage.
Então pensei em trabalhar com session para compartilhar token e dados do usuário.
O problema é que não consigo compartilhar a mesma session entre o sistema e o webservice, nem o localstorage é compartilhado.
Estou bastante confuso como resolver isso..
Pensei em colocar os dados da session no banco de dados também.
Podem me ajudar? Dar outras soluções?
Obrigado.
OBS: Todos os sistemas (api, sistema php e angular) envolvidos estão no mesmo servidor, mas em subdomínios diferentes.
Como funcionaria essa sessão no banco?
Eu guardaria a session_id no banco, mas no outro sistema, a session_id já é outra...
Como eu localizo o registro do cara?
cria uma tabela e no mesmo registro você guarda as duas session_id,
id | session_1 | session_2 | id_do_cara
assim você sabe qual é a session em cada sistema e qual o id do cara
Olá @Master_Cyber, tranquilo?
Como você está lidando com API REST e SPA, o mais apropriado seria manter as requisições à sua API independentes de estado (stateless). E isso você consegue abrindo mão do uso de sessions/cookies. Esse é definitivamente o caminho mais apropriado para o seu caso.
Nesse caso você deveria implementar um processo de autenticação baseado em OAuth / OAuth2 e similares ou JWT token.
Bom, antes de qualquer coisa, qual é a diferença entre uma mecânica e outra?
1 - Com sessões/cookies você precisa armazenar as informações relacionadas a cada sessão dos usuários em arquivos separados no servidor (e no cliente também). Quando você lida com instâncias (máquinas) únicas de servidores isso é simples: as sessões ficam por padrão na pasta /tmp (em servidores Linux), mas isso varia da configuração da sua hospedagem.
Quando a demanda de sua aplicação cresce, você precisa escalar essas sessões, ou seja, torná-las acessíveis em mais de uma máquina, para que as requisições podem ser respondidas regularmente, independente de qual máquina é requisitada.
Outro cenário é o que você está passando, onde duas aplicações distintas precisam ter conhecimento sobre as sessões dos usuários.
Como resolver isso utilizando sessões? Bom, para o primeiro caso (escalabilidade) existem sticky sessions, mas não é o seu caso e não é a melhor solução de qualquer forma.
Você também pode simplesmente inserir as sessões em outro lugar (como um banco de dados ou um serviço de cache). E isso é bem simples de ser feito. Veja um exemplo na AWS com DynamoDb. Essa seria uma solução.
O problema é que utilizar sessões não é o melhor caminho para SPAs e inclusive nem está documentado pela Apigility que você citou.
2 - Com JWT ou OAuth não existe estado, nem sessões, mas existem várias chaves que devem ser trafegadas com o objetivo de autenticar (verificar identidade) e autorizar (verificar permissões/acesso) os usuários.
Após o processo de login, o usuário terá uma chave, que deve ser armazenado pela sua SPA em localStorage (ou outra forma) e enviado em toda e qualquer requisição que exija acesso privilegiado.
Você encontra toda a documentação de como fazer isso aqui (navegue no menu lateral): https://apigility.org/documentation/auth/intro
Resumindo: no seu caso, basta estudar e seguir o que é explicado nesse último link para autenticar os usuários.
Não quis complicar muito explicando como funcionam as requisições a fundo (especificações HTTP e cada etapa de ambos os processos), mas caso queira se aprofundar mais, esse material é excelente: https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies
Nossa cara, muito obrigado pela explicação... Me ajudou muito, vou estudar a melhor solução para minha situação..
Obrigado.
Eu utilizaria bando de dados também.