【问题标题】:Multi database authentication system, where should I store sessions using Zend Framework?多数据库身份验证系统,我应该在哪里使用 Zend Framework 存储会话?
【发布时间】:2012-09-04 16:27:18
【问题描述】:

我正在使用 Zend 框架编写一个 ERM 应用程序,其中用户帐户在主要公司帐户下创建,使我能够根据公司支付的许可证限制公司的用户帐户数量。每个公司帐户在我的服务器上都有自己的数据库(与其他公司具有相同的结构)来存储与该公司相关的数据。每个公司数据库的名称与其他公司帐户信息和许可证密钥一起存储在我的“后端”数据库中。身份验证系统的工作原理如下:

  1. 一个新用户(以前从未使用过该应用程序)登陆索引页面并看到“公司帐号”的单个文本字段
  2. 点击“提交”后,下一步就是输入用户名和密码。当用户提交此表单时,所有三项信息(帐号、用户名和密码)都会发送到我的应用程序的身份验证处理程序。
  3. 首先查询我存储公司帐户的“后端”数据库以查看用户输入的帐户是否存在。如果是,则返回company_db_name 列并建立连接,然后将其保存在Zend_Registry 中。否则,身份验证失败。
  4. 如果公司帐户确实存在,则返回的数据库将查询其users 表以获取指定的用户名和密码哈希,如果凭据不正确,则返回MyApp_Authfalse 的成功实例。

起初,我计划将用户会话数据存储在各个公司的数据库中,但是我在第一次登陆应用程序的索引页面时遇到了与该数据库没有连接的问题。我计划了一个解决方法如下:

  1. 将我的会话存储表从客户的数据库中移到我的“后端”数据库中,一旦应用程序启动,该数据库就会建立连接。
  2. 在表中添加“公司帐号”列并索引该列。
  3. 当用户登陆应用程序index 页面时,可以在后端数据库中查询当前用户代理的sessionid。如果找到,则返回所有必要的信息,即建立连接的公司数据库名称,以及用于构建模型的用户信息。

我对这种方法有几个问题:

问题 1:将我的应用程序的每个用户的所有会话信息存储在单个后端数据库表中是否存在风险?我在考虑成千上万的用户。

问题 2:我担心新用户可能会访问索引页面,并且完全有可能(理解这是非常低的可能性,但仍有可能)与后面的现有会话具有相同的 session_id - 结束数据库。这是一个有效的担忧吗?如果是,可以减轻吗?

问题 3:有没有更好的方法,或者您会推荐一种不同的方法来实现我所需的功能?

感谢您的宝贵时间!

【问题讨论】:

    标签: zend-framework session authentication zend-auth


    【解决方案1】:

    回答您的 3 个问题:

    答案 1. 只要您在会话到期时将其删除,存储每个用户的会话信息就没有风险。这里的问题是“可扩展性”您使用的是什么方法?它的可扩展性是否足够?写/读速度是多少? MySQL 是“结构化”方法,就像 MSSQL。您需要什么处理时间?存储了多少信息?什么是建筑学。对您的客户来说是否足够可行?

    答案 2。 理想情况下,session_id 不会相同,因此您不必担心。

    答案 3。 你需要 NoSQL(不仅是 SQL,甚至更多)方法。 Read this

    鉴于您数据的海量,我强烈建议您选择HBASE(使用 Hadoop,易于多集群)或CouchDB,或者如果您是亚马逊粉丝dynamoDB

    问题? :)

    编辑:刚刚意识到您正在使用 Zend 框架。在这种情况下,您也可以使用MongoDB,并使用Shanty Mongo 库。

    【讨论】:

    • 感谢您的意见!目前,我无法使用 MongoDB 来重构我的数据层,尽管我可能会考虑在未来进行。应用程序的性质需要特别深入的报告功能,我觉得 MongoDB 可能不是最适合的。关于问题 #2,我知道发生这种情况的可能性非常低,但是即使在 PHP 的 session_id 生成中添加了额外的“随机性”,这种可能性也肯定存在。我有一个想法,通过 IP 比较消除重复 ID 的可能性(同样非常小)。
    • 那么,我猜你没有更多的疑问了?
    猜你喜欢
    • 1970-01-01
    • 2020-12-16
    • 2022-01-05
    • 1970-01-01
    • 2018-11-23
    • 2021-07-19
    • 1970-01-01
    • 2021-12-26
    • 1970-01-01
    相关资源
    最近更新 更多