Closed alesgurd closed 2 months ago
I've added a pull request #22, however the implementation would deprecate the previous service to service auth implementation where you'd get the token from backend.auth.keys
on the app-config.yaml. Any feedback is appreciated, we had to run this fork on our instances because the time-saver plugin was appreciated by the team managers almost immediately.
Also, I wasn't able to make a decision on the version bumps to be performed, this could be a major update because even though the change is quite small, it would implicate deprecating the previous implementation. Please, provide feedback if possible.
Hey @alesgurd Thank you for your contribution. I will take a look on it soon. I need to think on backward compatibility.
If I'm reading the backstage docs correctly, service-to-service auth doesn't need a token configured:
Backstage plugins that use the new backend system and handle credentials using the auth and httpAuth service APIs are secure by default, without requiring any configuration. They generate self-signed tokens automatically for making requests to other Backstage backend plugins, and the receivers use the caller's public key set endpoint to be able to perform verification.
The existing implementation was giving us 401 errors locally, so I hacked in support for the recommended way:
This fixes the problem for us. I don't have time to make a PR right now, sorry!
Hello everyone,
Indeed, this solves the S2S communication using the new Backstage auth service. I was working around fixing other things ATM but I started bumping into this too, implementing the same fix momentarily before a PR.
I appreciate your input Riley and will be making these changes and a correspond PR asap.
My best,
Javier
On Jul 2, 2024, at 4:20 PM, Riley Martine @.***> wrote:
If I'm reading the backstage docshttps://backstage.io/docs/auth/service-to-service-auth#standard-plugin-to-plugin-auth correctly, service-to-service auth doesn't need a token configured:
Backstage plugins that use the new backend system and handle credentials using the auth and httpAuth service APIs are secure by default, without requiring any configuration. They generate self-signed tokens automatically for making requests to other Backstage backend plugins, and the receivers use the caller's public key set endpoint to be able to perform verification.
The existing implementation was giving us 401 errors locally, so I hacked in support for the recommended way:
Patch file for compiled time saver plugin
diff --git @./backstage-plugin-time-saver-backend/dist/index.cjs.js @./backstage-plugin-time-saver-backend/dist/index.cjs.js index a4d26f1..20801e6 100644 --- @./backstage-plugin-time-saver-backend/dist/index.cjs.js +++ @./backstage-plugin-time-saver-backend/dist/index.cjs.js @@ -338,9 +338,10 @@ class DatabaseOperations { }
class ScaffolderClient {
return token; let key = ""; let decodedBytes = ""; const keyConfig = config.getOptional("backend.auth.externalAccess"); @@ -406,15 +412,16 @@ class ScaffolderClient { }
class TimeSaverHandler {
START - Collecting Time Savings data from templates...}
);
let templateTaskList = [];
try {
@@ -423,6 +430,7 @@ class TimeSaverHandler {
return "FAIL";
}
await this.db.truncate(this.tsTableName);this.logger.info(Template task list: ${JSON.stringify(templateTaskList)}
);
templateTaskList = templateTaskList.filter(
(single) => single.status === "completed"
);
@@ -494,11 +502,12 @@ class ScaffolderDatabaseOperations {
}
class TsApi {
this.auth ).fetchTemplatesFromScaffolder(); for (let i = 0; i < taskTemplateList.length; i++) { const singleTemplate = taskTemplateList[i]; @@ -762,13 +772,14 @@ class ScaffolderDb { }
class TsScheduler {
This fixes the problem for us. I don't have time to make a PR right now, sorry!
— Reply to this email directly, view it on GitHubhttps://github.com/tduniec/backstage-timesaver-plugin/issues/21#issuecomment-2204325777, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOSYQIGKG6CWSLZKHTJ3D3ZKMDSTAVCNFSM6AAAAABHUMWBYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBUGMZDKNZXG4. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Provided new version 2.0.0 with the new auth service.
Thanks @ionSurf fro driving this change! Thanks all for your input!
We've adopted the timesaver plugin before updating our backstage instance and the backstage update brought a few issues with it. Where the backend is unable to communicate with the scaffolder api when service to service auth is enabled. Also, the frontend plugin is unable to communicate with the backend because the user credentials are missing on the request.
I think a way to approach this would be to read the configuration from the backend side to retrieve a static token to use against the scaffolder api, and moving away from the fetchWithCredentials implementation to the @backstage/core-plugin-api fetchApi which already injects the user credentials to the request.