Skip to content

fix(bulk-import): fix gitlab oauth flow#2765

Merged
dzemanov merged 1 commit intoredhat-developer:mainfrom
dzemanov:bulk-import-fix-gitlab-oauth-flow
Apr 16, 2026
Merged

fix(bulk-import): fix gitlab oauth flow#2765
dzemanov merged 1 commit intoredhat-developer:mainfrom
dzemanov:bulk-import-fix-gitlab-oauth-flow

Conversation

@dzemanov
Copy link
Copy Markdown
Member

Hey, I just made a Pull Request!

Fixed GitLab OAuth flow for on behalf of the signed-in user

✔️ Checklist

  • A changeset describing the change and affected packages. (more info)
  • Added or Updated documentation
  • Tests for new functionality and regression tests for bug fixes
  • Screenshots attached (for UI changes)

Signed-off-by: Dominika Zemanovicova <dzemanov@redhat.com>
@rhdh-qodo-merge
Copy link
Copy Markdown

Review Summary by Qodo

Fix GitLab OAuth token configuration in bulk-import backend

🐞 Bug fix

Grey Divider

Walkthroughs

Description
• 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
Diagram
flowchart LR
  A["GitLab API Config"] -->|"Changed token to oauthToken"| B["OAuth Flow Fixed"]
  B -->|"Enables user delegation"| C["Signed-in User Auth"]
Loading

Grey Divider

File Changes

1. workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts 🐞 Bug fix +1/-1

Update GitLab API token parameter to oauthToken

• Changed GitLab API initialization parameter from token to oauthToken
• Fixes OAuth flow to properly authenticate on behalf of signed-in user
• Single line change in buildGitlab function

workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts


2. workspaces/bulk-import/.changeset/curvy-schools-fold.md 📝 Documentation +5/-0

Add changeset for GitLab OAuth fix

• Added changeset file documenting the bug fix
• Marks package as patch version bump
• Describes the GitLab OAuth flow fix

workspaces/bulk-import/.changeset/curvy-schools-fold.md


Grey Divider

Qodo Logo

@rhdh-qodo-merge
Copy link
Copy Markdown

rhdh-qodo-merge Bot commented Apr 14, 2026

Code Review by Qodo

🐞 Bugs (1)   📘 Rule violations (0)   📎 Requirement gaps (0)
🐞\ ≡ Correctness (1)

Grey Divider


Action required

1. Auth mode hard-coded 🐞
Description
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.
Code

workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts[R43-46]

  const apiThing = new Gitlab({
    host: baseUrl,
-    token: input.credential.token,
+    oauthToken: input.credential.token,
  });
Evidence
The PR changes Gitbeaker client initialization to always use oauthToken (glUtils). Elsewhere,
integration credentials are created from integrations.gitlab[].token and represented with an
Authorization Bearer header (GitlabAppManager), while tests show credential objects also carry a
type: 'token' field and error modeling hard-codes type: 'token' (utils.ts, tests), indicating
that non-OAuth token typing exists in the system. Additionally, repository listing explicitly
requires user OAuth tokens (router.ts), meaning the service mixes user OAuth tokens and
integration-config credentials—so buildGitlab should select the appropriate auth mechanism rather
than hard-coding one.

workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/glUtils.ts[29-48]
workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/GitlabAppManager.ts[30-49]
workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/gitlabApiService.test.ts[46-70]
workspaces/bulk-import/plugins/bulk-import-backend/src/gitlab/utils/utils.ts[41-54]
workspaces/bulk-import/plugins/bulk-import-backend/src/service/router.ts[289-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@rhdh-gh-app
Copy link
Copy Markdown

rhdh-gh-app Bot commented Apr 14, 2026

Changed Packages

Package Name Package Path Changeset Bump Current Version
@red-hat-developer-hub/backstage-plugin-bulk-import-backend workspaces/bulk-import/plugins/bulk-import-backend patch v7.2.1

@sonarqubecloud
Copy link
Copy Markdown

Comment on lines 43 to 46
const apiThing = new Gitlab({
host: baseUrl,
token: input.credential.token,
oauthToken: input.credential.token,
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

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

Copy link
Copy Markdown
Member

@PatAKnight PatAKnight left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@openshift-ci openshift-ci Bot added the lgtm label Apr 15, 2026
@dzemanov dzemanov merged commit b3a0333 into redhat-developer:main Apr 16, 2026
10 checks passed
@dzemanov dzemanov deleted the bulk-import-fix-gitlab-oauth-flow branch April 16, 2026 12:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants