Npm auth

Npm auth DEFAULT

azure-devops-npm-auth

Uses the OAuth 2 device code flow to authenticate against the Azure DevOps artifact private registry.

Why? ūü§Ē

Microsoft provides the vsts-npm-auth package for this task but sadly, it's not cross-platform and doesn't automatically handle token refresh.

There's also better-vsts-npm-auth which solves these issues but requires manual setup (not ideal for a dev team) and authentication through a web app, which in my opinion isn't the best flow to use in the command line.

The azure-devops-npm-auth solves all these problems mainly by using the OAuth 2 device code flow. Once authenticated, access and refresh tokens are then stored in the user's personal .npmrc file, keeping them secure and out of any code repository.

Installation ūüí™

Simply run .

Usage ūü§∑‚Äć‚ôāÔłŹ

First, add a pre-installation script to your file like so:

Then, setup the project repository in the file as documented in the Azure DevOps npm feed connection page:

az devops npm feed connection

When installing packages using , the preinstallation script will be executed and ask you to login using a device code:

az devops device code flow

Follow the instructions to login and authenticate npm to the Azure DevOps private feed. The following installation should be able to use the refresh token and automate the task of authenticating:

az devops device code refresh

Advanced Usage ūüßô‚Äć‚ôāÔłŹ

If you want to use your own Azure Active Directory application, it's possible to specify the and arguments:

Note: If your Azure Active Directory application is configured to be multitenant, can also be (is the default; Work and school accounts or personal Microsoft accounts), (personal Microsoft accounts) or (work and school accounts).

When creating your own Azure Active Direction application, under the authentication section, you need the configure it to be a public application:

aad public app

You also need to add the required API permissions to have '' and '':

aad api permissions

Continuous integration

To disable authentication within CI environments add the flag which skips authentication when the environment variable is set (which is automatically set in Azure DevOps build pipelines):

It's also possible to specify a custom environment variable:

Project Base Path

You can pass in a path to customize the directory to look in for the project's .npmrc file. The default value is the current working directory:

Note: this is the path to the directory that contains the .npmrc file, meaning you do not need to specify the .npmrc in the path.

Special Thanks ūüĎŹ

I have to give thanks to the author(s) of better-vsts-npm-auth which was a big inspiration of mine for this project. Also, thanks to openid-client for simplifying the process of integrating the OAuth device code flow to the code.

License ūüĎ©‚Äć‚öĖÔłŹ

Copyright © 2021, GSoft inc. This code is licensed under the Apache License, Version 2.0. You may obtain a copy of this license at https://github.com/gsoft-inc/gsoft-license/blob/master/LICENSE.

Sours: https://npm.io/package/azure-devops-npm-auth

npm

Uses the OAuth 2 device code flow to authenticate against the Azure DevOps artifact private registry.

Why?

Microsoft provides the vsts-npm-auth package for this task but sadly, it's not cross-platform and doesn't automatically handle token refresh.

There's also better-vsts-npm-auth which solves these issues but requires manual setup (not ideal for a dev team) and authentication through a web app, which in my opinion isn't the best flow to use in the command line.

The azure-devops-npm-auth solves all these problems mainly by using the OAuth 2 device code flow. Once authenticated, access and refresh tokens are then stored in the user's personal .npmrc file, keeping them secure and out of any code repository.

Installation

Simply run .

Usage

First, add a pre-installation script to your file like so:

"scripts": {"preinstall": "azure-devops-npm-auth"...},

Then, setup the project repository in the file as documented in the Azure DevOps npm feed connection page:

az devops npm feed connection

When installing packages using , the preinstallation script will be executed and ask you to login using a device code:

az devops device code flow

Follow the instructions to login and authenticate npm to the Azure DevOps private feed. The following installation should be able to use the refresh token and automate the task of authenticating:

az devops device code refresh

Advanced Usage

If you want to use your own Azure Active Directory application, it's possible to specify the and arguments:

"scripts": {"preinstall": "azure-devops-npm-auth --client_id='xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' --tenant_id='xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'"...},

Note: If your Azure Active Directory application is configured to be multitenant, can also be (is the default; Work and school accounts or personal Microsoft accounts), (personal Microsoft accounts) or (work and school accounts).

When creating your own Azure Active Direction application, under the authentication section, you need the configure it to be a public application:

aad public app

You also need to add the required API permissions to have '' and '':

aad api permissions

Continuous integration

To disable authentication within CI environments add the flag which skips authentication when the environment variable is set (which is automatically set in Azure DevOps build pipelines):

"scripts": {"preinstall": "azure-devops-npm-auth --ci"...},

