Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ Ozone team member manager #2460

Merged
merged 38 commits into from
Jun 18, 2024
Merged

✨ Ozone team member manager #2460

merged 38 commits into from
Jun 18, 2024

Conversation

foysalit
Copy link
Contributor

@foysalit foysalit commented Apr 30, 2024

This PR adds lexicons for a full set of CRUD actions to manage team members with 3 predefined roles (that bluesky currently uses).

Right now, team members are maintained via environment variables. This PR will move the storage to a table in the database. In order to maintain backward compatibility

In order to keep members configured via env vars compatible with this implementation, on boot, we iterate over those and upsert into the table as needed.

Copy link
Collaborator

@bnewbold bnewbold left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

general direction looks good!

Comment on lines 35 to 36
"name": "ModeratorAlreadyExists",
"description": "The user is already a moderator"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably UserAlreadyExists and "already a moderator" if we have a specific role called "Moderator"?

"description": "The user being deleted is not a moderator"
},
{
"name": "LastAdmin",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe OnlyRemainingAdmin? "LastAdmin" would be confusing to me out of context

"defs": {
"main": {
"type": "procedure",
"description": "Add a user as moderator in the ozone service.",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good docs to mention in each of these descriptions what privileges are required to use the endpoint. Eg, all require auth, but maybe listUsers only requires an ozone user of any role?

@foysalit foysalit changed the title 🚧 Proposal for moderator manager lexicons ✨ Proposal for moderator manager lexicons May 8, 2024
@foysalit foysalit requested review from bnewbold and devinivy May 8, 2024 22:40
@foysalit foysalit changed the title ✨ Proposal for moderator manager lexicons ✨ Moderator manager May 13, 2024
Copy link
Collaborator

@devinivy devinivy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite the chunk of work! Good stuff, going to be a big upgrade 👍

lexicons/tools/ozone/moderator/addUser.json Outdated Show resolved Hide resolved
lexicons/tools/ozone/moderator/deleteUser.json Outdated Show resolved Hide resolved
lexicons/tools/ozone/moderator/deleteUser.json Outdated Show resolved Hide resolved
lexicons/tools/ozone/moderator/listUsers.json Outdated Show resolved Hide resolved
lexicons/tools/ozone/moderator/addUser.json Outdated Show resolved Hide resolved
packages/ozone/tests/moderators.test.ts Outdated Show resolved Hide resolved
packages/ozone/src/api/moderator/updateUser.ts Outdated Show resolved Hide resolved
packages/ozone/src/api/moderator/deleteUser.ts Outdated Show resolved Hide resolved
packages/ozone/src/api/moderator/addUser.ts Outdated Show resolved Hide resolved
packages/ozone/src/api/moderator/updateUser.ts Outdated Show resolved Hide resolved
@foysalit foysalit changed the title ✨ Moderator manager ✨ Ozone team member manager May 28, 2024
@foysalit foysalit requested a review from devinivy May 29, 2024 12:02
@foysalit
Copy link
Contributor Author

alright we should be close now. a few major things to review

  1. the auth-verifier now gives the serviceDid to always access as admin
  2. update and delete actions are no longer allowed on serviceDid
  3. moderator terminology has been updated everywhere with member instead
  4. profile hydration has been moved into the team service and applied on add, update and list endpoints
  5. profile views are no longer cached and always fetched from appview on demand

.orderBy('createdAt', 'asc')
.execute()

return { members, cursor: members.slice(-1)[0]?.createdAt.toISOString() }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return { members, cursor: members.slice(-1)[0]?.createdAt.toISOString() }
return { members, cursor: members.at(-1)?.createdAt.toISOString() }

updatedAt: now,
createdAt: now,
})
.onConflict((oc) => oc.column('did').doUpdateSet({ role }))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we maintain updatedAt and lastUpdatedBy here too?

Comment on lines 100 to 105
.updateTable('member')
.where('did', '=', did)
.set({
...updates,
updatedAt: updates.updatedAt || new Date(),
})
Copy link
Collaborator

@devinivy devinivy Jun 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a bit of a security issue here, since updates may contain fields not explicitly Picked out of Selectable<Member>, and they end up passed directly through to the query. For example, imagine if did were a field on updates.

Looking at the team.updateMember endpoint, I think the user could end-up successfully changing the user's createdAt time through the API. On its own that isn't a critical issue, but as we add new columns to the members table we might run into more sensitive issues.

Comment on lines 112 to 124
// Always allow serviceDid to access as admin
if (iss === this.serviceDid) {
return {
credentials: {
type: 'standard',
iss,
aud: payload.aud,
isAdmin: true,
isModerator: true,
isTriage: true,
},
}
}
Copy link
Collaborator

@devinivy devinivy Jun 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we could avoid this exception if we folded the account into seedInitialMembers(), particularly now that there's a guard on deleting the user.

Copy link
Collaborator

@devinivy devinivy Jun 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know, the more I think about it we may want to keep the deletion guard but not add any other exceptions for the service DID. I think there could be legitimate reasons for a deployment to not want to make the service DID a team member.

For the Ozone distribution we configure the service DID to be an admin anyway, so most deployments will have this by default. Perhaps the deletion rule should be to ensure you don't delete, demote, or disable yourself. That should be enough to ensure there's no way to lock yourself out, which I think is the main thing we're going for.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that makes sense!

Comment on lines 132 to 133
const { isAdmin, isModerator, isTriage } =
await this.teamService.getMemberRole(member)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const { isAdmin, isModerator, isTriage } =
await this.teamService.getMemberRole(member)
const { isAdmin, isModerator, isTriage } =
this.teamService.getMemberRole(member)

@bnewbold
Copy link
Collaborator

Looking forward to this! Let me know when I can give it a spin in staging.

@foysalit foysalit requested a review from devinivy June 12, 2024 21:11
@devinivy devinivy merged commit 3ad0519 into main Jun 18, 2024
10 checks passed
@devinivy devinivy deleted the mod-manager branch June 18, 2024 22:47
@github-actions github-actions bot mentioned this pull request Jun 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants