Allow creating a model that does not 'allow' anyone.

[naedx]

Is your feature request related to a problem? Please describe.

I am creating a model that my users do not access directly. As such, I do not want to be forced to allow anyone.

Describe the solution you'd like

Either:

• simply deny by default if .authorization() is not called
• provide allow.nobody() as in .authorization((allow) => [allow.nobody()]) which allows the user to be explicitly deny access.

Describe alternatives you've considered

As a temporary workaround, I've chosen to use @auth(rules: [{allow: owner, ownerField: "_never_"}]) which is a field that wont be populated. I still see, however, that there is an unwanted field resolver defined automatically called MyModel_never_DataResolverFn.

    .authorization((allow) => [allow.ownerDefinedIn('_never_')]);

Additional context

Add any other context or screenshots about the feature request here.

[stocaaro]

Hello @naedx ,

Something must have access to this at some point, right? How are you granting permission for the indirect access you are supporting.

From what you describe, I would expect that you would have functions that would interact with your data which you would grant access to the schema.

const schema = a.schema(...).authorization(allow => [
    allow.resource(functionWithDataAccess).to(['query', 'listen'])
  ]);

You could also use a user group instead of an owner field, where you could maintain an empty user group to ensure no one has access. .authorization((allow) => [allow.group('nobody')]).

Any information on usecase that you can provide would be helpful as we keep this open for consideration. Glad its something you have found a workaround to support your usecase for now.

Thanks,
Aaron

[naedx]

Hi @stocaaro ,

Thanks for looking at this!

"Something must have access to this at some point, right? How are you granting permission for the indirect access you are supporting."

User Case 1

I have other models that are directly exposed to the users but I have a table that stores metadata that the user never directly interacts with. Their actions trigger operations on the hidden data source in pipelines. This is illustrated in the example below where there is an AuditLogTable that the user shouldn't even be aware of. Introspection is also disabled on the Api to help with this use case.

import { a, defineData, type ClientSchema } from '@aws-amplify/backend';

const schema2 = a.schema({
  Todo: a.model({
      content: a.string(),
      isDone: a.boolean()
    })
    .disableOperations(["update"])
    .authorization(allow => [allow.publicApiKey()]),

  AuditLog: a.model({
    userId: a.string(),
    action: a.string(),
  }),

  updateTodo: a.mutation()
    .arguments({
      input: a.customType({
        id: a.id(),
        content: a.string(),
        isDone: a.boolean()
      })
    })
    .returns(a.ref('Todo'))
    .handler([
      a.handler.custom( {
        dataSource: a.ref('Todo'),
        entry: esbuildHelper('./src/updateTodo.ts'),
      }),
      a.handler.custom({
        dataSource: a.ref('AuditLog'),
        entry: esbuildHelper('.src/auditLog.ts')
      }),
    ])
    .authorization(allow => [allow.authenticated()])
});

// esbuildHelper() builds .ts files into .js and returns its path to Amplify because developing in TS is just better...

[naedx]

And thanks for the .authorization((allow) => [allow.group('nobody')]) workaround! This is cleaner.

[naedx]

Use Case 2:

You have an application that uses the DynamoDB single-table design for the entire app or for a subset of the features. In this case, the users do not directly interact with the table that the model generates. Instead, they interact with the custom type and the corresponding custom operations.

const schema2 = a.schema({
  // ... other models
  
  TodoModuleData: a
    .model({
      pk: a.string().required(),
      sk: a.string().required(),
    })
    .identifier(['pk', 'sk'])
    .disableOperations(['mutations', 'queries', 'subscriptions']),

  Todo: a
    .customType({
      content: a.string(),
      isDone: a.boolean(),
    }),
    
  createTodo: a
    .mutation()
    .arguments({
      input: a.customType({
        id: a.id(),
        content: a.string(),
        isDone: a.boolean(),
      }),
    })
    .returns(a.ref('Todo'))
    .handler([
      a.handler.custom({
        dataSource: a.ref('TodoModuleData'),
        entry: esbuildHelper('./src/createTodo.ts'),
      }),
    ])
    .authorization((allow) => [allow.authenticated()]),

   // ...other operations
});

// esbuildHelper() builds .ts files into .js and returns its path to Amplify because developing in TS is just better...