It's also possible to specify a custom environment variable:

"scripts": {"preinstall": "azure-devops-npm-auth --ci=MY_CUSTOM_VARIABLE"...},

Project Base Path

You can pass in a path to customize the directory to look in for the project's .npmrc file. The default value is the current working directory:

"scripts": {"preinstall": "azure-devops-npm-auth --project_base_path=./configs"...},

Note: this is the path to the directory that contains the .npmrc file, meaning you do not need to specify the .npmrc in the path.

Special Thanks

I have to give thanks to the author(s) of better-vsts-npm-auth which was a big inspiration of mine for this project. Also, thanks to openid-client for simplifying the process of integrating the OAuth device code flow to the code.

License

Copyright © 2021, GSoft inc. This code is licensed under the Apache License, Version 2.0. You may obtain a copy of this license at https://github.com/gsoft-inc/gsoft-license/blob/master/LICENSE.

Sours: https://www.npmjs.com/package/azure-devops-npm-auth
  1. Ftse quotes
  2. Tattoo wallpaper designs
  3. One uw medicine
  4. Easy origami cards

npm

Build StatusCodacy Badge

This utility is used to set the credentials in locally to authenticate against any public/private NPM Repository.

Requirements

  • This utility depends on various environment variables being set, specifically:
  • => the value of .
  • => the email used to authenticate with. The default value will be used if this environment variable is not set.
  • => the registry that the utility will authenticate against.

Installation


Usage


If you are not setting the properties as environment variables, you are welcome to passing them via the CLI

¬†¬†¬†¬†npm-auth¬†--registry=http://www.your-private-registry/npm¬†¬†--secure-token=aasd-123-zasdf-123-sfd¬†[email protected]

¬†¬†¬†¬†npm-auth¬†[email protected]

Make sure to ignore the local from the project solution

.gitignore

Development

Start with:

Running tests:

  npm run test

  npm run test:cover

Command:

Building the application: The resulting source code is built to a directory which is where the transpiled source resides. By default the test files are not built to this directory, only the underlying source.

Command:

Contributing

Looking to contribute to NPM-Auth? I love seeing PR's and suggestions, please visit the CONTRIBUTING section for more information.

Sours: https://www.npmjs.com/package/npm-auth
Build Node.js User Authentication - Password Login

npm

Features

  • share items with multiple users
  • creating account tokens with access to specific collections & items
    • used for locking down public access to certain features.
    • ability to add expiration for tokens

var mongoose =require("mongoose"),

step         =require("step"),

Schema       =mongoose.Schema,

ObjectId     =Schema.Types.ObjectId;

var auth =require("auth").connect({

    connection:mongoose.createConnection("mongodb://localhost/auth-test")

});

var Post =newSchema({

    message:String

});

Post.plugin(auth.ownable);

step(

function(){

auth.signup({¬†email:"[email protected]",¬†password:"password"},this);

},

function(err,account){

this.account= account;

var post =newPost({

            message:"Hello World!"

});

account.own(post);

post.save(this);

},

function(){

Post.find(this.account.ownQuery(),this);

},

function(err,post){

console.log(post.message);

}

);

auth API

auth auth.connect(options)

  • options - mongodb connection

auth.Account.signup(account, onCreated)

creates a new user

auth.Account.login(credentals, onLogin)

Logs the user in with u/p, or a token

Example:

auth.Account.login({ token: tokenKey }, onLogin);

auth.Account.login({ email:"email", password:"password"}, onLogin);

Account API

account.getMainToken(callback)

returns the main access token with super privileges. No restrictions to collections & items.

user.getMainToken(function(null,token){

console.log(token.key);

console.log(token.ttl);

console.log(token.scope);

})

account.createToken(options, callback)

  • - options for the token
    • - the item to grant access to (optional)
    • - the collection
    • - time in MS for expiration
    • - (array) scope access. default is

user.createToken({ item:Posts.collection.name, access:[access.POST]},function(err,token){

console.log(token.scope);

});

account.ownItem(item)

makes the account an owner of an item with SUPER privileges on item

var p =newPost({ message:"hello!"});

user.ownItem(p);

p.save();

account.shareItem(item, access)

Shares an item with another user

  • - item to own
  • - access level for the given item. Blank = ALL privileges.

var access =require("auth").access;

Post.findOne({message:"hello!"},function(err,post){

user2.shareItem(post,[access.GET]);

post.save();

});

account.authorized(item, access)

returns TRUE if the account has access to the item. Note that the result can be variable depending if whether the given user logs in with a restricted login token. See below.

user2.authorized(post);

user2.authorized(post,[access.POST]);

