New Hook `getPermission()`

As discussed in #12 we want to offer an option to harden the security of telefunctions. CC @redbar0n.

// server.js
// Enviroment: Node.js

import { telefuncConfig } from 'telefunc'
telefuncConfig.enforcePermissions = true

When enforcePermissions is set to true, all telefunctions need to use a hook called getPermission().

// *.telefunc.ts
// Enviroment: Node.js

import { getPermission } from 'telefunc'
import { allowEveryone, allowAuthor, allowAdmin } from './permissions'

export function hello() {
  getPermission(allowEveryone)
  // ...
}

export function updateTodo(id: string) {
  getPermission(() => allowAuthor(id))
  // ...
}

export function deleteUser(id: string) {
  getPermission(() => allowAdmin())
  // ...
}

// permissions.ts
// Enviroment: Node.js

// Permissions defined by the user.

export function allowEveryone() {
  // ...
}
export function allowAuthor(rowId: string) {
  // ...
}
export function allowAdmin() {
  // ...
}

@louwers thoughts?

[brillout]

Hmm, don’t like that a function called getPermission returns a todo.

It seems weird at first, but I think it does make sense. Not only practically, but also semantically: the permission function validates the object and returns it. One way to think of it is that whatever is returned by getPermission() is safe.

This is not type safe

Yes and the official recommendation is to return someValue instead, see https://telefunc.com/permissions. But there are some uses cases where throw Abort('someValue') is convenient and justifies its existence (e.g. to globally define authorization).

Note that throw Abort() (without arguments) is semantically correct though.

We could check all return statements in a telefunction. At least one of them must be PermissionDenied. We can add this value to Telefunc or let the user define it.

That’s an interesting idea and I do like it. Problem though: it’s not trivial to get all return statements for all stacks (Vite, Parcel, Webpack, …).

OR one of the call expressions must return never.

Neat idea. I like it. Also because our shieldGenrator already provides us with a TS AST. I wonder if TypeScript provides us with that information though:

// Can TS differentiate them?

async function telefunction1(): Promise<string> {
  return 'hello'
}

async function telefunction2(): Promise<string> {
  if (someCondition) {
    throw Abort()
  }
  return 'hello'
}

I’m not sure if I think a permission enforcement system even makes sense. Telefunctions are by default safe… If you don’t put any code in them. 😂

Maybe you’re right, seeing all the problems it causes, I’m thinking it may not be worth it.

How about we deprioritize this? We’ll see if users will push more on this 😃.

I still think enforcing permission functions to be a neat feature, but I’m coming to the conclusion there is no easy way to do a enforePermission thing.

We can leave it to the getContext() wrapper trick for the time being https://telefunc.com/permissions#getcontext-wrappers.

[brillout]

👍 Closing this in the meantime. Thanks for the neat discussion 😃.