AuthorizationHandler: where TResource : class requirement

[brockallen]

Is this necessary? I want it to be an int.

[brockallen]

For more info, I want to build this:

public class AlbumOperations : IAuthorizationRequirement
{
    public static readonly AlbumOperations Edit = new AlbumOperations();
    public static readonly AlbumOperations Delete = new AlbumOperations();
}

public class AlbumOperationsHandler : AuthorizationHandler<AlbumOperations, int>
{
    AlbumService _albumService;

    public AlbumOperationsHandler(AlbumService albumService)
    {
        _albumService = albumService;
    }

    protected override void Handle(AuthorizationContext context, AlbumOperations requirement, int resource)
    {
        var album = _albumService.GetAlbum(resource);

        if (requirement == AlbumOperations.Edit)
        {
            // ...
        }
    }
}

[HaoK]

@blowdart So the class constraint was mostly to allow us to do a comparison against null and not call through to the handler if no resource was provided. We could switch the check to be against the default(TResource), but that would block int 0 which isn't good. Or we could just always call through again, but then resource would potentially be null again which was something we fixed previously...

Thoughts?

[blowdart]

0 could be a valid id I guess. Ouch, Is there no way to check if the resource is, in fact, nullable? Or is a value type?

[HaoK]

That's what the class constraint was for, but it blocks using value types as resources...

[blowdart]

https://msdn.microsoft.com/en-us/library/ms366789.aspx ? Then can block null on nullable types. Or am I missing something?

[brockallen]

Well, if it's a reference type then do the null check and short circuit the handler. If it's a value type, I'd say call thru with whatever resource value was provided. Or am I missing something?

[HaoK]

Meh, this is pretty gross to use reflection, yes this works but I'd almost rather let a null resource request go through, its not technically wrong is it? Resource is an optional parameter for us in general, its up to us to define the contract for this sugar, so its valid for us to just say the resource can be null when we call the abstract method...

[HaoK]

Basically our check will simply be call the handler if resource is TResource as opposed to being a TResource AND not null

[HaoK]

@brockallen I'm not convinced we shouldn't call through even with a null resource is my main question

[brockallen]

Ok, i'm cool with that :)

You could interpret those semantics as a policy check, in a sense.

[blowdart]

Yea null works for me, it'd be nicer than having to new up an instance of a class if you wanted to use it in views.

[HaoK]

Actually looks like the is check blocks nulls still :) So I guess that's sufficient then...

ints always flow through... and reference type nulls are blocked...