我在MVC解决方案中实现了以下操作属性。
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class AuthorizeADAttribute : AuthorizeAttribute
{
public string[] Groups { get; set; }
protected override bool AuthorizeCore(HttpContextBase httpContext)
{
if (base.AuthorizeCore(httpContext))
{
/* Return true immediately if the authorization is not
locked down to any particular AD group */
if (Groups == null)
return true;
foreach (var group in Groups)
if (httpContext.User.IsInRole(group))
return true;
}
return false;
}
}
并像这样调用它:
public const string Admin = "MY_DOMAIN\\Admins";
public const string Users = "MY_DOMAIN\\Users";
public const string AddUser = "MY_DOMAIN\\AddUser";
[AuthorizeAD(Groups = new string[] { Admin, Users })]
public ActionResult GridData(...)
{ ... }
[AuthorizeAD(Groups = new string[] { Admin, Users, AddUser })]
public ActionResult Add(...)
{ ... }
到目前为止它似乎工作正常(本地没有问题),直到有人注意到(在我发布的另一个问题上),我在已部署的实例上收到了401错误。
我认为我的AuthorizeADAttribute需要重新编写,除非任何人都知道主机环境可能存在什么问题。这个想法是用户必须在活动目录的管理员或用户组中才能访问该站点,如果他/她被分配给用户角色,他们也需要属于另一个组,例如:Add,删除,更新等......
到目前为止,我非常难过:/
答案 0 :(得分:2)
到目前为止似乎工作正常(本地没有问题), 直到有人注意到(在我发布的另一个问题上),我一直都是 在已部署的实例上接收401错误
这是完全正常的,这是NTLM authentication的工作方式。这是一种质询 - 响应身份验证协议,意味着服务器通过发送客户端响应的401页面来挑战客户端,...因此,您看到的401s是服务器发送给客户端进行身份验证的挑战的一部分。您可以看到客户端最终成功响应了这一挑战,并通过200次验证进行了身份验证。
我认为您不应该使用自定义授权属性重新处理任何内容。只是您可能不需要它,因为您可以使用默认的Authorize属性实现类似的功能:
[Authorize(Roles = "MY_DOMAIN\\Admins,MY_DOMAIN\\Users" })]
public ActionResult GridData(...)