search

Home  >  Q&A  >  body text

单点登录ticket在redis中存储问题

用户通过在单点登录服务器登陆,登录成功后,单点登录服务器分配给该用户一个ticket。然后单点登录服务器将该ticket做为key,用户名做为value,存储在redis中。通过判断该key是否是有效的来判断该用户会话有效。
后续会有服务通过向单点登录服务器发送一个ticket来验证该ticket是否有效,来判断该用户是否登录了。
但是这样会有个问题,某个用户肯能不停的登录,这样单点登录服务器每次都会将该ticket存储在redis中,虽然该ticket有过期时间,但有可能在短时间内在redis中写入大量的ticket。
不知这个有什么好的解决方法吗?

世界只因有你世界只因有你2761 days ago957

reply all(5)I'll reply

  • PHPz

    PHPz2017-04-24 16:02:16

    If you are talking about malicious calls to the interface, it is related to DDOS protection, and my answer will not apply.
    In fact, your problem will be encountered by anyone who has done this function. That is, if it is judged that the user has logged in, it must have not been done specifically to use cookies and sessions. What is involved here is the situation of logging in with different browsers. Cookies and sessions are both. It's useless.
    What I did at that time was to maintain another relationship in redis: username-->ticket, so that the previous ticket can be found based on the username, and it can be determined whether the user has logged in repeatedly.

    reply
    0
  • phpcn_u1582

    phpcn_u15822017-04-24 16:02:16

    I’ll answer this first. Add a verification code when logging in to make it more difficult to log in to the machine. This is one method. I wonder if there are other methods?

    reply
    0
  • 某草草

    某草草2017-04-24 16:02:16

    After logging in, the ticket should be recorded on the user side, either through session or cookie. Then when logging out, the server can get the ticket and clear it. Or when the user logs in again, the server can also get the last ticket to decide whether to destroy it. One is to use the user ID as the key value to save the ticket

    reply
    0
  • 天蓬老师

    天蓬老师2017-04-24 16:02:16

    If you log in non-stop in a short period of time, if it is a manual operation, you can rest assured that redis will not be unable to hold on.

    If it is a DDoS attack, you should add a protection policy on the outside (router, firewall, HTTP server or your application).

    In the application, it depends on how you are going to define such "abnormal login" behavior. For example, you can compare logins within a short period of time (you can customize the time interval), whether the source is consistent (for example, the user logged in from 10 seconds on earth within 5 seconds Log in from different places). When abnormal login behavior is detected, you can decide how to deal with it based on the sensitivity of the application (ban account? block IP? collect evidence and call the police:-)

    reply
    0
  • 淡淡烟草味

    淡淡烟草味2017-04-24 16:02:16

    Already logged in, why do you still want him to log in again? Is there something wrong with the logic?

    reply
    0
  • Cancelreply