作为远程服务的SqlMembershipProvider

Question

有什么解决方案可以利用来自不同服务器的SqlMembershipProvider呢？

动机:我们公司的安全分区政策不允许从web服务器直接连接到数据库。我们有一个传统的ASP.NET经典网站与SqlMembershipProvider和相应的连接字符串在它的web.config -这违背了安全策略，因此需要重新工作-与通常的最低努力。

到目前为止，我的想法是:一个简单的解决方案是在应用服务器上创建一个web服务，该服务将在幕后使用SqlMembershipProvider并公开必要的方法。这将由实现MembershipProvider的代理类在web服务器上使用。然而，我不想重新发明热水--尤其是如果这是一项古老的技术--所以如果有更好的主意或者现成的解决方案已经存在，请提出建议。成员数据库在多个应用程序之间共享，因此更愿意保留。

Answer 1

从理论上讲，这是可能的，但您必须继承sql提供程序类(角色和me成员资格)，从而编写自己的提供程序。当然，“其他”服务器将连接到sql安全提供者数据库，因此理论上，其他服务器将违反您试图避免的相同规则。那么，当其他服务器破坏了您在这个应用程序中不允许的事情时，它将如何工作呢？我的意思是，您可以从web.config中删除连接字符串，并将其放置到某种类型的静态类中。我的意思是，如果这里唯一的原因和目标是从web.config中删除连接字符串信息，那么重新编写安全提供程序无疑是一项艰巨的任务。

所以，你当然可以自己设计自己的供应商。您需要的3种提供程序中每个提供程序的方法数量都相当大，但在这些事件中，您只需要几个。但是，您不仅需要继承这3个类(Visual可以并将为您自动写出代码存根)，而且还必须在计划命中的另一个服务器上添加和编写所有这些方法。

因此，您需要在另一个服务器上编写大量的事件和web方法。

我已经编写了自己的提供程序--我的理由是我不想使用内置提供程序生成的“标准”表集，而是希望使用现有应用程序中的一些现有表。但是，这仍然是值得的，因为通过使用正确和标准的安全提供程序，所有在IIS安全设置中构建的内容(例如为每个文件夹在web.config中保护页面)都会正常工作。(因此，这比尝试使用自己的安全性要好得多)。

所以，你的目标和想法并没有那么糟糕，但这需要两个网站上的代码才能起作用。

当您固有的安全角色提供程序类时，您会得到以下内容：

​

​

现在，从上面出来？我没有费心去实现所有的方法。只有几个。

(这意味着我不需要使用IIS工具来设置和管理角色，但它们在设置(比如文件夹)和那些仅限于给定角色的页面方面确实工作得很好。

从上面看，我只需要这些：

FindusersInRole

GetAllRoles

GetRolesForUser

GetUsersInRole

IsUserInRole。

其他人呢？我只是留下了空白，像这样说：

​

​

因此，我没有费心重新创建所有的方法--实际上，我留下了大部分的空白。

“会员提供者”也是如此。

然而，这似乎都是很多工作，以“只是”将连接字符串从web.config。

那么，为什么不直接把连接线移出去-把它放在别的地方呢？因此，您可能仍然希望继承现有的角色和成员资格提供程序类，从而为连接字符串设置一个基于代码的方法。

但是，要建立对另一个站点的web服务调用呢？天哪，您必须在另一个服务器上为每个角色类方法以及成员资格提供程序类创建一个web方法。我想如果你整天都在编写web方法，以前做过很多这样的工作吗？那就不会有太多的工作了。

在我看来，将连接设置移出web配置要容易得多，随着继承角色和成员资格提供程序，您可以重写(在web配置之外提供自己的连接字符串)。

然而，不，我不知道有一个预先制定的解决方案。

如前所述，在大约30种方法中，我只使用了4-5种方法，而且我没有费心地将所有方法编码出来。因此，例如，我没有重新创建“添加用户到角色”，因为它更容易直接编辑角色表，并添加我需要的3-5个角色，因此多年来没有改变。