fix(bitbucket): report that the archive url carries no credential - #129
Merged
Conversation
A caller that can only fetch a url reaches a private repository through the credential the url carries. Bitbucket's archive host takes none from the url -- a token offered as basic userinfo is answered with a redirect to a login page, so what comes back is a login rather than an archive, and the fetch lands empty with nothing to say why. Adapters report whether their archive url stands on its own, so a caller can clone what it cannot download. Bitbucket's git endpoint accepts the token the archive host refuses.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A Bitbucket site deployment on Cloud never builds. It sits at
WaitingwithSize 0 B, no build logs, and nothing in the queue.Cause
getRepositoryPresignedUrl()puts the token in the url as basic userinfo. Bitbucket's archive host does not take a credential that way — it answers a redirect to a login page, so the fetch lands empty and the build is never queued. Nothing errors.Measured against production, with the real stored token:
x-token-auth:<oauth>@bitbucket.org/…/get/main.tar.gz?access_token=<oauth>Authorization: Bearer <oauth>git ls-remote https://x-token-auth:<oauth>@…gitOnly a header authenticates that host, and the caller fetching the url sends none. The same token is accepted by the git endpoint.
Change
Adapters report whether their archive url stands on its own. Bitbucket reports false, so a caller clones what it cannot download; every other adapter is unchanged and keeps its default.
The alternative — carrying an auth header to the archive fetch — reaches past the caller into the service that performs it, for a url that works without one anyway.
Follow-up
Appwrite routes a provider reporting false down the clone path it already owns for template pushes.