user2.authorized(post,[access.GET]);

user2.authorized(post,[access.GET,access.POST]);

User.login({ token: aboveTokenKey },function(err,user){

user.authorized(post,[access.TRUE]);

user.authorized(post,[access.POST]);

})

Error account.unauthorized(callback)

Tiny flow-control utility.

account.addToSearch(query)

adds account to the given search. For example:

Post.findOne(user.addToSearch(),function(err,post){

user.authorized(post);

})

## TODO

- make sub-schemas ownable

- sharing whole collections(job & timer)

- custom authentication schema

- validation ofcredentials(email/pass)

-Auth.lockdown- prevent models from being saved or serialized if unauthorized

- hooks with[passport](https:

Sours: https://www.npmjs.com/package/auth

Auth npm

Creating and viewing access tokens

You can create and view access tokens from the website and command line interface (CLI).

Creating access tokens

Creating tokens on the website

  1. In the upper right corner of the page, click your profile picture, then click Access Tokens.

    Screenshot of the account menu with the tokens link selected
  2. Click Create New Token.

    Screenshot of the create new token button
  3. Select the type of access token:

    • Read-only: a read-only token can only be used to download packages from the registry. It will have permission to read any private package that you have access to. This is recommended for automation and workflows where you are installing packages, but not publishing new ones.

    • Automation: an automation token can download packages and publish new ones, but if you have two-factor authentication (2FA) configured on your account, it will not be enforced. You can use an automation token in continuous integration workflows and other automation systems to publish a package even when you cannot enter a one-time passcode. This is recommended for automation workflows where you are publishing new packages.

    • Publish: a publish token can perform any action on your behalf, including downloading packages, publishing packages, and changing user settings or package settings. If you have two-factor authentication configured on your account, you will be required to enter a one-time passcode when using a publish token. This is recommended for interactive workflows.

    Screenshot of the access level selection
  4. Click Generate Token.

  5. Copy the token from the top of page.

Creating tokens with the CLI

You can create tokens with read-only permissions or read and publish permissions with the CLI; you cannot currently create automation tokens.

  • Read-only: Tokens that allow installation and distribution only, but no publishing or other rights associated with your account.
  • Publish: The default setting for new tokens, and most permissive token type. Publish tokens allow installation, distribution, modification, publishing, and all rights that you have on your account.

In addition, you can specify that the token is only valid for a specific IPv4 address range, using CIDR notation. The token will only be valid when used from the specified IP addresses.

  1. To create a new token, on the command line, run:
    • for a read and publish token
    • for a read-only token
    • for a CIDR-restricted read and publish token. For example,
    • for a CIDR-restricted read-only token
  2. When prompted, enter your password.
  3. If you have enabled two-factor authentication, when prompted, enter a one-time password.
  4. Copy the token from the token field in the command output.

CIDR-restricted token errors

If the CIDR string you enter is invalid or in an inappropriate format, you will get an error similar to the one below:

npm ERR! CIDR whitelist contains invalid CIDR entry: X.X.X.X./YY,Z.Z.. . .

Make sure you are using a valid IPv4 range and try creating the token again.

Viewing access tokens

Note: Full tokens are never displayed, only the first and last four characters will be shown. You can only view a full token immediately after creation.

Viewing tokens on the website

To view all tokens associated with your account, in the upper right corner of the page, click your profile picture, then click Access Tokens.

Screenshot of the account menu with the tokens link selected

Viewing tokens on the CLI

To view all tokens associated with your account, on the command line, run the following command:

Token attributes

  • id: Use the token ID to refer to the token in commands.
  • token: The first digits of the actual token.
  • create: Date the token was created.
  • readonly: If yes, indicates a read-only token. If no, indicates a token with both read and publish permissions.
  • CIDR whitelist: Restricts token use by IP address.
Sours: https://docs.npmjs.com/creating-and-viewing-access-tokens/
Fix-- npm is not recognized as internal or external command

Configure and use npm with CodeArtifact

After you create a repository in CodeArtifact, you can use the npm client to install and publish packages. The recommended method for configuring npm with your repository endpoint and authorization token is by using the command. You can also configure npm manually.

Configuring npm with the login command

Use the command to fetch credentials for use with npm.

Note

If you are accessing a repository in a domain that you own, you don't need to include . For more information, see Cross-account domains.

This command makes the following changes to your ~/.npmrc file:

  • Adds an authorization token after fetching it from CodeArtifact using your AWS credentials.

  • Sets the npm registry to the repository specified by the option.

  • For npm 6 and lower: Adds so the authorization token is sent for every npm command.

The default authorization period after calling is 12 hours, and must be called to periodically refresh the token. For more information about the authorization token created with the command, see Tokens created with the login command.

Configuring npm without using the login command

You can configure npm with your CodeArtifact repository without the command by manually updating the npm configuration.

To configure npm without using the login command

  1. In a command line, fetch a CodeArtifact authorization token and store it in an environment variable. npm will use this token to authenticate with your CodeArtifact repository.

  2. Get your CodeArtifact repository's endpoint by running the following command. Your repository endpoint is used to point npm to your repository to install or publish packages.

    • Replace with your CodeArtifact domain name.

    • Replace with the AWS account ID of the owner of the domain. If you are accessing a repository in a domain that you own, you don't need to include . For more information, see Cross-account domains.

    • Replace with your CodeArtifact repository name.

    The following URL is an example repository endpoint.

    Important

    The registry URL must end with a forward slash (/). Otherwise, you cannot connect to the repository.

  3. Use the command to set the registry to your CodeArtifact repository. Replace the URL with the repository endpoint URL from the previous step.

  4. Use the command to add your authorization token to your npm configuration.

    For npm 6 or lower: To make npm always pass the auth token to CodeArtifact, even for requests, set the configuration variable with .

Example npm configuration file ()

The following is an example file after following the preceding instructions to set the CodeArtifact registry endpoint, add an authentication token, and configure .

Running npm commands

After you configure the npm client, you can run npm commands. Assuming that a package is present in your repository or one of its upstream repositories, you can install it with . For example, use the following to install the package.

Use the following command to publish a new npm package to a CodeArtifact repository.

For information about how to create npm packages, see Creating Node.js Modules on the npm documentation website. For a list of npm commands supported by CodeArtifact, see npm Command Support.

Verifying npm authentication and authorization

Invoking the command is a way to verify the following:

  • You have correctly configured your credentials so that you can authenticate to an CodeArtifact repository.

  • The authorization configuration grants you the permission.

The output from a successful invocation of looks like the following.

The option causes npm to print additional debug information, including the repository URL. This information makes it easy to confirm that npm is configured to use the repository you expect.

Changing back to the default npm registry

Configuring npm with CodeArtifact sets the npm registry to the specified CodeArtifact repository. You can run the following command to set the npm registry back to its default registry when you're done connecting to CodeArtifact.

Sours: https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.html

You will also be interested:

Using private packages in a CI/CD workflow

You can use access tokens to test private npm packages with continuous integration (CI) systems, or deploy them using continuous deployment (CD) systems.

Create a new access token

Create a new access token that will be used only to access npm packages from a CI/CD server.

Continuous integration

By default, will generate a token with both read and write permissions. When generating a token for use in a continuous integration environment, we recommend creating a read-only token:

npm token create --read-only

For more information on creating access tokens, including CIDR-whitelisted tokens, see "Creating an access token".

Continuous deployment

Since continuous deployment environments usually involve the creation of a deploy artifact, you may wish to create an automation token on the website. This will allow you to publish even if you have two-factor authentication enabled on your account.

Interactive workflows

If your workflow produces a package, but you publish it manually after validation, then you will want to create a token with read and write permissions, which are granted with the standard token creation command:

CIDR whitelists

For increased security, you may use a CIDR-whitelisted token that can only be used from a certain IP address range. You can use a CIDR whitelist with a read and publish token or a read-only token:

npm token create --cidr=[list]

npm token create --read-only --cidr=[list]

Example:

npm token create --cidr=192.0.2.0/24

For more information, see "Creating and viewing authentication tokens".

Set the token as an environment variable on the CI/CD server

Set your token as an environment variable, or a secret, in your CI/CD server.

For example, in GitHub Actions, you would add your token as a secret. Then you can make the secret available to workflows.

If you named the secret , then you would want to create an environment variable named from that secret.

steps:

- run: |

npm install

- env:

NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Consult your CI/CD server's documentation for more details.

Create and check in a project-specific .npmrc file

Use a project-specific file with a variable for your token to securely authenticate your CI/CD server with npm.

  1. In the root directory of your project, create a custom file with the following contents:

    //registry.npmjs.org/:_authToken=${NPM_TOKEN}

    Note: that you are specifying a literal value of . The npm cli will replace this value with the contents of the environment variable. Do not put a token in this file.

  2. Check in the file.

Securing your token

Your token may have permission to read private packages, publish new packages on your behalf, or change user or package settings. Protect your token.

Do not add your token to version control or store it insecurely. Store it in a package manager, your cloud provider's secure storage, or your CI/CD provider's secure storage.

Sours: https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow/


340 341 342 343 344