AuthorizeAttribute(IEnumerable<Claim>) doesn't make sense

[Praburaj]

From @victorhurdugaci on April 29, 2014 20:42

The constructor overload for AuthorizeAttribute taking an IEnumerable as argument doesn't make sense because .NET expects all attribute arguments to be compile time constants.

cc @sebastienros

Copied from original issue: aspnet/Security#9

[Praburaj]

From @sebastienros on May 5, 2014 21:35

We should move this issue to WebFX. I agree we need an overload with a single claim, but multiple ones do make sense in the sense they represent a logical OR.

[Praburaj]

Moving this bug to MVC as it belongs to MVC.

[rynowak]

/cc @sebastienros

You can use this constructor if you're defining a derived class what expects specific claims. There's no legacy/back-compat concern here since neither of our old AuthorizeAttribute implementations had constructor parameters.

[rynowak]

Also, since AuthorizeAttribute is a filter, you can manually construct it and add it as a global filter. Seems like we should leave this around.

[yishaigalatzer]

I agree with @rynowak in general, and that was the original intent. Either way we are rewriting the authorize attribute and this overload will does not fit in the new design see #1664.

@HaoK

[sebastienros]

Yeah !