Determine plan on how to fetch security bugs
armenzg opened this issue · comments
Currently we can only fetch public bugs.
@dylan says that the easiest would be "if [the app] was served by bmo itself; it could use the login cookie."
Cons to the proposal above:
it would break the development model for the SPA. The only way to test the SPA is by having to build the artifacts and place them under the bmo repo to test it there. It breaks the ability to do hot reloading the SPA
dylan:
fair enough, We develop with hot reloading too, and for this I bet it would just be a matter of mounting $(pwd) to container:public/ But if it was my SPA I'd just have a mode that did unauthenticated requests when running under a non-BMO hostname.
Alternatively:
The options are following the BMO api key flow -- which requires receiving a POST with the user's API key, or possibly we can add more APIs to the oauth scope (bmo is an oauth2 provider, you'd need to get a client key and client secret from us)
https://bmo.readthedocs.io/en/latest/integrating/auth-delegation.html
API keys came from at time / set of requirements that pretty much prevent client-side-only auth.
oauth2 exists now, but we have not added any scopes for bug data so that would need to be done our side.
From dylan: file a bug in BMO :: General, list the APIs you use and mention we need to define oauth2 scopes for those. A separate bug can be filed to request a client secret and client id.
From kang:
An SPA can authenticate with auth0, and the user could be coming from various IdPs but that does not include a bugzilla api key, or a bugzilla access token that allow bugzilla api access - these are issued by bugzilla, in bugzilla - auth0 has no control over them.
When an API uses auth0 to also do API access, then because we use the same authorizer for SSO and APIs in the backend, an SPA is able to request tokens for both at the same time and use these to access the application's API which would be the case with task cluster for example
If bugzilla would like to front their API with our authorizer to allow for this we'll help them do that of course, but I don't know if they want.
Alternatively, Bugzilla could implement the oauth2 consent flow and your SPA, after the user has logged in, you do an additional request for the user to consent from Bugzilla to access their API, where Bugzilla would then deliver an additional access token they control for your SPA (which would require the user to also login into bugzilla, not just SSO - because Bugzilla does not use SSO logins).
The consent flow being this thing when a website tells you "Website X wants to access Z on your behalf" or here "Armen's SPA wants to access your Bugzilla bugs" and you have to click yes/no