验证和存储用户详细信息的方法

时间:2010-04-08 23:14:29

标签: php mysql session caching

我正在使用Zend Framework,但我的问题大致是关于sessions / databases / auth(PHP MySQL)。

目前这是我的身份验证方法:

1)用户登录,详细信息在数据库中检查。 - 标准的东西真的。

2)如果细节正确,则只有用户的唯一ID存储在会话和安全令牌(用户唯一ID + IP +浏览器信息+盐)中。会话写入文件系统。

  • 我一直在阅读,很多人都说在会话中存储东西不是一个好主意,而且你应该只写一个唯一的ID,它引用用户的详细信息和安全令牌来防止会话劫持。所以这是我采用的方法,我用来在会话中写出用户的详细信息,但我已经把它移出去了。想知道你对此的看法。
  • 我在文件系统中保留会话,因为我不在多个服务器上运行,因为我只是向会话写了一小部分数据,我认为性能会更高,使文件系统中的会话保持不变减少数据库的负载。一旦会话在身份验证上编写,它实际上只是从那时开始只读。

3)用户的其他细节(如订阅详情,权限,帐户信息等)都缓存在文件系统中(如果我想要更高的性能,这可以随时轻松移动到内存中)。

  • 因此,不是将用户的详细信息保存在会话中,而是将用户的详细信息缓存在文件系统中。我正在使用Zend_Cache,并且唯一的缓存ID类似于md5(/ cache / auth / 2892),该数字是用户的唯一ID。我想这种方法的好处是,一旦用户登录,基本上不会运行数据库查询来获取用户的详细信息。只是想知道这种方法是否比保持整个会议更好......

4)当用户在整个站点中移动时,唯一检查的是会话中的ID和安全令牌。

所以,总的来说,第一个问题是1)文件系统是否比数据库更有效率2)我采取了足够的安全预防措施3)将用户详细信息从会话分离到缓存文件是一项毫无意义的任务吗?

感谢。

2 个答案:

答案 0 :(得分:0)

1)通过制作循环脚本,您可以轻松地测试哪个更快。无论如何,使用文件系统的一个缺点是每次更新db时都需要更新缓存的文件。数据副本通常是一件坏事。此外,除非你有数百万的访客,否则我认为在任何一个阶层都不会有任何关于速度的实际差异。并且......不要忘记,会话也存储在文件系统中。每个会话一个文件。

查询是否比文件系统更快:取决于。是否启用了查询缓存。在MySql中,默认情况下,您可能比较幸运,只需要内存访问。如果没有,db无论如何都需要做一个文件系统。其次,您的查询与索引的优化程度如何。服务器硬盘有多糟糕。

3)取决于从db获取它的速度。一般来说,缓存可以通过魔术来提高性能,但是使用memcached或类似的东西,内存缓存会更好。一般来说,我会避免文件中的数据副本。但是,当然,如果从数据库中查询数据需要使用secods,那么请去文件系统缓存。此外,如果你有很多用户..像10.000+你必须制作一些文件夹系统,因为在同一文件夹中放置10.000缓存文件减慢了访问时间......

答案 1 :(得分:0)

你问的是一系列事情。

<强>会话

PHP中的会话快速而有效。在适度最新的服务器上成千上万个基于磁盘的小会话不会成为性能瓶颈。编写自己的处理程序(非常简单; PHP手册有示例)也不能将它放在数据库中。

关于会话的唯一最佳实践规则是:仅向Web浏览器提供一个事物,即会话ID。只需将登录的用户标识放入会话中,并在需要时从数据库中检索这些详细信息,这也是最佳实践。这也意味着可以更改用户信息,并在下次更新页面时获取用户信息。

这听起来不像你会遇到这个问题,但要注意把很多东西扔进会话。几K的数据(比如几十个标量)就可以了。将会注意到抛出许多对象和大量数据。如果您针对特定页面执行此操作,请记住在页面完成后将其丢弃在会话中。

您可能还希望使用会话变量实现自己的登录超时。 php.ini中的垃圾收集设置用于管理会话数据的存储,而不是用于执行登录超时。

<强>缓存

这是一个复杂的主题,您可能需要在实施任何内容之前开始收集指标(通常是页面加载时间)。

要实现任何类型的缓存,您需要考虑缓存数据的生命周期以及缓存未命中时重新生成数据的成本。只是在问题上抛出memcache是​​而不是解决方案;您仍然需要了解缓存参数以及memcache如何解释它们。这也适用于任何持久性存储解决方案,包括基于磁盘的会话,但我强调内存缓存,因为它是高调的,并且具有相当积极的到期机制。

一个经常被忽视的例子是在一个页面中多次从数据库加载相同的数据:一个好的ORM会为你做这些而不依赖于MySQL查询缓存。另一个被忽视的例子是在每个页面上运行的小查询:在中等繁忙的服务器上缓存这些只有几秒钟,数据库负载将大大减少。

最后,多级缓存通常比一次缓存更有效和可扩展,因为它们可以充分利用彼此的到期。它也抽象得很好:例如,将它隐藏在你的ORM中,理论上它可以无形地自动地用于所有你的对象。

相关问题