I have problem authenticating artifactory on both local and CI environments with .npmrc:
local config works only with _authToken
#render:registry=https://artifactory.corpname.io/artifactory/api/npm/npm/
//artifactory.corpname.io/artifactory/api/npm/npm/:_authToken=${JFROG_AUTH_TOKEN}
//artifactory.corpname.io/artifactory/api/npm/npm/:always-auth=true
//artifactory.corpname.io/artifactory/api/npm/npm/:email=myemail#corpname.io
CI works only with _auth
#render:registry=https://artifactory.corpname.io/artifactory/api/npm/npm/
//artifactory.corpname.io/artifactory/api/npm/npm/:_auth=${JFROG_AUTH_TOKEN}
//artifactory.corpname.io/artifactory/api/npm/npm/:always-auth=true
//artifactory.corpname.io/artifactory/api/npm/npm/:email=myemail#corpname.io
I've tried adding both hoping it will take whatever is compatible with env
#render:registry=https://artifactory.corpname.io/artifactory/api/npm/npm/
//artifactory.corpname.io/artifactory/api/npm/npm/:_authToken=${JFROG_AUTH_TOKEN}
//artifactory.corpname.io/artifactory/api/npm/npm/:_auth=${JFROG_AUTH_TOKEN}
//artifactory.corpname.io/artifactory/api/npm/npm/:always-auth=true
//artifactory.corpname.io/artifactory/api/npm/npm/:email=myemail#corpname.io
this didn't help, what else can I do to have consistent setup?
as far as I understood env difference is that one of them uses npm login and another one basic auth, but what is responsible for this? both envs use same node version and how do I sync the setup is unclear for me
Try something like:
curl -u %ARTIFACTORY_USER%:%ARTIFACTORY_KEY% https://artifactory.corpname.io/artifactory/api/npm/auth > ~/.npmrc
echo '#render:registry https://artifactory.corpname.io/artifactory/api/npm/components-npm' >> ~/.npmrc
npm config set registry https://artifactory.corpname.io/artifactory/api/npm/mirror-npmjs-org
npm config set #render:registry https://artifactory.corpname.io/artifactory/api/npm/components-npm
Adjust the lines for linux if needed.
Related
my software started saying my giver is not deployed, but it is deployed, obviously.
I guess this is about endpoints. Could you please help me wrap my head around what's to be fixed? THx a lot!
everdev contract deploy FarmingCalculator.abi.json -n dev -s dev_giver -v 250000000 -d _randomNonce:13
Configuration
Network: dev (eri01.net.everos.dev, rbx01.net.everos.dev, gra01.net.everos.dev)
Signer: dev_giver (public 191fb7466066419bb44da39d58c2c1161255da87453b0447dc2500a4927b57db)
Address: 0:9781a951a6c8c8961e7f5467e308c6983189c3746557cf5cc5739d5a2dbc39a2 (calculated from TVC and signer public)
Error: Giver 0:5236a17bd571ad5cf8acda004158e94f97d61833c3a11484e23dd9e97374f9f7 has no code deployed."
try this:
everdev network credentials dev --project ""Project Id""
(Don't forget to install the latest everdev version and you need to be athorized)
I would like to use an access token to publish and retrieve from an artifactory npm repo from a CI environment. I have created a Bearer token using the artifactory API but when I try and use that for access in the .npmrc with the format:
//mydomain.jrog.io/:_authToken=myveryverylongaccesstoken
registry=https://mydomain.jfrog.io/mydomain/api/npm/npm
I always receive 401 errors back.
In addition, though perhaps a different issue, if I try to use npm login with my actual artifactory credentials I get the response:
adduser Incorrect username or password
npm WARN adduser You can reset your account by visiting:
npm WARN adduser
npm WARN adduser https://npmjs.org/forgot
npm WARN adduser
npm ERR! code E403
npm ERR! forbidden No oauth npm default login configuration found: org.couchdb.user:myusername
The artifactory docs around access tokens explicitly say this is the sort of use case to set up an access token, but the docs around setting up the npm repo alwyas seem to imply you need a real user account and make no mention of access tokens...
What is your artifactory version?
The "npm login" way is only supported since 5.4 (aka. _authToken), so if you are below that, your only chance is to authenticate with BASIC authentication (aka. _auth).
Basic authentication is fairly easy to setup, Artifactory provides an easy entry point to help you set up your .npmrc
Launch the following (and do not forget to replace user and encrypted_password with the Artifactory user account you want to authenticate with)
curl -u user:encrypted_password https://mydomain.jfrog.io/mydomain/api/npm/auth
It will output something like
_auth = YourLongBasicAuthToken
always-auth = true
email = user#server.com
Copy these 3 lines in your .npmrc, and this should work well...
To generate the contents for .npmrc, use an existing user like admin with its password
curl -uadmin:<PASSWORD> http://<ARTIFACTORY_SERVER_DOMAIN>/artifactory/api/npm/auth
afterwards you can replace/set the _auth key with any base64 encoded username:ACCESS_TOKEN
for scoped packages, use
curl -uadmin:<PASSWORD> http://<ARTIFACTORY_SERVER_DOMAIN>/artifactory/api/npm/npm-repo/auth/<SCOPE>
and set ..username and .._password (base64) with any user and access token
Using Basic Authentication
Using the next described steps you should change your local .nprmc file with the output of the command
To retrieve the next fields _auth, email and always-auth automatically generated -> Run the following command to retrieve these strings directly from Artifactory:
curl -u {username}:{API_key}
http://{artifactory_server_domain}/{domain}/artifactory/api/npm/auth
Notes:
{username} -> Name near Welcome when you are logged in - take a look at the attached screenshot
{Api_key} -> Copy and paste this key - take a look at the attached screenshot
{artifactory_server_domain} - domain of your artifactory accrodingly.
{domain} - additional filed of domain in you url (if present)
Screenshot describes {artifactory_server_domain} and {domain}
The _auth line in the other answers breaks some scoped package retrieval from npmjs. I found that I needed to use specific _auth for just the one registry I was using. See my original answer here https://stackoverflow.com/a/57014522/442837
in addition to the previously offered solutions:
curl -u username:encrypted_password http://<ARTIFACTORY_SERVER_DOMAIN>/artifactory/api/npm/auth >> ~/.npmrc
curl -u username:personal_api_key http://<ARTIFACTORY_SERVER_DOMAIN>/artifactory/api/npm/auth >> ~/.npmrc
here is another option without using curl (*does not work with API key):
npm config set _auth $(echo -n username:encrypted_password | base64)
My experience adds to the comments made by others.
I was working with jfrog and already placed the package in jfrog. When trying to resolve that using jfrog.
I got the error "npm ERR! Unable to authenticate, need: Basic realm="Artifactory Realm"" when i checked logs.
After spending hours trying to resolve.
I came across the documentation.
https://www.jfrog.com/confluence/display/JFROG/npm+Registry#npmRegistry-ConfiguringthenpmClientforaScopeRegistry
This is very useful..The issue is I'm just pasting the access token instead of base64 encoded one.
the helpful part of the page
Then I ran that command curl -u admin with a new credentials and token and got back the base64 encoded one.
Then it started working ..Hope it's helpful to anyone working with jfrog
For windows user :-
1/ Add https://registry.npmjs.org to .npmrc to user profile on top:
registry=https://registry.npmjs.org
or 2/ Run below command
npm config set registry https://registry.npmjs.org
By using npm adduser, my credentials get stored as a base64-encoded String username:password into the ~/.npmrc file:
_auth=aGV5OmN1cmlvdXM7LSk=
Anyone with access to this file could easily decode this and find out my password.
Is it possible in NPM to encrypt the _auth value?
It seems that they try to tackle this by using environment variables that are injected in .npmrc when needed:
All npm config files are an ini-formatted list of key = value parameters. Environment variables can be replaced using ${VARIABLE_NAME}
from: https://docs.npmjs.com/files/npmrc
So, in your case you can save your password token in an env variable
export ENV_TOKEN=${mytoken} and have your .npmrc file auth line changed to:
_auth=${ENV_TOKEN}
I want to write a Dockerfile which exports a directory from a remote Subversion repository into the build context so I can work with these files in subsequent commands. The repository is secured with user/password authentication.
That Dockerfile could look like this:
# base image
FROM ubuntu
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# export my repository
RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory
# further commands, e.g. on container start run a file just downloaded from the repository
CMD ["/bin/bash", "path/to/file.sh"]
However, this has the drawback of printing my username and password on the screen or any logfile where the stdout is directed, as in Step 2 : RUN svn export --username=myUserName --password=myPassword http://subversion.myserver.com/path/to/directory. In my case, this is a Jenkins build log which is also accessible by other people who are not supposed to see the credentials.
What would be the easiest way to hide the echo of username and password in the output?
Until now, I have not found any way how to execute RUN commands in a Dockerfile silently when building the image. Could the password maybe be imported from somewhere else and attached to the command beforehand so it does not have to be printed anymore? Or are there any methods for password-less authentication in Subversion that would work in the Dockerfile context (in terms of setting them up without interaction)?
The Subversion Server is running remotely in my company and not on my local machine or the Docker host. To my knowledge, I have no access to it except for accessing my repository via username/password authentication, so copying any key files as root to some server folders might be difficult.
The Dockerfile RUN command is always executed and cached when the docker image is build so the variables that svn needs to authenticate must be provided at build time. You can move the svn export call when the docker run is executed in order to avoid this kind of problems. In order to do that you can create a bash script and declare it as a docker entrypoint and pass environment variables for username and password. Example
# base image
FROM ubuntu
ENV REPOSITORY_URL http://subversion.myserver.com/path/to/directory
# install subversion client
RUN apt-get -y update && apt-get install -y subversion
# make it executable before you add it here otherwise docker will coplain
ADD docker-entrypoint.sh /enrypoint.sh
ENTRYPOINT /entrypoint.sh
docker-entrypoint.sh
#!/bin/bash
# maybe here some validation that variables $REPO_USER $REPO_PASSOWRD exists.
svn export --username="$REMOTE_USER" --password="$REMOTE_PASSWORD" "$REPOSITORY_URL"
# continue execution
path/to/file.sh
Run your image:
docker run -e REPO_USER=jane -e REPO_PASSWORD=secret your/image
Or you can put the variables in a file:
.svn-credentials
REPO_USER=jane
REPO_PASSWORD=secret
Then run:
docker run --env-file .svn-credentials your/image
Remove the .svn-credentials file when your done.
Maybe using SVN with SSH is a solution for you? You could generate a public/private key pair. The private key could be added to the image whereas the public key gets added to the server.
For more details you could have a look at this stackoverflow question.
One solution is to ADD the entire SVN directory you previously checked out on your builder file-system (or added as a svn:externals if your Dockerfile is itself in a SVN repository like this: svn propset svn:externals 'external_svn_directory http://subversion.myserver.com/path/to/directory' ., then do a svn up).
Then in your Dockerfile you can simply have this:
ADD external_svn_directory /tmp/external_svn_directory
RUN svn export /tmp/external_svn_directory /path/where/to/export/to
RUN rm -rf /tmp/external_svn_directory
Subversion stores authentication details (if it not disabled in configuration) at client side and use stored username|password on request for the subsequent operations on the same URL.
Thus - you have to run (successful) svn export in Dockerfile with username|password only once and allow SVN to use cached credentials (remove auth. options from command-line) later
I'm trying to clone private git repository from github. I did a Dockerfile like this:
FROM ubuntu:12.04
RUN apt-get update
RUN apt-get install -y git
RUN mkdir -p /root/.ssh/
ADD ./id_rsa /root/.ssh/id_rsa
RUN git clone git#github.com:usr/repo.git
I use this repo with this key just fine locally, so it seems I'm missing something inside docker.
One more thing I may be missing is that both ~ and $HOME inside docker point to / instead of /root, but I'm not sure if that can be related.
What's the output of the build process?
Random guess: try to chmod 600 the private key.
If it still doesn't work, try to RUN ssh -v git#github.com (after adding the key); the output should explain what's happening.
RUN ssh-keyscan github.com >> ~/.ssh/known_hosts
The keyscan works great since it accepts the host. The following complete answer worked:
RUN mkdir -p /root/.ssh
RUN cp /var/my-app/id_rsa /root/.ssh/id_rsa
RUN chmod 600 /root/.ssh/id_rsa
RUN ssh-keyscan github.com >> /root/.ssh/known_hosts
Also as mentioned:
RUN ssh -v git#github.com
^ Great way to debug the flow. That's how I realized I needed the keyscan >> known_hosts
(Will probably not fit your needs)
There is another approach: https://stackoverflow.com/a/29464430/990356
Go to Settings > Personal access tokens and generate a personal access token with repo scope enabled.
Now you can do git clone https://MY_TOKEN#github.com/user-or-org/repo
Pros:
very simple approach
token can be easily revoked
Cons:
if someone has access to the Dockerfile he has access to the token
To fix this, you can use an environment variable to store the token
Below approach is using https with Personal Access Token, and it works like charm.
ARG git_personal_token
RUN git config --global url."https://${git_personal_token}:#github.com/".insteadOf "https://github.com/"
RUN git clone https://github.com/your/project.git /project
Then, supply a docker argument as below.
docker build --build-arg git_personal_token={your_token} .
Basic idea is from https://medium.com/paperchain/fetching-private-github-repos-from-a-docker-container-273f25ec5a74