[Bug] Azure artifacts authentication #316
Comments
|
Can you try using If it still doesn't work it'd be helpful if you could add some logs near the place that makes the http request to find out whether the server answers with the reason why the request is rejected. |
|
I did try using Here's the things I tried:
I'm now trying this on a Windows PC. What's interesting is their That's it. It doesn't have the two different URL's (one with I tried using that token in the various methods I described above, but the only way it worked was just that token in the I don't know how that All I know is that Yarn v1 doesn't have any problem with the .npmrc Does berry have a built in logging utility, or will I need to do a tcpdump to get the logs you mentioned? |
|
Very strange ... I think the main difference is that we're not sending the email address as it's unused by all registries I'm aware of 🤔
The best is to just add a https://github.com/yarnpkg/berry/blob/master/packages/berry-core/sources/httpUtils.ts#L63 |
|
I put a I will try this again on my Linux box tonight to get some logs for that I realized what I've been doing wrong with So, after encoding Here's what I got from curl...
Where does an npm server usually expect to see the email address in the request? I can run that through curl, and if I am able to retrieve the tarball, we know that's the problem. |
|
Nevermind, I figured it out. I was able to retrieve the file succesfully by sending the authentication headers Using curl, I used Then the Hope this helps. |
|
But credentials are expected to be sent through the Oh wait I might know where this is coming from - in the v1, when resolving a package, we also were storing the returned archive url. In the v2, we only store the package version, and when we need to fetch the archive we combine the version to the registry according to the following convention: If that's the case we track that in #238 - it should be possible to fix it by storing non-conventional tarball urls within the lockfile, the main issue being that I cannot test it on my side since I don't have access to such environments ... so if someone else could do it it would be awesome 😅 This would however imply that the authentication credentials are somehow stored inside the lockfile when using Azure, which sounds surprising. Can you check? |
|
Ah, yes, you're correct. It did seem a little odd to me that they would pass credentials that way, but I didn't even think to try it without. 🙄 The tarball naming URL's do match that convention, but that tarball URL redirects to the *.blob, which includes session IDs + various other query parameters (sv, sr, si, sig, spr, se, rscl, rscd). Most of those stay constant per each tarball, but the "rscl" appears to be a session ID, and the "sig" appears to be a type of access token, and they change on each request. I don't think storing that URL will be effective, because I doubt there's a guarantee for how long those parameters will be good. The only thing they seem to care about when hitting that redirect is whether or not there IS an authorization header. Apparently, everything up to the redirect you get when you hit the tarball URL is authenticated, but the *.blob I get from the tarball URL is anonymous. It simply ignores those query parameters. So the 400 error about checking the Authorization header was just to say "why is there an Authorization header?" 🤣 EDIT: |
|
Btw, I can say with certainty that the authentication credentials are not stored in the lockfile when using Azure. At least not with v1. It's just the standard naming convention: I haven't been able to fetch the package successfully with v2 yet, so I can't say what the lockfile looks like for it. |
|
So just to be clear - the fix would be to do as we do, but if we receive a redirect not send the authentication header after handling the redirect? If so that seems acceptable. Would you be willing to make a PR? The relevant code is here: https://github.com/yarnpkg/berry/blob/master/packages/berry-core/sources/httpUtils.ts#L63 |
|
Added pull request #329. |
|
Fixed by #329 🎉 |
|
For future readers - tldr: npmRegistryServer: "https://your-server"
npmAuthIdent: "base64(your-org:your-pat)"
|
|
I was able to get passed authentication, but now I am getting a 404. The following returns 200 Not sure if this is related to Yarn or Artifacts. Thought I would share this here in case somebody is having the same issue. |
|
Problem still exists, lacks of solution. Are we able to provide more details, any kind of yarnrc.yml as example? |
THANK YOU @darthtrevino ! This just worked for me using github registry as well. Finally! |
|
To clarify this even more:
But in step 3.2, type: Then your npmRegistries:
//pkgs.dev.azure.com/<organisation>/_packaging/<azurefeed>/npm/registry:
npmAlwaysAuth: true
npmAuthIdent: <base64 output from above>
npmScopes:
<azurefeed>:
npmRegistryServer: "https://pkgs.dev.azure.com/<organisation>/_packaging/<azurefeed>/npm/registry"After you have this setup, I've tested this with yarn berry/v3. |
|
for us the base64 encoding did not work, but having the <org>:<pat> in plain form in the npmAuthIdent did |
In case anyone else has a similar setup to me, we run all modules through our azure registry, so our shared .yarnrc.yml looked like this: And then each dev can have their own $AZURE_ARTIFACTS_TOKEN in their PATH, and it's easy to set the env var in a build |
|
@cherealnice I came across similar issue recently. Our dev environment uses Content of the Create a new yarnrc-ci.yml file with this content Set environment variable for the yarnrc file in the build script: Use the yarnrc file name and access token environment variable in your build script for all the tasks that depend on yarn. Please note that |
|
It's possible to make the authentication without creating the PAT, but with token generated by It's a bit hacky, but it works – we read the JWT token generated by |
Describe the issue
Really not sure this is a bug; more like a support question. I am having trouble getting my Azure DevOps Artifacts npm registry working with berry. It works fine in v1, using the token from .npmrc, which is generated by Azure DevOps.
The ":_password" field in the .npmrc is a base64 encoded Personal Access Token generated in Azure DevOps, and according to their documentation, the ":username" and ":email" field mean nothing. Documentation is found here
I have tried generating the auth token through their Artifact "Connect to feed" process, which generates the token for your .npmrc like this
I also tried generating my own PAT, and base64 encoding it, for use in that "_password" field.
I used that "_password" field as the
npmAuthTokenin my .yarnrc.yml, I've tried using it in thenpmAuthIdentin combination with the username from above, as<username>:<token>. I've tried combining the<username>:<token>into a base64 encoded string and including that in thenpmAuthToken. None of these work. I always get(401) Unauthorized.To Reproduce
You would need a module published in an Azure DevOps Artifacts registry.
My .yarnrc.yml is below, with the sensitive information redacted.
Environment if relevant (please complete the following information):
The text was updated successfully, but these errors were encountered: