0

好的，我真的要在这里展示我对 ASP.NET 安全模型的愚蠢，但这里就是这样。

我有一个 WCF Web 服务，并且我设法破解了通过我的自定义会员提供程序通过管道传输它的方法。

我的会员提供程序覆盖了“ValidateUser”，我在其中尝试使用我们的 SQL 服务器实例中的数据加载用户对象。到目前为止一切顺利，我检索了凭据，加载了用户对象，如果我在路上没有遇到任何颠簸，则返回 true。

此时，我通常会将用户对象（或 id）填充到会话中，或者实际上只是一些在请求的生命周期内可访问的状态包。我遇到的问题是此时 HttpContext 为空，即使我使用 ASP 兼容性属性。

我手头还有哪些其他选择？干杯，克里斯。

编辑：

只是为了澄清我想做什么。我想传递用户凭据以在服务器上进行身份验证，一旦发生这种情况，我想将经过身份验证的用户的详细信息保存在我只能在服务请求的生命周期内访问的地方。这将是 Http.Current.Items 的等价物吗？

是否有任何按请求实例化的对象，我可以通过静态属性全局访问（即以类似于 HttpContext.Current 的方式）？我假设 OperationContext 是 this，但这也是 null？

这真的是一个不常见的问题吗？在整个处理请求的过程中，发送凭据 > 检索用户 > 填充用户以供访问。对我来说似乎很常见，我错过了什么？

干杯，克里斯。

4

1 回答 1

0

基本上，对于 WCF，首选的最佳实践解决方案是使用每次调用激活，例如，每个新请求/调用都会获取服务类的新实例，并且为每个请求完成所有必要的步骤，如身份验证和授权。

这听起来可能效率低下，但 Web 应用程序，尤其是 Web 服务，应该尽可能完全无状态。将东西放入“状态包”只会在未来引发问题——你怎么知道什么时候该缓存的凭证副本无效？如果用户存在您的应用程序但 cookie 保留在他的机器上怎么办？

总而言之，我强烈建议尝试习惯每次都执行这些步骤的想法。是的，它会花费一点处理时间——但另一方面，在本质上无状态的环境中，你可以避免在状态管理方面的很多痛苦——无论你怎么看，这总是一个杂物。 ..

如果您仍然坚持这种做法，您可以为 WCF 打开 ASP.NET “兼容性”模式，这应该可以让您访问 HttpContext - 但同样：我强烈建议您不要这样做。第一个也是最明显的限制是，这种 ASP.NET 兼容模式当然只在 IIS 中托管 WCF 服务时才有效——我自己也不想在生产代码中这样做。

要打开 ASP.NET 兼容模式，请在 web.config 中使用此设置：

<system.serviceModel>
   <serviceHostingEnvironment 
        aspNetCompatibilityEnabled="true"/>
</system.serviceModel>

并且您需要使用相应的属性来装饰您的服务实现（实现服务合同的类）：

[AspNetCompatibilityRequirements(RequirementsMode=
       AspNetCompatibilityRequirementsMode.Allowed)]
class YourService : IYourService

AspNetCompatibilityRequirementsMode可以NotAllowed是Allowed或Required。_

更多信息和更透彻的解释，请参阅董文龙关于ASP.NET 兼容模式的博文

于 2009-11-28T22:32:43.293 回答