我有一个项目，还有一个子项目。现在我希望子项目使用与主项目相同的用户数据进行登录。从本质上说，我有点想使用主项目的users表（也许还有第二个与users相关的表）。这不是一个单向的道路，虽然，我希望用户也能够在子项目上创建帐户，然后再次对主项目也是有效的。
关键是：这些项目使用不同的专用服务器作为它们的sql数据库(但在版本10或10.1中
我考虑了以下选择：
1） 我可以在子项目中打开两个mysql示例，一个用于访问子项目数据，另一个用于访问主项目的用户数据。不过，这带来了一个很大的缺点，即a）我打开了2个连接，这可能也会导致性能损失；b）我根本不能在users表上使用任何连接。
2） 我听说过一个联邦引擎，当某些查询涉及使用联邦引擎的表时，它可以用来自动进行远程调用。但是，mariadb似乎不再支持此引擎(我来测试它也不是为了看看它还有什么其他的缺点。我在某个地方读到，这种方法存在潜在的安全问题，因为很容易读取到主服务器的连接信息？）
3） 我从未使用过复制，但如果我正确理解这个系统，我可以有第二个本地数据库，基本上是主服务器的users表的从属数据库，对吗？但是，我担心这迟早会导致问题，特别是如果我考虑到将来可能会有更多的子项目使用主项目的users表。如果有许多服务器都维护着完全相同的数据，那么当几个服务器试图同时添加（或编辑）数据时，听起来像是许多潜在的麻烦制造者。
4） 通过openid或oauth的中心登录表单目前不是一个理想的选择。目前，我希望每个项目都提供自己的注册/登录表单。
对于这个用例，这些（或其他）方法中哪一个是最优化的，并且易于设置/维护的？
1条答案
按热度按时间pobjuy321#
虽然我已经投票决定以基于意见的方式结束这篇文章，但我还是会提出我的观点：创建一个中间服务来进行身份验证，而中间服务会担心细节。
中间服务与两个数据库通信。它首先检查数据库a，然后检查数据库b。它可能会缓存结果。它可能会使一个数据库优先于其他数据库。这就是隐藏在编写的方便restapi后面的业务逻辑。
现在，您的主项目和子项目针对现在运行的中间服务发出rest请求。请求可能非常简单：这些凭据有效吗？如果是，则在项目中建立会话。如果会话可移植性很重要，请使用公共库来识别每个会话的会话值。
这种体系结构感觉最符合逻辑——各部分是分开的，业务逻辑包含在各自的单元中，没有太多不适当的冗余机会——但它正危险地接近于编写自己的auth。您可以考虑继续，咬紧牙关，实现中间身份验证系统以使用已建立的协议（例如oauth）或直接使用oauth系统。