The security breach that was found in the Kelvin API found its way into the ucsschool-apis App as well, since it was derived from Kelvin. It needs to be fixed here as well. This is not a big problem since the App was never released yet.
Fixed in oschwieg/53534
QA: nok confirm bug =========== I try to do QA with buildingslogin, the wrong tokens come from a kelvin server - get/build wrong token - Fetch a token from kelvin server - access protected resource on http://localhost:8080/ucsschool/apis/bildungslogin/user/demo_student'' \ - see success - => {"id":"demo_student","licenses":["foo-123","bar-456"],"context":{"DEMOSCHOOL":{"classes":["Democlass"],"roles":["student"]}}} Fix on branch ============= - build new image? done - adapt plugin # THIS FEELS WRONG - get/build wrong token - fetch from kelvin - access protected resource, see fail = =>{"detail":"Could not validate credentials"} - get/build correct token - access protected resource - =>{"id":"demo_student","licenses":["foo-123","bar-456"],"context":{"DEMOSCHOOL":{"classes":["Democlass"],"roles":["student"]}}} It works in principle, but maybe it would be better if the plugins wouldn't need adaption. Suggestion: rename oauth2_scheme->something_else, get_token -> oauth2_schema
I would argument the other way around: The ucsschool-apis App is not released yet, hence also the plugins are not released yet and completely in development. If we implement your suggested change we get a difference between the Kelvin and ucsschool-apis code. If we someday merge the shared code for auth (which is still intended) we get the discrepancy and need to adapt one or the other then.
Your argument about the discrepancy between kelvin and ucsschool-apis wins. QA: ok
QA was ok, I ment to set it to verified -> verified fixed
*** Bug 54075 has been marked as a duplicate of this bug. ***