feat(bitbucketdatacenter): allow service accounts to not require user setup

[Ru13en]

📝 Description of the Change

Previously, using project or repository HTTP scoped tokens required configuring an associated user, even when the token already provided the necessary access context.
This PR removes the requirement to configure a user when using HTTP tokens from project and repository scopes.
It updates authentication flow to rely directly on the scoped token context, when only token is provided.
Related validation and tests were adjusted accordingly

🔗 Linked GitHub Issue

Fixes #
#2685

🧪 Testing Strategy

• Unit tests
• Integration tests
• End-to-end tests
• Manual testing
• Not Applicable

🤖 AI Assistance

AI assistance can be used for various tasks, such as code generation,
documentation, or testing.

Please indicate whether you have used AI assistance
for this PR and provide details if applicable.

• I have not used any AI assistance for this PR.
• I have used AI assistance for this PR.

Important

Slop will be simply rejected, if you are using AI assistance you need to make sure you
understand the code generated and that it meets the project's standards. you
need at least know how to run the code and deploy it (if needed). See
startpaac to make it easy
to deploy and test your code changes.

If the majority of the code in this PR was generated by an AI, please add a Co-authored-by trailer to your commit message.
For example:

Co-authored-by: Claude noreply@anthropic.com

✅ Submitter Checklist

• 📝 My commit messages are clear, informative, and follow the project's How to write a git commit message guide. The Gitlint linter ensures in CI it's properly validated
• ✨ I have ensured my commit message prefix (e.g., fix:, feat:) matches the "Type of Change" I selected above.
• ♽ I have run make test and make lint locally to check for and fix any
  issues. For an efficient workflow, I have considered installing
  pre-commit and running pre-commit install to
  automate these checks.
• 📖 I have added or updated documentation for any user-facing changes.
• 🧪 I have added sufficient unit tests for my code changes.
• 🎁 I have added end-to-end tests where feasible. See README for more details.
• 🔎 I have addressed any CI test flakiness or provided a clear reason to bypass it.
• If adding a provider feature, I have filled in the following and updated the provider documentation:
  • GitHub App
  • GitHub Webhook
  • Gitea/Forgejo
  • GitLab
  • Bitbucket Cloud
  • Bitbucket Data Center

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Ru13en / name: Ruben Rodrigues (afb412f)

[gemini-code-assist]

Code Review

This pull request updates the Bitbucket Data Center provider to allow authentication without an explicitly defined user by falling back to a direct repository URL request for token validation. Feedback from the review highlights a critical need for a nil check on the repository object to prevent runtime panics. Furthermore, the current error handling logic needs refinement to avoid malformed error strings when wrapping nil errors and to provide more accurate messaging when the user field is empty.

[mathur07]

/lgtm
cc: @zakisk @theakshaypant

[zakisk]

/ok-to-test

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 85.71429% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.54%. Comparing base (529a725) to head (279d636).

Files with missing lines	Patch %	Lines
...rovider/bitbucketdatacenter/bitbucketdatacenter.go	85.71%	2 Missing and 1 partial ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2726      +/-   ##
==========================================
+ Coverage   59.53%   59.54%   +0.01%     
==========================================
  Files         209      209              
  Lines       20720    20734      +14     
==========================================
+ Hits        12335    12346      +11     
- Misses       7612     7614       +2     
- Partials      773      774       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zakisk]

@Ru13en what do you mean by service account? do you mean repo http access token as you added in PR description?

[Ru13en]

@zakisk, correct. Bitbucket DC has 3 types of HTTPS tokens. User tokens have the authentication attached to the Licensed user. Repository HTTPS token and Project HTTPS have the authentication integrated within the server and can be used as Service Account. There is no need to have an extra Bitbucket User license, when the Project and Repo token can create webooks, create repositories (for project token), commits and comments.
Example of a comment made via a MLOPS Project HTTP token:

[zakisk]

@Ru13en I've tested this and found that you can actually use project access token with admin permission in PaC without any code changes but for repo access token we need to LICENCED_USER for checking permission of the user pushing to repo or raising PR.

[Ru13en]

@Ru13en I've tested this and found that you can actually use project access token with admin permission in PaC without any code changes but for repo access token we need to LICENCED_USER for checking permission of the user pushing to repo or raising PR.

@zakisk HTTP repository tokens with admin permission can get the members of the group necessary to check the permissions that you mention. Try with the following command:

curl -sS -H "Authorization: Bearer $REPO_ADMIN_TOKEN" <bitbucket_base_url>/rest/api/1.0/admin/groups/more-members?context=<Group_name>

Also they can get all permissions of the repository that it belongs.

curl -sS -H "Authorization: Bearer $REPO_ADMIN_TOKEN" <bitbucket_base_url>/rest/api/1.0/projects/{project_key}/repos/{repository_slug}/permissions/search

When you setup the scm-go client, if you don't drop the user, you will be forced to add an known user as a placeholder for the Repository PAC config and then this username somehow is being used...

[zakisk]

@Ru13en yeah, you're right I tried it. but you don't need to do the changes you're doing at the moment. it's issue in ACL when org membership check fails due to lack of permission on repo http token, it's returning right from there without checking below repo collaborator permission so you can just have a condition like this to get repo token working fine:

allowed, resp, err := v.Client().Organizations.IsMember(ctx, event.Organization, event.Sender)
if err != nil && resp != nil && resp.Status != http.StatusUnauthorized {
	return false, err
}

but your token must be having repo admin permission

[Ru13en]

@zakisk these changes are only to drop the unnecessary requirement for a username if I provide a HTTP Token during the PaC Repository configuration, since you are forced to add a valid one.
For security reasons we don't want to associate users or use them as placeholders with Admin tokens.
In this PR I didn't addressed any issue related with the lack of permissions.

[zakisk]

but if its working with repo and project access token why do you wanna remove user account check?

[Ru13en]

When you add the Repo config via GitOps we use External Secrets to inject the HTTP Tokens.
Right now we need to add a Valid Placeholder user.
We can't leave it empty or we can't add anything random.
Github configs don't need the username, why Bitbucket datacenter HTTP tokens require it?
We don't want to associate users or use them as placeholders with Admin tokens, we have a flag in the our security audits to drop such association.

[zakisk]

why Bitbucket datacenter HTTP tokens require it?

it was implemented a while ago in this commit to ensure that token is valid 549b2d8

[zakisk]

When you add the Repo config via GitOps we use External Secrets to inject the HTTP Tokens. Right now we need to add a Valid Placeholder user. We can't leave it empty or we can't add anything random. Github configs don't need the username, why Bitbucket datacenter HTTP tokens require it? We don't want to associate users or use them as placeholders with Admin tokens, we have a flag in the our security audits to drop such association.

it makes sense after you explained your use case!

[zakisk]

/ok-to-test

[Ru13en]

@zakisk updated the message for nil Repository CR as requested.
As you can check in the PR, the previous token validation is maintained and further extended for cases with empty username.

For private repositories, the CR will fail directly under the validation since the repo url will return 401.
For public repositories, if the token is invalid it will have the same behavior of a expired token or without enough permissions.
If this behavior is not good enough, then we need a different protected REST endpoint that allow us to validate the token validity.

[Ru13en]

CR setup now uses Find instead of FindLogin.
Unit tests mock the whoami url request implemented in go-scm client from upstream for stash/bitbucketdc.
@zakisk during my internal testing, I believe that I found a solution to validate the Admin permissions of the token, but I will implement it as a follow up PR.