sqlmembershipprovider作为远程服务
是否有任何解决方案可以利用其他服务器使用SQLMembersHippRovider？
动机：我们公司的安全性分区策略不允许其他Web服务器直接连接到数据库。我们有一个旧的ASP.NET经典网站，其中包含sqlmembershipprovider和web.config中的相应连接字符串 - 违反了安全策略，因此需要返工 - 照常付出了最少的努力。
到目前为止，我的想法是：一个直接的解决方案是在应用程序服务器上创建Web服务，该服务器将在引擎盖下使用SQLMembersHippRovider并揭示必要的方法。这将在Web服务器上通过实现MemberHippRovider的代理类消耗。但是，我不想重新发明热水 - 尤其是如果是旧技术 - 因此，如果已经有任何更好的想法或现成的解决方案，请建议您。会员数据库在多个应用程序之间共享，因此更喜欢保留。
Is there any solution out there for utilizing SqlMembershipProvider from a different server?
Motivation: The security zoning policy at our company doesn't allow any more to directly connect to the database from web servers. We have a legacy ASP.NET classic website with SqlMembershipProvider and corresponding connection string in it's web.config - which is against the security policy hence need rework - with minimum effort as usual.
My thoughts so far: a straightforward solution would be to create a web service on the app server which would use SqlMembershipProvider under the hood and expose the necessary methods. And this would be consumed on the web server by a proxy class that implements MembershipProvider. However I don't want to reinvent the hot water - especially if it's an old technology - so if any better idea or an off-the-shelf solution is already there please advise. The membership database is shared among multiple apps hence prefer to keep.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从理论上讲，这是可能的，但是您必须继承SQL提供商类（角色和ME会员资格，因此编写您自己的提供商。“其他”服务器当然会与SQL Security Provister数据库有一定的联系，以便从理论上讲，其他服务器将打破您试图避免的相同规则。 web.config，将其放入某种类型的静态类中。 - 编写安全提供者
。您需要继承这三个类（Visual Studio可以并且将为您编写代码存根），但是您还必须在您计划击中的另一台服务器上添加并写入所有这些方法。
因此，您将有一系列事件和Web方法来在其他服务器上写入。
我写了自己的提供商 - 我的原因是我不想使用内置提供商生成的“标准”表，而是想使用现有应用程序中的一些现有表。但是，这仍然值得努力，因为使用正确和标准的安全提供商，然后使用所有内置的IIS Secuirty设置，例如在Web中确保页面。每个文件夹的Config都可以使用。 （因此，这要好得多，然后尝试滚动自己的安全）。
因此，您的目标和想法并不是那么糟糕，但是它需要两个网站上的代码才能正常工作。
当您固有安全角色提供商classe时，您会得到：
现在，从上面出发？我没有费心实施所有方法。只有少数。
（这意味着我无需使用IIS工具来设置和管理角色，但是它们在设置文件夹方面确实可以正常工作，并且这些页面仅限于给定的角色
。 ：
finduserinrole
getallroles
getrolesforuser
getuserinrole
。
需要这些
isuserinrole 映像”
空
的
然后，您可能要继承现有的角色和成员资格提供商类，因此具有基于代码的手段设置连接字符串
。 gee，您将必须在该角色类方法以及会员提供者类上对其他服务器上的Web方法进行Web方法。我想如果您整天整天编码Web方法，请之前做很多此操作？那将不是太多的工作。
在我看来，将连接设置移出Web配置以及继承角色和成员资格提供商，您可以覆盖（在Web配置之外提供自己的连接字符串）。
但是，不，我不知道为此做出预先做出的解决方案。
如前所述，在其中大约30种方法中，我只使用了大约4-5个方法，而我没有费心编码所有方法。因此，例如，我没有重新创建“将用户添加到角色”，因为直接直接编辑角色表并添加我需要的3-5个角色要容易，因此多年来没有更改它。
this in theory would be possible, but you would have to inherit the sql provider classes, (role and me membership and thus write your own provider. That "other" server will of course have some connection to the sql security provider database, so that other server would in theory be breaking the VERY SAME rule you attempting to avoid. So, how is that other server going to work when it breaks the very same thing you not allowing in this application? I mean, you could remove the connection string from the web.config, and place it say into a static class of some type. I mean if the ONLY reason and goal here is to remove the connection string information from the web.config, then it sure seems like a tall order to THEN re-write the security providers.
So, you certainly could cook up your own provider. The number of methods of each of the 3 providers you need is quite large, but out of those events, you only need a few. However, not only would you need to inherit the 3 classes (Visual studio can and will write out the code stubs automatic for you), but you ALSO have to add and write all those methods on the OTHER server that you plan to hit.
so, you would have a boatload of events and web methods to write on that other server.
I have written my own providers - and my reason was I did not want to use the "standard" set of tables generated by the built in provider, but wanted to use some existing tables from an existing applcation. However, it was still worth the efforts, since by using the correct and standard security providers, then ALL OF the built in IIS secuirty settings such as securing pages in web.config for each folder would then work. (which thus is MUCH better then attempting to roll your own security).
So, your goal and idea is not all that bad, but it would require code on both web sites for this to work.
When you inherent the security role provider classe, you get this:
Now, out of above? I did not bother to implement ALL OF the methods. Only a few.
(this would meant that I can't necessary use the IIS tools to setup and manage roles, but they do work just fine in terms of setting up say a folder and those pages being limited to a given role.
From above, I only really needed these:
FindusersInRole
GetAllRoles
GetRolesForUser
GetUsersInRole
IsUserInRole.
The rest of them? I just left them blank, say like this:
So, I did not bother to re-create all methods - I in fact left most empty.
Same goes for the "membership provider".
However, this all sure seems like a lot of work to "just" get the connection string out of web.config.
So, why not just move the connection string out - put it some place else then? So, you might still want to inherit the existing role and membership provider classes, and thus have a code based means setup for the connection string.
But, to setup web service calls to another site? Gee, you would have to make a web method on that other server for each of the role class methods, and also the membership provider class. I suppose if you code web methods all day long, done lots of this before? Then it would not be too much work.
seems to me, it would be far easier to just move the connection settings out of web config, and along with inheriting role and membership providers, then you could override (provide your own connection string outside of web config).
However, no, I don't know of a pre made solution for this.
As noted, out of the what, about 30 methods, I only did use about 4-5 of them, and I did not bother coding out all methods. So, for example, I did not re-create "add user to roles" since it was easier to just edit the role table directly, and add the 3-5 roles I needed, and thus not changed that for years now.