Feature request: Promises in ability conditions

Abilities allow using functions in the conditions of abilities, such as:

can('update', 'Post', { userId: function(id) { return id === 5 } });

Would it be possible to extend this API to also support promises? This would be handy for cases like querying databases, which return a promise.

Test example:

class Post {
    constructor(props) {
        Object.assign(this, props)
    }
}
function standardUser()
{
    return AbilityBuilder.define(
        (can, cannot) =>
        {
            can('update', 'Post', { userId: Promise.resolve(true) });
        }
    );
}

const abilities = standardUser();

console.log(abilities.can('update', new Post({userId: 5})));

Right now this evaluates to false because it doesn’t recognize promises.

[RedShift1]

Let’s say you have users and devices, and users have access to one or more devices. The relationship between users and their devices is stored in a table in a database. You have some data about those devices stored in Redis and want to protect this function:

function doRead(data) // data is user input
{
    return redis.get(`somekey:${data.device}`);
}

It would work as follows (pseudo code):

const ability = AbilityBuilder.define(
    (can, cannot) =>
    {
        can('read', 'SomekeyRequest',
            {
                device: function(device) // Function that returns a Promise
                    {
                        return db.query(`SELECT COUNT(*) AS cnt FROM userDevices WHERE deviceId = ${device}`)
                            .then(resultSet => resultSet.cnt > 0);
                    }
            }
        );
    }
);

function doRead(data)
{
    return ability.can('read', data)
        .then(
            (authz) =>
            {
                if(!authz)
                    throw 'Unauthorized';
                else
                    return redis.get(`somekey:${data.device}`);
            }
        );
}

[JaneJeon]

I would REALLY like to see this idea dropped.

For reference, I built https://github.com/JaneJeon/objection-authorize which is built on top of a competing access control library, https://github.com/tensult/role-acl.

The developer of role-acl suddenly one day “added” the ability to have an async function in conditions, and that meant literally every method had to be changed to async.

And that broke everything needlessly. And that’s actually the main reason why I’m looking to migrate my library to using casl instead.

I feel that you SHOULDN’T have async conditions to “query the database”. If you need something async, you should put it OUTSIDE the actual ability condition checks - provide all of the information necessary to make a decision to the ability builder in forms of context objects. In addition, you almost always want the frontend to share the same ability class that’s used in the backend so you can limit the UI based on the ACL, but if you’re “querying the database” from the frontend, you’re literally BEGGING to be hacked.

You don’t need async conditions, so the benefits are nil to begin with, and if you do “add” this “feature”, it will break everyone’s code. BAD IDEA.

@stainly I hope to dear god that you don’t consider this. It’s far more changes than you’d think for basically no benefit.