0

As following to this answer I have created an AuthorizeAttribute class in my projects default namespace. So that the compiler will automatically pick it up instead of MVC's standard one. But it picks System.Web.Mvc.Authorizeattribute.

If I include my projects namespace, which is using TestIdentitySample; then the following error was shown 

  'Authorize' is an ambiguous reference between 'System.Web.Mvc.Authorizeattribute' and 'ProjectDefaultNamespace'
  • Please be noted that I do not want to use fully qualified name or namespace alias or other Custome Attributes name.

My AuthorizeAttribute Class

namespace TestIdentitySample
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
    public class AuthorizeAttribute : System.Web.Mvc.AuthorizeAttribute
    {
        protected override void HandleUnauthorizedRequest(System.Web.Mvc.AuthorizationContext filterContext)
        {
            if (filterContext.HttpContext.Request.IsAuthenticated)
            {
                filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);
            }
            else
            {
                base.HandleUnauthorizedRequest(filterContext);
            }
        }
    }
}

I just want that the compiler will automatically pick it up instead of MVC's standard one if it is possible. Thanks in advance for any help.

ramzan ali
  • 471
  • 4
  • 14
  • 2
    It would so long as you have no references at all to `System.Web.Mvc` in the code (but that would be highly unlikely since you would want to use that on a `Controller`), so just change the name of the attribute, or use the fully qualified name. –  Nov 30 '17 at 09:30
  • Got your point. – ramzan ali Nov 30 '17 at 09:36
  • 1
    *"Please be noted that I do not want to use fully qualified name or namespace alias or other Custome Attributes name."* These are your options. What's wrong with them? – Sefe Nov 30 '17 at 09:38

1 Answers1

4

You should rethink your approach of creating your own attribute with the same name. This is problematic for two reasons:

  1. Readers of your code might think it's the built-in attribute and not your own. They might get a misconception about what your code does. This is especially important for the AuthorizeAttribute, since security is a usually a critical issue in a web application
  2. You could run into naming conflicts. That's exactly what happended here.

You can resolve your issue in different ways:

Rename your attribute

A good solution - and the solution that I would recommend - would be to simply rename your custom attribute so that it's clear that it is yours and the naming conflict gets resolved.

Specify the namespace explicitly

If you want to keep the same name of the attribute, you can resolve the naming conflict by explicitly specifying your own namespace:

[ProjectDefaultNamespace.Authorize]

Use a namespace alias

You can also specify a namespace alias in your using list:

using MyAuthorizeAttribute = ProjectDefaultNamespace.AuthorizeAttribute;

And then apply it like:

[MyAuthorizeAttribute]

But then again, why not just giving it your own custom name? It will look the same in code, just without the additional complication of the alias.

Sefe
  • 13,731
  • 5
  • 42
  • 55
  • @Safe, thanks for your ans, it makes sense. I have gone through these solutions already. I just wanted to avoid them so that the other programmers who are used to use '[Authorize(Roles = "foo")] did not think about the new Custome Authorize name or about the new additional namespace. – ramzan ali Nov 30 '17 at 09:41
  • 2
    @ramzanali: If you create your own attribute, developers *will* have to think about that. Since there is no way around it, clarifying that with your own name, rather **helps** them with that. It's worse to keep developers in the dark by creating hidden functionalities. They have to understand the code that they're writing 100%. Adding hidden features doesn't help with that. – Sefe Nov 30 '17 at 09:43