Skip to content
This repository has been archived by the owner on Jun 9, 2023. It is now read-only.

Ensure that the client always knows what the server permits #2269

Open
ojeytonwilliams opened this issue Jan 24, 2023 · 0 comments
Open

Ensure that the client always knows what the server permits #2269

ojeytonwilliams opened this issue Jan 24, 2023 · 0 comments
Labels
Discussion Ideas, feature requests, views on features. Anything which is a discussion.

Comments

@ojeytonwilliams
Copy link
Contributor

ojeytonwilliams commented Jan 24, 2023

The potential problem

It's possible for the client side checkPermission

export const checkPermission = (
user: UserContextType['user'],
requiredPermission: InstancePermission | ChapterPermission,
variableValues?: Record<string, number>,
) => {
if (!user) return false;
const context = { user, events: [], venues: [] };
return checker(context, requiredPermission, variableValues || {});

to fail when the server would allow a request. There are two ways it can fail when it should not

  1. It does not pass the correct variableValues
  2. It relies on events or venues

The first case isn't fundamental. If we're careful, it can be avoided. However, there are situations where the second case cannot be avoided.

For example, if a chapter administrator checks their permission

checkPermission(user, Permissions.EventEdit, { eventId: 1 })

this will fail even if they're an administrator of the chapter this event belongs to. This is because the checker function needs the chapterId to see if the administrator has the permission and it needs the list of events to get the chapterId.

The potential solutions

  1. make events + venues available to the client
  2. stop client side checking and, instead, query the server whenever the client needs to know what's allowed
  3. put events and venues inside the user object. That way checker can find chapterId just by inspecting `user

Option 3 seems like the cleanest solution to me, but I'd welcome any opinions before I try to implement this.

@ojeytonwilliams ojeytonwilliams added the Discussion Ideas, feature requests, views on features. Anything which is a discussion. label Jan 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Discussion Ideas, feature requests, views on features. Anything which is a discussion.
Projects
None yet
Development

No branches or pull requests

1 participant