Ozone ACLs #2252
Ozone ACLs #2252
Conversation
| creds.credentials.type === 'mod_service' || | ||
| (creds.credentials.type === 'standard' && | ||
| this.isModService(creds.credentials.iss)) |
There was a problem hiding this comment.
Making sure I understand correctly—this means the mod service can view takedowns either:
- as a mod service, using the mod service signing key (also used for e.g. signing labels).
- as an actor, using their repo signing key.
Does that sound right? If so, when does the latter come into play?
There was a problem hiding this comment.
Yup that does sound right - maybe it could be communicated better.
But the latter comes into play on some of the view routes where we still want to show taken down content - getProfile for instance
There was a problem hiding this comment.
We could use a separate authVerifier there like optionalStandardOrModService but I thought it was a bit clearer to just use optionalStandard and then do a follow on check to see if it came from a trusted did
packages/ozone/src/auth-verifier.ts
Outdated
|
|
||
| type NullOutput = { | ||
| credentials: { | ||
| type: 'null' |
There was a problem hiding this comment.
I struggle a little bit with the string 'null' here, mostly because I wonder whether it's a typo when I read checks like credentials.type === 'null'.
I like keeping a string here so there's a value to discriminate credentials on. This covers the case where the user did not bring any credentials: would 'none' work?
packages/bsky/src/auth-verifier.ts
Outdated
| const { iss, aud } = await this.verifyServiceJwt(reqCtx, { | ||
| aud: this.ownDid, | ||
| iss: [this.adminDid], | ||
| iss: [this.modServiceDid, `${this.modServiceDid}#atproto_mod`], |
There was a problem hiding this comment.
I think #atproto_mod is the id of the key. Do we want to use the id of the service here, map it to the id of the key when verifying?
There was a problem hiding this comment.
Yup we chatted about this - I changed this to be the serviceId to keep it inline with possible future updates 👍
| admins: string[] | ||
| moderators: string[] | ||
| triage: string[] |
There was a problem hiding this comment.
I have a hunch we'll end-up wanting to toss these in the database before long, but seems like this is the right place to start 👍
packages/pds/src/auth-verifier.ts
Outdated
| throw new AuthRequiredError('Untrusted issuer', 'UntrustedIss') | ||
| } | ||
| const payload = await this.verifyServiceJwt(reqCtx, { | ||
| aud: this.dids.entryway ?? this.dids.pds, | ||
| iss: [this.dids.admin], | ||
| iss: [this.dids.modService, `${this.dids.modService}#atproto_mod`], |
There was a problem hiding this comment.
We might consider using the service id rather than the key id for the issuer here.
| dbPostgresSchema: 'pds_admin_auth', | ||
| dbPostgresSchema: 'pds_moderator_auth', |
There was a problem hiding this comment.
I appreciate the rebrand from "admin" to "moderator" 👍
add runit to the services/bsky Dockerfile
* Allow tags to lead with and contain only numbers * Break tags on other whitespace characters * Export regexes from rich text detection * Add test * Add test * Disallow number-only tags * Avoid combining enclosing screen chars * Allow full-width number sign * Clarify tests * Fix punctuation edge case * Reorder * Simplify, add another test * Another test, comment
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* ozone delegates email sending to user's pds * lexicon: add content field to mod email event * test email sending via mod event
Switches out basic auth for ACLs in Ozone backend.
Supersedes #2058 but broken up such that it does not introduce breaking changes