Check and clean up endpoints access conditions
Activity
added Spec/discussion + 1 deleted label
mentioned in issue #348 (closed)
unassigned @vrigal
As a summer project, work will start on checking each endpoint one by one, updating all the relevant documentation, tests and fixing any bugs that may be found. This should be easier than just looking at the current state, documenting it in one giant table, and then making many changes repetitively—the table might end up out of date, or we might just find even more issues when working on the fixes.
I will create one issue for each API endpoint.
-
Endpoint checklist
- Does the endpoint use the proper permission classes?
- Does the endpoint check for access rights on the relevant objects (corpora, repositories, workers, …) using the ACL mixins?
- Does the endpoint check for the correct access levels on the relevant objects (corpora, repositories, workers, …)?
- Does the endpoint check for the relevant feature flags?
- Are the correct permission classes documented in OpenAPI?
ReDoc should display aAuthorizations:field with the possible authentication methods, but those do not mention if the endpoint requires a verified email or is restricted to admins or Ponos tasks - Are the correct required access rights documented in OpenAPI?
- Do the access rights match the documented access rights?
- Are there unit tests to check that each required permission, access right, user scope is actually required?
If we are going through every endpoint, we might as well check for other things:
- Is there any missing documentation on the endpoint's behavior?
- Is there any missing
help_textto add on the serializers to help users understand each field? - Is each request and response field properly typed?
- Are there any undocumented query parameters?
- Are there any special behaviors, such as uncommon error codes or errors with custom fields, that should be documented as response examples?
- Are there any other unit tests missing for this endpoint?
- Is the endpoint following the API best practices?
If the endpoint itself, the OpenAPI documentation or the unit tests need to be updated, open a merge request to make all the relevant updates on the endpoint, and document the applied changes in the merge request's description; for example
Updated OpenAPI docs and added check for internal users. If doc.arkindex.org needs to be updated, open a merge request on https://gitlab.com/teklia/arkindex/doc. Merge requests on arkindex/doc will not be merged before the next Arkindex release.If the necessary access rights are confusing or cannot be determined using the current documentation, ask before implementing anything, to require a proper discussion on which access rights should apply on this endpoint.
Edited by Erwan Rouchet mentioned in issue #1081
mentioned in issue #1082
mentioned in issue #1083
mentioned in issue #1085
mentioned in issue #1084
mentioned in issue #1086
mentioned in issue #1087
mentioned in issue #1088
mentioned in issue #1089
mentioned in issue #1090 (closed)
mentioned in issue #1091 (closed)
mentioned in issue #1092 (closed)
mentioned in issue #1093 (closed)
mentioned in issue #1094
mentioned in issue #1095
mentioned in issue #1096
mentioned in issue #1097
mentioned in issue #1098
mentioned in issue #1099
mentioned in issue #1100
mentioned in issue #1101 (closed)
mentioned in issue #1102 (closed)
mentioned in issue #1103 (closed)
mentioned in issue #1104 (closed)
mentioned in issue #1105 (closed)
mentioned in issue #1106 (closed)
mentioned in issue #1107
mentioned in issue #1108
mentioned in issue #1109
mentioned in issue #1110 (closed)
mentioned in issue #1111 (closed)
mentioned in issue #1112 (closed)
mentioned in issue #1113 (closed)
mentioned in issue #1114
mentioned in issue #1115
mentioned in issue #1116 (closed)
mentioned in issue #1117
mentioned in issue #1118
mentioned in issue #1119
mentioned in issue #1120
mentioned in issue #1121
mentioned in issue #1122
mentioned in issue #1123
