backstage: 🐛 Bug Report: Unable to use a different name for the Authorization token
📜 Description
We use an external authorization layer on our ingresses, and configured oauthProxy as the auth provider.
While some plugins properly implement the FetchMiddlewares.injectIdentityAuth method, which allows us to use a custom header name, there are multiple places in code where we assume the name of the header is ‘Authorization’ (examples: https://github.com/search?q=repo%3Abackstage%2Fbackstage+“Authorization%3A+`Bearer”+language%3ATypeScript+path%3A&type=code) - techdocs, catalog being the most striking.
LE: this is by design. Fronted plugins must use fetchAPI while backend plugins must pass an Authorization header. The bug scope is reduced to only fronted plugins.
👍 Expected behavior
All frontend API requests should use the configurable fetchAPI so that the header name can be configured and not overlap with other authentication layers.
👎 Actual Behavior with Screenshots
Authorization header is (sometimes) hardcoded
👟 Reproduction steps
Try to change the name of the Authorization header.
📃 Provide the context for the Bug.
No response
🖥️ Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?
- I checked and didn’t find similar issue
🏢 Have you read the Code of Conduct?
- I have read the Code of Conduct
Are you willing to submit PR?
Yes I am willing to submit a PR!
About this issue
- Original URL
- State: open
- Created 4 months ago
- Comments: 15 (14 by maintainers)
I’ve got a PR for updating the Azure DevOps, DevTools, and Linguist plugins 👍
https://github.com/backstage/backstage/pull/23046 (this has been on my todo list for a bit now and I wanted to make these changes myself to better understand)
@freben Thoughts on a new
eventSourceApithat usesEventSourcePolyfillunder the hood forplugins/catalogandplugins/scaffolder(to be used for other SSE’s as well)?On a bit of a separate note, might it be worth moving some of that backend complexity to an abstracted backend implementation of
fetchApi? Rugvip added some thoughts in the BEP around that, https://github.com/backstage/backstage/blob/master/beps/0003-auth-architecture-evolution/README.md?plain=1#L319-L324, but I’d be curious to see if this is something we can revisit especially as we start adding more to the service-to-service request layer. This would also hopefully save us entirely from passing the token into the client for just backend requests and we could move towards thepluginId://{path}format consistently that’s existed for a while but stayed generally unused. Might be follow on work after the BEP/implementation lands.@alexef For the
CatalogClient, yes, we shouldn’t be passing token when this is used in the frontend. I’m not sure if this a restriction we can enforce, but it should generally not be happening. For thePermissionClient, I think this should be updated to follow the pattern inCatalogClient(allowing an override for thefetchimplementation it uses instead of just usingcross-fetch).For PRs, I’d recommend splitting it into 2 pieces, the
PermissionClientupdates and the frontendfetchApiupdates. @awanlin is a speed demon and already hopped on his plugins 😁 .@alexef Yup, should be #22603, must have accidentally deleted the last digit. And yes, you’re correct, the frontend should use
fetchApiand the backend should continue to use Authorization. Backend traffic shouldn’t leave the pod, but some users may have split backends with traffic going between pods.We’d love your help in making that frontend consistency happen!
As which particular fetch? 😉
yeah I see the catalog client actually uses global.fetch as its input type but uses cross-fetch as the default actual fallback implementation
For backend, yeah.
The deal for the catalog has been
node-fetchand supply tokens to each individual call.Now with the new auth work we’re doing, we’ll see if that backend picture shifts or not 😃