Session variables can now be used with operators like _in, _nin, _has_keys_any and _has_keys_all. For example you now now define such a permission:

{"org_id": {"_in": "x-hasura-allowed-org-ids"}}

and then provide x-hasura-allowed-org-ids from your authn layer in this format. This helps in cases where some of the information used in your authn layer is not part of the database but is derived from an external source.

Affected components

• Server
• Console
• Docs

Related Issues

#1333

Solution and Design

What we have in #1799 will not work with multiplexed subscriptions. So I had to change the implementation. The SQL generation changes from col IN (v1, v2 ..) to col = ANY (ARRAY[v1,v2 ..]::[v]).

Breaking changes

1. The type of input values for _in and _nin operators is previously [t] (t being the type of the column). It is now changed to [t!]. Note that even previously when you have a query with say {owner_id: {_in: [1, null]}}, you would only get rows where owner_id is 1 and not rows with owner_id set as NULL. This change makes the previous behaviour explicit.
2. Previously you can define a permission like {"org_id": {"_in": ["x-hasura-org-id1", "x-hasura-org-id2", ..]}. Such rules don't work as expected any more. The server only expects the session variable to be present only at the top level, for the above mentioned array operators.

Steps to test and verify

I'll update this once the console changes are in.

Limitations, known bugs & workarounds

The biggest limitation is that session variables are still a map of strings to strings. i.e, even arrays have to be expressed as strings as per Postgres's literal syntax for arrays ({1,2,3..}). This is purely an implementation limitation and requires a fair amount of work but will be lifted as soon as possible.

Notes to the reviewer

Previously we assumed that the type of a session variable is the type of the column. So, if you have a clause like {"user_id":{"_eq": "x-hasura-user-id"}, it implies that x-hasura-user-id should be of type, type(user_id). This changes. The type of a session variable now need not be that of column, for example, {"user_id":{"_in": "x-hasura-user-ids"}, the type of x-hasura-user-ids is type(user_id)[].

However our modelling of postgres types (PGColType) is very rudimentary, while it captures all possible types, we can't really construct a type say int[]. This has to be fixed and will be part of the PR which adds support for all possible types. However till then I introduced a new type called PgType which is either a simple type or an array type, a gross oversimplification of postgres types but will help us with this feature.