是否有任何解決方案可以從不同的服務器使用 SqlMembershipProvider？
動機：我們公司的安全磁區政策不再允許從 Web 服務器直接連接到資料庫。我們有一個舊的 ASP.NET 經典網站，其中包含 SqlMembershipProvider 和相應的連接字串，它的 web.config - 這違反了安全策略，因此需要返工 - 像往常一樣以最少的努力。
到目前為止，我的想法是：一個簡單的解決方案是在應用服務器上創建一個 Web 服務，該服務將在后臺使用 SqlMembershipProvider 并公開必要的方法。這將由實作 MembershipProvider 的代理類在 Web 服務器上使用。但是，我不想重新發明熱水 - 特別是如果它是一項舊技術 - 所以如果已經有任何更好的想法或現成的解決方案，請提出建議。會員資料庫在多個應用程式之間共享，因此更喜歡保留。
uj5u.com熱心網友回復：
這在理論上是可能的，但是您必須繼承 sql 提供程式類（角色和我的成員資格，因此撰寫您自己的提供程式。那個“其他”服務器當然會與 sql 安全提供程式資料庫有一些連接，這樣理論上，其他服務器會破壞您試圖避免的非常相同的規則。那么，當其他服務器破壞了您在此應用程式中不允許的相同內容時，該服務器將如何作業？我的意思是，您可以從中洗掉連接字串web.config, 并將其放入某種型別的靜態類中。我的意思是，如果這里的唯一原因和目標是從 web.config 中洗掉連接字串資訊，那么這似乎是一項艱巨的任務-撰寫安全提供程式。
因此，您當然可以制作自己的提供商。您需要的 3 個提供程式中的每一個的方法數量都很大，但在這些事件中，您只需要幾個。但是，您不僅需要繼承 3 個類（Visual Studio 可以并且將為您自動撰寫代碼存根），而且您還必須在您計劃訪問的 OTHER 服務器上添加和撰寫所有這些方法。
因此，您將有大量事件和 Web 方法可以在其他服務器上撰寫。
我已經撰寫了自己的提供程式 - 我的原因是我不想使用內置提供程式生成的“標準”表集，而是想使用現有應用程式中的一些現有表。但是，仍然值得付出努力，因為通過使用正確和標準的安全提供程式，所有內置的 IIS 安全設定（例如保護每個檔案夾的 web.config 中的頁面）都將起作用。（因此這比嘗試推出自己的安全性要好得多）。
所以，你的目標和想法并沒有那么糟糕，但它需要兩個網站上的代碼才能實作。
當您固有安全角色提供者類時，您會得到：
現在，在上面？我沒有費心去實作所有的方法。只有少數。
（這意味著我不必使用 IIS 工具來設定和管理角色，但它們在設定檔案夾和限制給定角色的頁面方面確實作業得很好。
從上面看，我只需要這些：
FindusersInRole
獲取所有角色
GetRolesForUser
獲取用戶角色
是用戶角色。
其余的？我只是把它們留空，這樣說：
所以，我沒有費心重新創建所有方法——事實上我留下了大部分的空。
“會員提供者”也是如此。
然而，這一切似乎需要做很多作業才能“只是”從 web.config 中獲取連接字串。
那么，為什么不直接將連接字串移出 - 放在其他地方呢？因此，您可能仍希望繼承現有的角色和成員資格提供程式類，從而為連接字串設定基于代碼的方法。
但是，要設定對另一個站點的 Web 服務呼叫？哎呀，您必須在其他服務器上為每個角色類方法以及成員資格提供者類創建一個 Web 方法。我想如果你整天撰寫 web 方法，以前做過很多這樣的事情嗎？那么就不會做太多的作業了。
在我看來，將連接設定移出 Web 配置會容易得多，并與繼承角色和成員資格提供程式一起，然后您可以覆寫（在 Web 配置之外提供您自己的連接字串）。
但是，不，我不知道對此有預制的解決方案。
如前所述，在大約 30 種方法中，我只使用了其中的 4-5 種，而且我沒有費心撰寫所有方法。因此，例如，我沒有重新創建“將用戶添加到角色”，因為直接編輯角色表并添加我需要的 3-5 個角色更容易，因此多年來沒有改變。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/465429.html
標籤：网 验证 sqlmembership提供者