Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support using GITLAB_PAT for authentication #674

Merged
merged 6 commits into from
Jun 29, 2022
Merged

Conversation

toph-allen
Copy link
Contributor

@toph-allen toph-allen commented Jun 24, 2022

Intent

Fix source downloads from private GitLab repositories by preferentially using GITLAB_PAT for authentication.

Fixes #673

Approach

The GitLab downloader now checks for a GITLAB_PAT. If that exists, instead of creating the username/password auth, it adds Private-Token to the request's headers.

GITLAB_USERNAME and GITLAB_PASSWORD were removed. See this comment for why.

Automated Tests

There were no automated tests for GitLab download functionality before. There is one test that is skipped unless run manually.

This PR adds no tests.

QA Notes

I validated this against a private repo on my GitLab account. Validation is tricky, requiring a Packrat lock file that restores from a GitLab repository.

To validate:

  1. Download and extract this archive: packrat-with-private-package.zip
  2. Get access from me to the private package hosted on GitLab that this package attempts to restore.
  3. Create a GitLab PAT and make it available in your terminal's environment as GITLAB_PAT.
  4. Install this branch's version of Packrat.
  5. Start an R session in the archive's directory that contains a packrat subdirectory. Run packrat::restore(). The environment should restore correctly.

We should also confirm:

  • If the GITLAB_PAT environment variable is missing, an error message is displayed.
  • If GITLAB_USERNAME and GITLAB_PASSWORD variables are present and GITLAB_PAT is absent, the same error message about GITLAB_PAT is displayed.

Checklist

  • Added NEWS entry

@toph-allen toph-allen linked an issue Jun 24, 2022 that may be closed by this pull request
@toph-allen toph-allen marked this pull request as draft June 24, 2022 21:39
@toph-allen toph-allen marked this pull request as ready for review June 24, 2022 21:44
@toph-allen toph-allen requested a review from aronatkins June 24, 2022 21:44
@toph-allen
Copy link
Contributor Author

toph-allen commented Jun 28, 2022

I haven’t found any historical reference to GitLab ever allowing basic password auth in its API, even going back into old issues and StackOverflow posts. I wondered if I was missing some search term. The original implementation was tested against a public repo and followed the Bitbucket implementation (Bitbucket does use username and password).

I think it's likely that GitLab has never supported basic auth with username and password, and that this feature has just never been exercised properly due to renv's availability and Connect not supporting restoring packages from private sources.

@aronatkins , do you think it makes sense to remove the GITLAB_USERNAME and GITLAB_PASSWORD “capability” entirely from packrat? I think that leaving it may only serve to send users on a wild goose chase.

@toph-allen
Copy link
Contributor Author

@aronatkins I removed GITLAB_USERNAME and GITLAB_PASSWORD support in the latest commit.

  • After an exhaustive search of the web (StackOverflow, GitLab's own issue tracker and community forum, relevant issues on Packrat and Connect repos, and the RStudio community forum), I found no evidence that GitLab ever supported authenticating calls to its API with username and password, or that anyone had tried to use Packrat in this way. Even five years ago, token-based auth was all I found.
  • This was added three years ago, and the work seems to only have been verified with public packages. At that point, renv already existed and supported GitLab.
  • Because this was mainly only used in Connect, and there were other known barriers to restoring private packages on Connect, this was never discovered.

Removing it from Packrat will avoid sending users down a dead end.

gitlab_pwd <- function(quiet = FALSE) {
pwd <- Sys.getenv("GITLAB_PASSWORD")
if (nzchar(pwd)) {
gitlab_pat <- function(quiet = FALSE) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I just realized that the bitbucket and gitlab accessor functions are exported by packrat. I don't think that it was our intent to allow packrat::gitlab_pat. That said, it's out in the wild. :(

CC @kevinushey

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think they are actually exported! They don't have the @export keyword, they don't appear in NAMESPACE, and you need to use ::: to access them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They do have documentation generated, but it isn't included in the index, because they include @keyword internal in a roxygen2 comment.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, that's correct -- they're documented but not exported.

@toph-allen
Copy link
Contributor Author

CI is failing on oldrel-1 — it looks like network errors in apt-get or something like that.

@toph-allen toph-allen merged commit 2bbfad3 into main Jun 29, 2022
@toph-allen toph-allen deleted the toph-gitlab-pat branch June 29, 2022 19:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Authentication for private GitLab repos need to use PAT
3 participants