@teamkeel/functions-runtime 0.331.0 → 0.333.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@teamkeel/functions-runtime",
-  "version": "0.331.0",
+  "version": "0.333.0",
   "description": "Internal package used by @teamkeel/sdk",
   "main": "src/index.js",
   "scripts": {

package/src/database.js

@@ -1,6 +1,27 @@
 const { Kysely, PostgresDialect } = require("kysely");
 const { AsyncLocalStorage } = require("async_hooks");
 const pg = require("pg");
+const { PROTO_ACTION_TYPES } = require("./consts");
+
+// withTransaction wraps the containing code with a transaction
+// and sets the transaction in the AsyncLocalStorage so consumers further
+// down the hierarchy can access the current transaction.
+// For read type operations such as list & get, no transaction is used
+async function withTransaction(db, actionType, cb) {
+  switch (actionType) {
+    case PROTO_ACTION_TYPES.GET:
+    case PROTO_ACTION_TYPES.LIST:
+      return dbInstance.run(db, async () => {
+        return cb({ transaction: db });
+      });
+    default:
+      return db.transaction().execute(async (transaction) => {
+        return dbInstance.run(transaction, async () => {
+          return cb({ transaction });
+        });
+      });
+  }
+}
 
 function mustEnv(key) {
   const v = process.env[key];
@@ -47,5 +68,5 @@ function getDatabase() {
   return db;
 }
 
-module.exports.dbInstance = dbInstance;
 module.exports.getDatabase = getDatabase;
+module.exports.withTransaction = withTransaction;

package/src/handleRequest.js

@@ -3,18 +3,11 @@ const {
   createJSONRPCSuccessResponse,
   JSONRPCErrorCode,
 } = require("json-rpc-2.0");
-const { getDatabase, dbInstance } = require("./database");
-const {
-  PERMISSION_STATE,
-  Permissions,
-  PermissionError,
-  checkBuiltInPermissions,
-  permissionsApiInstance,
-} = require("./permissions");
-const { PROTO_ACTION_TYPES } = require("./consts");
+const { getDatabase } = require("./database");
+const { tryExecuteFunction } = require("./tryExecuteFunction");
 const { errorToJSONRPCResponse, RuntimeErrors } = require("./errors");
 const opentelemetry = require("@opentelemetry/api");
-const { getTracer, withSpan } = require("./tracing");
+const { withSpan } = require("./tracing");
 
 // Generic handler function that is agnostic to runtime environment (local or lambda)
 // to execute a custom function based on the contents of a jsonrpc-2.0 payload object.
@@ -56,80 +49,29 @@ async function handleRequest(request, config) {
           meta: request.meta,
         });
 
+        // The Go runtime does *some* permissions checks up front before the request reaches
+        // this method, so we pass in a permissionState object on the request.meta object that
+        // indicates whether a call to a custom function has already been authorised
         const permitted =
           request.meta && request.meta.permissionState.status === "granted"
             ? true
             : null;
 
         const db = getDatabase();
-        const permissions = new Permissions();
-
-        const result = await permissionsApiInstance.run(
-          { permitted: permitted },
-          () => {
-            // We want to wrap the execution of the custom function in a transaction so that any call the user makes
-            // to any of the model apis we provide to the custom function is processed in a transaction.
-            // This is useful for permissions where we want to only proceed with database writes if all permission rules
-            // have been validated.
-
-            return db.transaction().execute(async (transaction) => {
-              return dbInstance.run(transaction, async () => {
-                // Call the user's custom function!
-                const customFunction = functions[request.method];
-                const fnResult = await customFunction(ctx, request.params);
-
-                // api.permissions maintains an internal state of whether the current operation has been *explicitly* permitted/denied by the user in the course of their custom function, or if execution has already been permitted by a role based permission (evaluated in the main runtime).
-                // we need to check that the final state is permitted or unpermitted. if it's not, then it means that the user has taken no explicit action to permit/deny
-                // and therefore we default to checking the permissions defined in the schema automatically.
-                switch (permissions.getState()) {
-                  case PERMISSION_STATE.PERMITTED:
-                    return fnResult;
-                  case PERMISSION_STATE.UNPERMITTED:
-                    throw new PermissionError(
-                      `Not permitted to access ${request.method}`
-                    );
-                  default:
-                    // unknown state, proceed with checking against the built in permissions in the schema
-                    const relevantPermissions = permissionFns[request.method];
-                    const actionType = actionTypes[request.method];
-
-                    const peakInsideTransaction =
-                      actionType === PROTO_ACTION_TYPES.CREATE;
-
-                    let rowsForPermissions = [];
-                    switch (actionType) {
-                      case PROTO_ACTION_TYPES.LIST:
-                        rowsForPermissions = fnResult;
-                        break;
-                      case PROTO_ACTION_TYPES.DELETE:
-                        rowsForPermissions = [{ id: fnResult }];
-                        break;
-                      default:
-                        rowsForPermissions = [fnResult];
-                        break;
-                    }
-
-                    // check will throw a PermissionError if a permission rule is invalid
-                    await checkBuiltInPermissions({
-                      rows: rowsForPermissions,
-                      permissionFns: relevantPermissions,
-                      // it is important that we pass db here as db represents the connection to the database
-                      // *outside* of the current transaction. Given that any changes inside of a transaction
-                      // are opaque to the outside, we can utilize this when running permission rules and then deciding to
-                      // rollback any changes if they do not pass. However, for creates we need to be able to 'peak' inside the transaction to read the created record, as this won't exist outside of the transaction.
-                      db: peakInsideTransaction ? transaction : db,
-                      ctx,
-                      functionName: request.method,
-                    });
-
-                    // If the built in permission check above doesn't throw, then it means that the request is permitted and we can continue returning the return value from the custom function out of the transaction
-                    return fnResult;
-                }
-              });
-            });
+        const customFunction = functions[request.method];
+
+        const result = await tryExecuteFunction(
+          { request, ctx, permitted, db, permissionFns, actionTypes },
+          async () => {
+            // Return the custom function to the containing tryExecuteFunction block
+            // Once the custom function is called, tryExecuteFunction will check the schema's permission rules to see if it can continue committing
+            // the transaction to the db. If a permission rule is violated, any changes made inside the transaction are rolled back.
+            return customFunction(ctx, request.params);
           }
         );
 
+        // Sometimes a custom function may be coded in such a way that nothing is returned from it.
+        // We see this as an error so handle accordingly.
         if (result === undefined) {
           // no result returned from custom function
           return createJSONRPCErrorResponse(

package/src/handleRequest.test.js

@@ -232,6 +232,10 @@ describe("ModelAPI error handling", () => {
 
     functionConfig = {
       permissionFns: {},
+      actionTypes: {
+        createPost: PROTO_ACTION_TYPES.CREATE,
+        deletePost: PROTO_ACTION_TYPES.DELETE,
+      },
       functions: {
         createPost: async (ctx, inputs) => {
           new Permissions().allow();

package/src/permissions.js

@@ -8,6 +8,16 @@ const PERMISSION_STATE = {
   UNPERMITTED: "unpermitted",
 };
 
+// withPermissions sets the initial permission state from the go runtime in the AsyncLocalStorage so consumers further down the hierarchy can read or mutate the state
+// at will
+const withPermissions = async (initialValue, cb) => {
+  const permissions = new Permissions();
+
+  return await permissionsApiInstance.run({ permitted: initialValue }, () => {
+    return cb({ getPermissionState: permissions.getState });
+  });
+};
+
 const permissionsApiInstance = new AsyncLocalStorage();
 
 class Permissions {
@@ -61,8 +71,9 @@ const checkBuiltInPermissions = async ({
   throw new PermissionError(`Not permitted to access ${functionName}`);
 };
 
-module.exports.permissionsApiInstance = permissionsApiInstance;
 module.exports.checkBuiltInPermissions = checkBuiltInPermissions;
 module.exports.PermissionError = PermissionError;
 module.exports.PERMISSION_STATE = PERMISSION_STATE;
 module.exports.Permissions = Permissions;
+module.exports.withPermissions = withPermissions;
+module.exports.permissionsApiInstance = permissionsApiInstance;

package/src/tryExecuteFunction.js

@@ -0,0 +1,72 @@
+const { withTransaction } = require("./database");
+const {
+  withPermissions,
+  PERMISSION_STATE,
+  PermissionError,
+  checkBuiltInPermissions,
+} = require("./permissions");
+const { PROTO_ACTION_TYPES } = require("./consts");
+
+// tryExecuteFunction will create a new database transaction around a function call
+// and handle any permissions checks. If a permission check fails, then an Error will be thrown and the catch block will be hit.
+function tryExecuteFunction(
+  { db, permitted, permissionFns, actionTypes, request, ctx },
+  cb
+) {
+  const actionType = actionTypes[request.method];
+
+  return withPermissions(permitted, async ({ getPermissionState }) => {
+    return withTransaction(db, actionType, async ({ transaction }) => {
+      const fnResult = await cb();
+
+      // api.permissions maintains an internal state of whether the current operation has been *explicitly* permitted/denied by the user in the course of their custom function, or if execution has already been permitted by a role based permission (evaluated in the main runtime).
+      // we need to check that the final state is permitted or unpermitted. if it's not, then it means that the user has taken no explicit action to permit/deny
+      // and therefore we default to checking the permissions defined in the schema automatically.
+      switch (getPermissionState()) {
+        case PERMISSION_STATE.PERMITTED:
+          return fnResult;
+        case PERMISSION_STATE.UNPERMITTED:
+          throw new PermissionError(
+            `Not permitted to access ${request.method}`
+          );
+        default:
+          // unknown state, proceed with checking against the built in permissions in the schema
+          const relevantPermissions = permissionFns[request.method];
+
+          const peakInsideTransaction =
+            actionType === PROTO_ACTION_TYPES.CREATE;
+
+          let rowsForPermissions = [];
+          switch (actionType) {
+            case PROTO_ACTION_TYPES.LIST:
+              rowsForPermissions = fnResult;
+              break;
+            case PROTO_ACTION_TYPES.DELETE:
+              rowsForPermissions = [{ id: fnResult }];
+              break;
+            default:
+              rowsForPermissions = [fnResult];
+              break;
+          }
+
+          // check will throw a PermissionError if a permission rule is invalid
+          await checkBuiltInPermissions({
+            rows: rowsForPermissions,
+            permissionFns: relevantPermissions,
+            // it is important that we pass db here as db represents the connection to the database
+            // *outside* of the current transaction. Given that any changes inside of a transaction
+            // are opaque to the outside, we can utilize this when running permission rules and then deciding to
+            // rollback any changes if they do not pass. However, for creates we need to be able to 'peak' inside the transaction to read the created record, as this won't exist outside of the transaction.
+            db: peakInsideTransaction ? transaction : db,
+            ctx,
+            functionName: request.method,
+          });
+
+          // If the built in permission check above doesn't throw, then it means that the request is permitted and we can continue returning the return value from the custom function out of the transaction
+          return fnResult;
+      }
+    });
+  });
+}
+
+module.exports.tryExecuteFunction = tryExecuteFunction;