Ability to force security context filter

[jessedobbelaere]

Is it possible to set a security context that is injected on each query that executes, so it's always setting or filtering on an attribute? For example, I have a multi-tenant setup where we always need to filter on the tenantId key.

A typical use case is for a central authorization module to add an accountId or userId to the context which is then used in keys for items belonging to that account or user. This is useful for multi-tenant applications.

table.setContext({
   userId: 'user-42'
})

In OneTable this is supported via setContext function, see here. I'm searching for similar functionality in Electrodb? Or perhaps some way to hook into the attributes (in a central place) before a query is executed?

[tywalch]

This is an interesting concept; I like it and see it's worth. I will keep this in mind as a new feature to implement!

My gut says an implementation could be the following:

• Add new .context() method for all queries/mutations
• Any subsequent usages of the attributes provided to .context() would be ignored (including usages of where)

[tywalch]

It looks like the OneTable implementation in your example would return another instance of table, and all usages of the returned table would have the "context" applied?

[jessedobbelaere]

Great to hear! Yes i assume it would affect the instance of the table.

As an example, we could create a singleton of the table and use a helper to set the scope:

export const myTable = new Table({...});

// This uses https://doc.onetable.io/api/table/contexts/
export const orgTenantScope = {
  setScope(identity: Identity) {
    myTable.setContext({ tenantId: identity.tenantId })
  },
  reset() {
    myTable.clearContext()
  },
}

And in an AWS Lambda handler, we should always set the right scope before doing any logic:

try {
    tenantScope.setScope(identity)
    // Handle the route
    ...
  } catch (error: any) {
  } finally {
    tenantScope.reset()
  }

Context properties take precedence over supplied properties. This is to prevent accidental updating of context keys.

So the orgId here cannot be overwritten or changed in downstream queries. Effectively enforcing the query to only filter on the data of the tenant that is making the request. Without it, we need to make sure every query contains the tenantId property.