为什么我们应该选择PrincipalPermission而不是IsInRole()？
Q1 - 我不确定我是否理解为什么我们应该更喜欢使用 PrincipalPermission.Union() （或 PrincipalPermission.Intersect() ）而不是 IsInRole()？ 如果有的话，多次调用 IsInRole() 需要的代码少于创建多个 PrincipalPermission 对象并通过 Union() 将它们合并为一个对象（或 < em>相交())？
Q2 - PrincipalPermission 对象的一个构造函数重载还指定一个 IsAuthenticated 标志，告诉 Demand() 验证用户是否已通过身份验证。 使用该标志是否仅在前两个参数（ name 和 role ）均为空的情况下才有用？
谢谢
Q1 - I’m not sure I understand why we should prefer to use PrincipalPermission.Union() ( or PrincipalPermission.Intersect() ) instead of IsInRole()? If anything, calling IsInRole() several times requires less code than creating multiple PrincipalPermission objects and merging them into one via Union() ( or Intersect() )?
Q2 - One constructor overload of PrincipalPermission object also specifies a IsAuthenticated flag that tells Demand() to verify if user is authenticated. Wouldn’t using that flag only be useful in situations where first two parameters ( name and role ) are both null?
thanx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Q1. - RE：PrincipalPermission 方法与 IPrincipal.IsInRole(..)
这两个函数调用创建一个具有您赋予它的角色的并集或交集的PrincipalPermission。 因此，您最终会得到一个具有一组非常具体的需求的主体，然后您可以对其调用 IsInRole()。 请注意，这样做会影响您的角色提供程序（可能是 SQL 服务器或活动目录），因此会涉及延迟，因此您不想一直这样做。
Q2。 - RE：PrincipalPermission 身份验证
已通过身份验证表示用户已针对您的提供商登录。 如果您只需要审核您的应用程序，您可能需要这样做，确认用户已登录到您的角色提供程序将意味着您可以记录他们是谁等。
您说得对，它只在您不关心谁的情况下才有用用户是，只是他们已登录。
Q1. - RE: PrincipalPermission methods vs. IPrincipal.IsInRole(..)
The two function calls make a PrincipalPermission that has the union or intersection of the roles you give it. Thus you end up with a principal that has a very specific set of demands, which you can then call IsInRole() upon. Note that doing this will hit your role provider which may be an SQL server or the active directory and thus have latency involved, so you don't want to do it all the time.
Q2. - RE: PrincipalPermission authentication
Authenticated indicates that the user is logged in against your provider. You may want this if you need only auditing on your application, confirming the user is logged in to your role provider will mean that you can log who they are etc.
You are correct in saying it's only useful where you don't care about who the user is, only that they are logged in.