fix(bulk-import): fix gitlab oauth flow#2765
Conversation
Signed-off-by: Dominika Zemanovicova <dzemanov@redhat.com>
Review Summary by QodoFix GitLab OAuth token configuration in bulk-import backend
WalkthroughsDescription• Fixed GitLab OAuth flow by using oauthToken instead of token • Enables proper authentication on behalf of signed-in user • Added changeset documenting the patch release Diagramflowchart LR
A["GitLab API Config"] -->|"Changed token to oauthToken"| B["OAuth Flow Fixed"]
B -->|"Enables user delegation"| C["Signed-in User Auth"]
File Changes1. workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts
|
Code Review by Qodo
|
Changed Packages
|
|
| const apiThing = new Gitlab({ | ||
| host: baseUrl, | ||
| token: input.credential.token, | ||
| oauthToken: input.credential.token, | ||
| }); |
There was a problem hiding this comment.
1. Auth mode hard-coded 🐞 Bug ≡ Correctness
buildGitlab now always passes credential.token as Gitbeaker oauthToken, ignoring that credentials in this codebase can be typed as 'token' and/or include explicit headers. This forces all GitLab calls (including those using integration-config credentials) down the OAuth/Bearer path, which can break call paths that require non-OAuth token semantics and lead to authentication failures.
Agent Prompt
## Issue description
`buildGitlab` always constructs the Gitbeaker client with `oauthToken`, regardless of what kind of credential it receives. The codebase can represent credentials with a `type` field (e.g. `'token'`) and/or explicit headers, and it also uses both user-scoped OAuth tokens and integration-config tokens.
## Issue Context
Hard-coding `oauthToken` forces all GitLab calls down a single auth mode and risks breaking integrations that expect non-OAuth token handling.
## Fix Focus Areas
- workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts[31-47]
- workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/GitlabAppManager.ts[30-49]
## Suggested fix
- Update `buildGitlab` to choose the Gitbeaker auth option based on the credential shape:
- Prefer `input.credential.type` if present (e.g., `type === 'oauthToken'` -> `oauthToken`, otherwise -> `token`).
- If `type` is absent, infer from `input.credential.headers` (e.g., `Authorization: Bearer ...` -> `oauthToken`) and fall back to `token`.
- Keep behavior for user tokens (Bearer/OAuth) while preserving compatibility for non-OAuth tokens.
- Add/adjust a unit test around `buildGitlab` (or an integration-style test using the constructor mock) to assert the right constructor option is used for both cases.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
PatAKnight
left a comment
There was a problem hiding this comment.
I tested with the PR/MR flow and the scaffolder template flow. Did not try the orchestrator workflow flow but I would assume that it works the same
/lgtm



Hey, I just made a Pull Request!
Fixed GitLab OAuth flow for on behalf of the signed-in user
✔️ Checklist