...
Status colour Blue title In Progress Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1218 A fresh ticket is probably in order here. I’m not clear on the final proposed solution, and where we need monitoring along the way, but this definitely adds complexity to our authentication, and I think there is a simpler way.
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1181 Not sure if this has any additional useful context, or is redundant and should be forgotten.
Status colour Green title In FC-18 Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-107 AUTHENTICATION_CLASSES
is a default setting for DRF endpoints.This would enable the use of JwtAuthentication from most edx-platform DRF endpoints.
DRF endpoints that override the default should be reviewed to see if the override can be deleted, once there is a sane default.
Order is an open question: JwtAuthentication before or after SessionAuthentication?
Unfortunately, due to differences noted in DEPR(#165), order matters.
Also, order matters until ARCHBOM-1218 is implemented.
For rollout, propose to add a custom version of BasicAuthentication in edx-platform that adds some monitoring to see how and if it is used in Production.
It would be good to drop BasicAuthentication from the defaults if we don’t actually want it.
https://github.com/openedx/edx-drf-extensions/issues/332Status colour Green title In FC-18 Status colour Green title In FC-18
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1183 https://github.com/openedx/public-engineering/issues/165
This may be complicated without further product input, but maybe the solution can be readied regardless.
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1074 Adding an endpoint to LMS to expose the public signing keys. (Unticketed)
This would simplify key rotation. It came up at 2U for non-Open edX platform applications that may use the JWT cookie for SSO.
...
https://github.com/openedx/edx-drf-extensions/issues/333Status colour Green title In FC-18 New implementation ticket for https://github.com/openedx/public-engineering/issues/83
This would simplify authentication and maintenance, but wouldn’t necessarily add functionality.
https://github.com/openedx/edx-drf-extensions/issues/327Status colour Green title In FC-18 https://github.com/openedx/public-engineering/issues/189
Related: For some of the past removal work, the new api client wasn’t used, and instead a straight requests object was used and worked with the user’s JWT for service-to-service calls.
The intention was not to add this functionality to the new client, because it was thought that the client credentials token should be used instead.
If feels like we should have an ADR that clarifies what should be used where, and potentially enhances the client if we wish to allow for other ways of using it.
The client also provided shared observability, but that only works when it is used.
https://github.com/openedx/edx-drf-extensions/issues/284
To be considered.
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1172 A DEPR should be created for this.
Probably requires working in Prospectus.
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1077 Related?
(“unfinished”)Jira Legacy server System JIRA serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key ARCHBOM-1168
...