사용자가 Single Sign-On 서버를 통해 로그인합니다. 로그인에 성공하면 Single Sign-On 서버가 사용자에게 티켓을 할당합니다. 그런 다음 Single Sign-On 서버는 티켓을 키로, 사용자 이름을 값으로 사용하여 이를 Redis에 저장합니다. 키가 유효한지 확인하여 사용자 세션이 유효한지 확인합니다.
후속 서비스에서는 Single Sign-On 서버로 티켓을 보내 티켓이 유효한지 확인하고 사용자가 로그인했는지 확인합니다.
하지만 특정 사용자가 계속 로그인할 수 있다는 문제가 있을 수 있으므로 Single Sign-On 서버는 티켓에 만료 시간이 있지만 짧은 시간 내에 티켓을 매번 Redis에 저장합니다. . 많은 수의 티켓이 redis에 기록됩니다.
이 문제에 대한 좋은 해결책이 있나요?
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
만약 인터페이스가 악의적으로 호출되었다는 것이면 DDOS 보호에 속하므로 내 대답은 해당되지 않습니다.
실제로 이 기능을 수행한 사람이라면 누구나 귀하의 문제에 직면하게 될 것입니다. 사용자가 로그인했다고 판단되면 쿠키 및 세션을 사용하기 위해 특별히 수행되지 않은 상황입니다. 다른 브라우저, 쿠키 및 세션으로 로그인하는 것은 쓸모가 없습니다.
그때 제가 한 일은 redis에서 또 다른 관계인 username-->ticket을 유지하여 사용자 이름을 기반으로 이전 티켓을 찾을 수 있도록 하고, 사용자가 반복적으로 로그인했는지 여부를 판단할 수 있도록 하는 것이었습니다.
먼저 답변해 드리겠습니다. 로그인 시 인증번호를 추가하시면 기기 로그인이 더 어려워집니다. 이것도 하나의 방법인데 다른 방법이 있는지 궁금합니다.
로그인 후 티켓은 사용자 측에서 기록되거나 세션 또는 쿠키를 사용해야 합니다. 그런 다음 로그아웃할 때 서버가 티켓을 가져와서 지울 수도 있습니다. 마지막 티켓을 가져와서 여부를 결정합니다. 또 다른 파기 방법은 사용자 ID를 키 값으로 사용하여 티켓을 저장하는 것입니다
짧은 시간 안에 논스톱으로 로그인을 하게 되면 수동으로 하는 작업이라면 redis가 버티지 못하니 안심하셔도 됩니다.
DDoS 공격인 경우 외부(라우터, 방화벽, HTTP 서버 또는 애플리케이션)에 보호 정책을 추가해야 합니다.
애플리케이션에서는 이러한 "비정상적인 로그인" 동작을 어떻게 정의할 것인지에 따라 다릅니다. 예를 들어 짧은 시간 동안의 로그인을 비교할 수 있고(시간 간격을 사용자 정의할 수 있음) 소스가 일치하는지 여부가 있습니다. (예를 들어, 사용자가 지구에서 5초 이내에 로그인합니다. 10개의 다른 곳에서 로그인합니다.) 비정상적인 로그인 동작을 판단한 후 애플리케이션의 민감도(계정 금지 또는 IP 차단)에 따라 처리 방법을 결정할 수 있습니다. ? 증거를 수집하고 경찰에 신고하세요:-)
이미 로그인했는데 왜 다시 로그인시키려는 건가요? 로직에 문제가 있나요?