You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the API supports adding mod only user flairs through the PUT /v1/community endpoint. This happens by setting the mod_only field to true when adding a flair to a community.
These flairs then get displayed, along the non mod only flairs, when calling the GET /v1/community endpoint and specifying mod_only=true as a query. However, further support is required.
Only mods should be able to view mod only flairs
Only mods should be able to assign mod only user flairs, either to themselves or to others
Only mods should be able to view mod only flairs
The get_community_flairs_api handler should look for an optional Authorization header, which would work similarly to the existing ones already set up for PUT and DELETE requests. If such a header is included, and if the resulting user is a mod (this can be checked with the already existing verify.rs/verify_mod function), then the list should return mod only flairs, otherwise it should return either a list of regular flairs or an "Unauthorized" error.
Only mods should be able to assign mod only user flairs
The put_user_flair_api handler already verifies the user's JWT. However, insertions of mod only flairs should only happen if the owner of the JWT is a mod.
The challenge here is to avoid calling the verify.rs functions more than once, as they rely on the Lemmy API and are thus pretty slow. This will likely require a major rewrite of the handler.
The text was updated successfully, but these errors were encountered:
Right now the API supports adding mod only user flairs through the
PUT /v1/community
endpoint. This happens by setting themod_only
field totrue
when adding a flair to a community.These flairs then get displayed, along the non mod only flairs, when calling the
GET /v1/community
endpoint and specifyingmod_only=true
as a query. However, further support is required.Only mods should be able to view mod only flairs
The
get_community_flairs_api
handler should look for an optionalAuthorization
header, which would work similarly to the existing ones already set up for PUT and DELETE requests. If such a header is included, and if the resulting user is a mod (this can be checked with the already existingverify.rs/verify_mod function
), then the list should return mod only flairs, otherwise it should return either a list of regular flairs or an "Unauthorized" error.Only mods should be able to assign mod only user flairs
The
put_user_flair_api
handler already verifies the user's JWT. However, insertions of mod only flairs should only happen if the owner of the JWT is a mod.The challenge here is to avoid calling the verify.rs functions more than once, as they rely on the Lemmy API and are thus pretty slow. This will likely require a major rewrite of the handler.
The text was updated successfully, but these errors were encountered: