仅使用 cookie 进行身份验证的最佳方式是什么?

发布于 2024-11-09 02:36:49 字数 259 浏览 0 评论 0原文

我正在考虑一些方法。
1.使用用户PK,cookie值:{id}:{md5(id+salt)}
2. 使用用户电子邮件,cookie值:{email}:{md5(email+salt)}
3.方式1或2加密码,如{id}:{md5(id+pass+salt)},但是这种方式每次都会选择一个db(选择密码)

还有其他基于 cookie 的身份验证的好方法吗?

There are some ways which I am considering of.
1. using the user PK, the cookie value: {id}:{md5(id+salt)}
2. using the user email, the cookie value: {email}:{md5(email+salt)}
3. way 1 or 2 plus the password, like {id}:{md5(id+pass+salt)}, but this way will make a db select every time (select the password).

Is there any other good way of cookie based auth?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

灯下孤影 2024-11-16 02:36:49

您真正想要的是:

  id:[some_int],
  session_token:[some_hash]

会话令牌仅在服务器上创建,并且只是一个查找密钥...重要的是,与 user_id 配对。它存储在数据库中,并具有到期日期。一旦到期,您需要重新登录。您可以随时设置超时...更改生成密钥的方式等。您还可以对具有不同超时的身份验证令牌进行不同的分类等。

在页面加载时,您可以使用 id 和会话令牌作为查询您的会话表,通常带有日期范围选择(取决于您的登录业务规则)。如果一切都匹配,那就很好。为了进行额外的混淆,您可以使用部分用户代理。

在这种情况下,如何生成令牌并不重要... MD5(mktime()) 与其他任何东西一样好。

您唯一需要担心预构建格式的是 auth_tokens,它可用于弥合应用程序和应用程序之间的 API 差距。你的网络服务(听起来你不需要担心这个)。


示例登录检测流程:

<?php
   session_start();
   if (array_key_exists('auth_user', $_SESSION))
   {
       // user already has a session.
   }
   elseif (array_key_exists('session_token', $_COOKIE))
   {
       $sql = 'SELECT * 
               FROM sessions
               LEFT JOIN users USING (user_id)
               WHERE sessions.user_id = %d
                 AND sessions.token = \'%s\'
                 AND [ some date argument ]
               LIMIT 1';
       // execute SQL.  If you get a user back, great.  Set up a session.
       if (!empty($user))
       {
           $_SESSION['auth_user'] = $user;
       }
   }
   else
   {
      // Not logged in.  Do what you want here (like show a login UI).
   }

您的身份验证代码应创建令牌,将其放入数据库中,然后设置 cookie。

What you really want is:

  id:[some_int],
  session_token:[some_hash]

The session token is created only on the server, and is just a lookup key... importantly, paired with the user_id. It gets stored in a database, with an expiration date. Once that expiration is hit, you require a new login. You can set the timeout at any time... change the way you generate the keys, etc. You can also hav different classifications of auth tokens with different timeouts, etc.

On page load, you use the id and session token as queries into your session table, typically with a date rage selection (depending on your login business rules). If everything matches up, you're good. For extra obfuscation, you could use part of the user-agent.

How you generate the token doesn't matter in this case... an MD5(mktime()) is just as good as anything else.

The only time you need to worry about prebuilt formats is for auth_tokens, which could be used to bridge API gaps between applications & your Web service (doesn't sound like you need to worry about this).


Example login detection flow:

<?php
   session_start();
   if (array_key_exists('auth_user', $_SESSION))
   {
       // user already has a session.
   }
   elseif (array_key_exists('session_token', $_COOKIE))
   {
       $sql = 'SELECT * 
               FROM sessions
               LEFT JOIN users USING (user_id)
               WHERE sessions.user_id = %d
                 AND sessions.token = \'%s\'
                 AND [ some date argument ]
               LIMIT 1';
       // execute SQL.  If you get a user back, great.  Set up a session.
       if (!empty($user))
       {
           $_SESSION['auth_user'] = $user;
       }
   }
   else
   {
      // Not logged in.  Do what you want here (like show a login UI).
   }

Your Auth code should create the token, drop it into the DB, and set the cookie.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文