\n
... more content ... \n",
"versionRevision": "REVISION-SAMPLE-55C752BEE9B772FC"
}
```
# État de version du package de mise à jour
Chaque version de package CodeArtifact possède un statut qui décrit l'état actuel et la disponibilité de la version du package. Vous pouvez modifier l'état de la version du package à l'aide de la console AWS CLI et de la console.
**Note**
Pour plus d'informations sur l'état de la version du package, y compris une liste des statuts disponibles, consultez[État de la version du package](packages-overview.md#package-version-status).
## Mettre à jour le statut de version du package
La définition du statut d'une version de package permet de contrôler la manière dont une version de package peut être utilisée sans la supprimer complètement du référentiel. Par exemple, lorsqu'une version de package a le statut de`Unlisted`, elle peut toujours être téléchargée normalement, mais elle n'apparaîtra pas dans les listes de versions de package renvoyées à des commandes telles que`npm view`. L'[UpdatePackageVersionsStatus API](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html) permet de définir l'état de version de plusieurs versions d'un même package en un seul appel d'API. Pour une description des différents statuts, voir[Vue d'ensemble des packages](packages-overview.md).
Utilisez la `update-package-versions-status` commande pour modifier le statut d'une version de package en `Published``Unlisted`, ou`Archived`. Pour connaître les autorisations IAM requises pour utiliser la commande, consultez[Autorisations IAM requises pour mettre à jour l'état de la version d'un package](#update-package-version-status-iam). L'exemple suivant définit le statut de la version 4.1.0 du package `chalk` npm sur. `Archived`
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 --target-status Archived
```
Exemple de sortie :
```
{
"successfulVersions": {
"4.1.0": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Cet exemple utilise un package npm, mais la commande fonctionne de la même manière pour les autres formats. Plusieurs versions peuvent être déplacées vers le même statut cible à l'aide d'une seule commande, voir l'exemple suivant.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.1.1 --target-status Archived
```
Exemple de sortie :
```
{
"successfulVersions": {
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Archived"
},
"4.1.1": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Notez qu'une fois publiée, une version de package ne peut pas être replacée dans cet `Unfinished` état. Ce statut n'est donc pas autorisé en tant que valeur pour le `--target-status` paramètre. Pour déplacer la version du package vers l'`Disposed`état, utilisez plutôt la `dispose-package-versions` commande comme décrit ci-dessous.
## Autorisations IAM requises pour mettre à jour l'état de la version d'un package
`update-package-versions-status`Pour demander un package, vous devez avoir l'`codeartifact:UpdatePackageVersionsStatus`autorisation d'accéder à la ressource du package. Cela signifie que vous pouvez accorder l'autorisation `update-package-versions-status` d'appeler pour chaque forfait. Par exemple, une politique IAM qui accorde l'autorisation d'appeler `update-package-versions-status` le package npm *chalk* inclurait une déclaration comme celle-ci.
```
{
"Action": [
"codeartifact:UpdatePackageVersionsStatus"
],
"Effect": "Allow",
"Resource": "arn:aws:codeartifact:us-east-1:111122223333:package/my_domain/my_repo/npm//chalk"
}
```
## Mise à jour de l'état d'un package npm délimité
Pour mettre à jour l'état de la version du package d'une version de package npm avec une portée, utilisez le `--namespace` paramètre. Par exemple, pour annuler la liste de la version 8.0.0 de`@nestjs/core`, utilisez la commande suivante.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --namespace nestjs
--package core --versions 8.0.0 --target-status Unlisted
```
## Mettre à jour le statut d'un package Maven
Les packages Maven ont toujours un identifiant de groupe, appelé espace de noms dans. CodeArtifact Utilisez le `--namespace` paramètre pour spécifier l'ID du groupe Maven lors de l'appel`update-package-versions-status`. Par exemple, pour archiver la version 2.13.1 du package Maven`org.apache.logging.log4j:log4j`, utilisez la commande suivante.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format maven
--namespace org.apache.logging.log4j --package log4j
--versions 2.13.1 --target-status Archived
```
## Spécification d'une révision de version de package
Une révision de version de package est une chaîne qui spécifie un ensemble spécifique de ressources et de métadonnées pour une version de package. Vous pouvez spécifier une révision de version de package pour mettre à jour le statut des versions de package qui se trouvent dans un état spécifique. Pour spécifier une révision de version de package, utilisez le `--version-revisions` paramètre pour transmettre une ou plusieurs versions de package séparées par des virgules et les paires de révisions de version de package. L'état d'une version de package ne sera mis à jour que si la révision actuelle de la version de package correspond à la valeur spécifiée.
**Note**
Le `—-versions` paramètre doit également être défini lors de son `--version-revisions` utilisation.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8bzVMJ4="
--versions 4.1.0 --target-status Archived
```
Pour mettre à jour plusieurs versions à l'aide d'une seule commande, transmettez aux options une liste séparée par des virgules de paires de versions et de révisions de `--version-revisions` version. L'exemple de commande suivant définit deux paires différentes de version de package et de révision de version de package.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm
--package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Published
```
Exemple de sortie :
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Published"
},
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Published"
}
},
"failedVersions": {}
}
```
Lors de la mise à jour de plusieurs versions de package, les versions transmises `--version-revisions` doivent être les mêmes que celles transmises`--versions`. Si une révision n'est pas spécifiée correctement, le statut de cette version ne sera pas mis à jour.
## Utilisation du paramètre d'état attendu
La `update-package-versions-status` commande fournit le `--expected-status` paramètre qui permet de spécifier l'état actuel attendu d'une version de package. Si le statut actuel ne correspond pas à la valeur transmise`--expected-status`, le statut de cette version du package ne sera pas mis à jour.
Par exemple, dans*my\$1repo*, les versions 4.0.0 et 4.1.0 du package npm ont `chalk` actuellement un statut de. `Published` Un appel indiquant un statut attendu de `Unlisted` échouera à mettre à jour les deux versions du package en raison de l'incompatibilité des statuts. `update-package-versions-status`
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.0.0 --target-status Archived --expected-status Unlisted
```
Exemple de sortie :
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
},
"4.1.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
## Erreurs liées aux différentes versions de package
Il existe plusieurs raisons pour lesquelles le statut d'une version de package ne sera pas mis à jour lors de l'appel`update-package-versions-status`. Par exemple, la révision de la version du package a peut-être été spécifiée de manière incorrecte ou le statut attendu ne correspond pas à l'état actuel. Dans ces cas, la version sera incluse dans la `failedVersions` carte dans la réponse de l'API. Si une version échoue, les autres versions spécifiées dans le même appel à `update-package-versions-status` peuvent être ignorées et leur statut n'est pas mis à jour. Ces versions seront également incluses dans la `failedVersions` carte avec un `errorCode` de`SKIPPED`.
Dans l'implémentation actuelle de`update-package-versions-status`, si le statut d'une ou de plusieurs versions ne peut pas être modifié, toutes les autres versions seront ignorées. En d'autres termes, soit toutes les versions sont mises à jour avec succès, soit aucune version n'est mise à jour. Ce comportement n'est pas garanti dans le contrat d'API ; à l'avenir, certaines versions pourraient réussir tandis que d'autres échoueront en un seul appel à`update-package-versions-status`.
L'exemple de commande suivant inclut un échec de mise à jour de l'état de version causé par une incompatibilité de version de version de package. Cet échec de mise à jour entraîne l'annulation d'un autre appel de mise à jour de l'état de la version.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo
--format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Archived
```
Exemple de sortie :
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "SKIPPED",
"errorMessage": "version 4.0.0 is skipped"
},
"4.1.0": {
"errorCode": "MISMATCHED_REVISION",
"errorMessage": "current revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=, expected revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ="
}
}
}
```
## Élimination des versions du package
Le statut `Disposed` du package a un comportement similaire à celui du package`Archived`, sauf que les actifs du package seront définitivement supprimés, de CodeArtifact sorte que le compte du propriétaire du domaine ne sera plus facturé pour le stockage des actifs. Pour plus d'informations sur le statut de chaque version de package, consultez[État de la version du package](packages-overview.md#package-version-status). Pour modifier le statut d'une version de package en`Disposed`, utilisez la `dispose-package-versions` commande. Cette fonctionnalité est distincte du `update-package-versions-status` fait que la suppression d'une version de package n'est pas réversible. Dans la mesure où les actifs du package seront supprimés, le statut de la version ne peut pas être redéfini sur `Archived``Unlisted`, ou`Published`. La seule action qui peut être entreprise sur une version de package qui a été supprimée est de la supprimer à l'aide de la `delete-package-versions` commande.
Pour que l'appel soit `dispose-package-versions` réussi, le principal IAM appelant doit avoir l'`codeartifact:DisposePackageVersions`autorisation d'accéder à la ressource du package.
Le comportement de la `dispose-package-versions` commande est similaire à `update-package-versions-status` celui des `--expected-status` options `--version-revisions ` et décrites dans les sections sur la [révision de la version](#update-status-specify-package-version-revision) et sur le [statut attendu](#using-expected-status). Par exemple, la commande suivante tente de supprimer une version de package mais échoue en raison d'un état attendu qui ne correspond pas.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Unlisted
```
Exemple de sortie :
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
Si la même commande est exécutée à nouveau avec un `--expected-status` de`Published`, la destruction réussira.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Published
```
Exemple de sortie :
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Disposed"
}
},
"failedVersions": {}
}
```
# Modification des contrôles d'origine des packages
Dans AWS CodeArtifact, les versions de package peuvent être ajoutées à un référentiel en les publiant directement, en les extrayant d'un référentiel en amont ou en les ingérant depuis un référentiel public externe. Le fait d'autoriser l'ajout de versions d'un package à la fois par publication directe et par ingestion à partir de référentiels publics vous rend vulnérable aux attaques de substitution de dépendances. Pour de plus amples informations, veuillez consulter [Attaques de substitution de la dépendance](dependency-substitution-attacks.md). Pour vous protéger contre une attaque de substitution de dépendance, vous pouvez configurer les contrôles d'origine des packages sur un package dans un référentiel afin de limiter la manière dont les versions de ce package peuvent être ajoutées au référentiel.
La configuration des contrôles d'origine des packages doit être envisagée par toute équipe qui souhaite autoriser les nouvelles versions de différents packages à provenir à la fois de sources internes, telles que la publication directe, et de sources externes, telles que des référentiels publics. Par défaut, les contrôles d'origine des packages sont configurés en fonction de la manière dont la première version d'un package est ajoutée au référentiel. Pour plus d'informations sur les paramètres de contrôle de l'origine des packages et leurs valeurs par défaut, consultez[Paramètres de contrôle de l'origine des packages](#package-origin-control-settings).
Pour supprimer l'enregistrement du package après avoir utilisé l'opération `put-package-origin-configuration` API, utilisez `delete-package` (voir[Supprimer un package ou une version de package](delete-package.md)).
## Scénarios courants de contrôle d'accès aux packages
Cette section inclut certains scénarios courants lorsqu'une version de package est ajoutée à un CodeArtifact référentiel. Les paramètres de contrôle de l'origine des packages seront définis pour les nouveaux packages en fonction de la manière dont la première version du package est ajoutée.
Dans les scénarios suivants, un *package interne* est un package publié directement depuis un gestionnaire de packages vers votre référentiel, tel qu'un package que vous ou votre équipe créez et gérez. Un *package externe* est un package existant dans un dépôt public qui peut être ingéré dans votre référentiel via une connexion externe.
**Une version de package externe est publiée pour un package interne existant**
Dans ce scénario, considérez un package interne, *PackageA*. Votre équipe publie la première version du package pour *PackageA dans un* CodeArtifact référentiel. Comme il s'agit de la première version de package pour ce package, les paramètres de contrôle de l'origine du package sont automatiquement définis **sur Publier : Autoriser** et **Upstream : Bloquer**. Une fois que le package existe dans votre dépôt, un package portant le même nom est publié dans un dépôt public connecté à votre CodeArtifact dépôt. Il peut s'agir d'une tentative d'attaque de substitution de dépendance contre le package interne ou d'une simple coïncidence. Quoi qu'il en soit, les contrôles d'origine des packages sont configurés pour bloquer l'ingestion de la nouvelle version externe afin de se protéger contre une attaque potentielle.
Dans l'image suivante, *RePoA* est votre CodeArtifact dépôt avec une connexion externe à un dépôt public. Votre dépôt contient les versions 1.1 et 2.1 de *PackageA*, mais la version 3.0 est publiée dans le dépôt public. Normalement, *RePoA* ingère la version 3.0 une fois que le package a été demandé par un gestionnaire de packages. L'ingestion de packages étant définie sur **Bloquer**, la version 3.0 n'est pas ingérée dans votre CodeArtifact référentiel et n'est pas disponible pour les gestionnaires de packages qui y sont connectés.
![\[Graphique simple illustrant le blocage d'une nouvelle version de package externe dans un dépôt public.\]](http://docs.aws.amazon.com/fr_fr/codeartifact/latest/ug/images/package-origin-controls-one.png)
**Une version de package interne est publiée pour un package externe existant**
Dans ce scénario, un package, *PackageB*, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande *PackageB*, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de *PackageB* ajoutée à votre référentiel, les paramètres d'origine du package sont configurés sur **Publish : BLOCK et Upstream :** **ALLOW**. Plus tard, vous essayez de publier une version portant le même nom de package dans le référentiel. Soit vous ne connaissez pas le package public et vous essayez de publier un package indépendant sous le même nom, soit vous essayez de publier une version corrigée, soit vous essayez de publier directement la version exacte du package qui existe déjà en externe. CodeArtifact rejettera la version que vous essayez de publier, mais vous permettra d'annuler explicitement le rejet et de publier la version si nécessaire.
Dans l'image suivante, *RePoA* est votre CodeArtifact dépôt avec une connexion externe à un dépôt public. Votre dépôt contient la version 3.0 qu'il a ingérée depuis le dépôt public. Vous souhaitez publier la version 1.1 dans votre dépôt. Normalement, vous pouvez publier la version 1.2 sur *RePoA*, mais comme la publication est définie sur **Bloquer**, la version 1.2 ne peut pas être publiée.
![\[Graphique simple illustrant le blocage d'une nouvelle version de package externe dans un dépôt public.\]](http://docs.aws.amazon.com/fr_fr/codeartifact/latest/ug/images/package-origin-controls-two.png)
**Publication d'une version de package corrigée d'un package externe existant**
Dans ce scénario, un package, *PackageB*, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande *PackageB*, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de *PackageB* ajoutée à votre référentiel, les paramètres d'origine du package sont configurés sur **Publish : BLOCK et Upstream :** **ALLOW**. Votre équipe décide qu'elle doit publier les versions patchées de ce package dans le référentiel. Pour pouvoir publier directement les versions des packages, votre équipe modifie les paramètres de contrôle de l'origine des packages en **Publish : ALLOW** et **Upstream : BLOCK**. Les versions de ce package peuvent désormais être publiées directement dans votre dépôt et ingérées à partir de référentiels publics. Une fois que votre équipe a publié les versions du package corrigées, elle rétablit les paramètres d'origine du package sur **Publish : BLOCK et Upstream :** **ALLOW**.
## Paramètres de contrôle de l'origine des packages
Grâce aux contrôles de l'origine des packages, vous pouvez configurer la manière dont les versions des packages peuvent être ajoutées à un référentiel. Les listes suivantes incluent les paramètres et valeurs de contrôle d'origine des packages disponibles.
**Note**
Les paramètres et valeurs disponibles sont différents lors de la configuration des contrôles d'origine sur les groupes de packages. Pour de plus amples informations, veuillez consulter [Contrôles d'origine des groupes de packages](package-group-origin-controls.md).
**Publish**
Ce paramètre permet de configurer si les versions des packages peuvent être publiées directement dans le référentiel à l'aide de gestionnaires de packages ou d'outils similaires.
+ **AUTORISER** : les versions du package peuvent être publiées directement.
+ **BLOCK** : Les versions du package ne peuvent pas être publiées directement.
**En amont**
Ce paramètre définit si les versions des packages peuvent être ingérées à partir de référentiels publics externes ou conservées à partir de référentiels en amont à la demande d'un gestionnaire de packages.
+ **AUTORISER** : Toute version de package peut être conservée à partir d'autres CodeArtifact référentiels configurés en tant que référentiels en amont ou ingérée à partir d'une source publique via une connexion externe.
+ **BLOCAGE** : Les versions de package ne peuvent pas être conservées à partir d'autres CodeArtifact référentiels configurés comme référentiels en amont ou ingérées à partir d'une source publique avec une connexion externe.
## Paramètres de contrôle de l'origine des packages par défaut
Les paramètres de contrôle d'origine des packages par défaut sont configurés en fonction des paramètres de contrôle d'origine du groupe de packages associé au package. Pour plus d'informations sur les groupes de packages et les contrôles d'origine des groupes de packages, consultez [Utilisation de groupes de packages dans CodeArtifact](package-groups.md) et[Contrôles d'origine des groupes de packages](package-group-origin-controls.md).
Si un package est associé à un groupe de packages avec des paramètres de restriction `ALLOW` correspondant à chaque type de restriction, les contrôles d'origine du package par défaut pour un package seront basés sur la manière dont la première version de ce package est ajoutée au référentiel.
+ Si la première version du package est publiée directement par un gestionnaire de packages, les paramètres seront **Publish : ALLOW** et **Upstream : BLOCK.**
+ Si la première version du package est ingérée à partir d'une source publique, les paramètres seront **Publish : BLOCK** et **Upstream : ALLOW**.
**Note**
Les packages qui existaient dans CodeArtifact des référentiels avant mai 2022 environ seront dotés de contrôles d'origine par défaut tels que **Publish : ALLOW** et **Upstream : ALLOW**. Les contrôles d'origine des packages doivent être définis manuellement pour ces packages. Les valeurs par défaut actuelles ont été définies sur les nouveaux packages depuis lors et ont commencé à être appliquées lorsque la fonctionnalité a été lancée le 14 juillet 2022. Pour plus d'informations sur la définition des contrôles d'origine des packages, consultez[Modification des contrôles d'origine des packages](#edit-package-origin-controls).
Sinon, si un package est associé à un groupe de packages dont au moins un paramètre de restriction est `BLOCK` ou`ALLOW_SPECIFIC_REPOSITORIES`, les paramètres de contrôle d'origine par défaut pour ce package seront définis sur **Publish : ALLOW** et **Upstream : ALLOW**.
## Comment les contrôles d'origine des packages interagissent avec les contrôles d'origine des groupes de packages
Étant donné que les packages ont des paramètres de contrôle d'origine et que les groupes de packages associés ont des paramètres de contrôle d'origine, il est important de comprendre comment ces deux paramètres différents interagissent les uns avec les autres.
L'interaction entre les deux paramètres est qu'un paramètre de l'emporte `BLOCK` toujours sur un paramètre de`ALLOW`. Le tableau suivant répertorie quelques exemples de configurations et leurs paramètres de contrôle d'origine effectifs.
| Paramètre de contrôle de l'origine du package | Paramètre de contrôle de l'origine du groupe de packages | Paramètre de contrôle d'origine efficace |
| --- | --- | --- |
| PUBLIER : AUTORISEREN AMONT : AUTORISER | PUBLIER : AUTORISEREN AMONT : AUTORISER | PUBLIER : AUTORISEREN AMONT : AUTORISER |
| PUBLIER : BLOQUEREN AMONT : AUTORISER | PUBLIER : AUTORISEREN AMONT : AUTORISER | PUBLIER : BLOQUEREN AMONT : AUTORISER |
| PUBLIER : AUTORISEREN AMONT : AUTORISER | PUBLIER : AUTORISEREN AMONT : BLOC | PUBLIER : AUTORISEREN AMONT : BLOC |
Cela signifie qu'un package dont les paramètres d'origine sont **Publish : ALLOW** et **Upstream : ALLOW** s'en remet effectivement aux paramètres de contrôle d'origine du groupe de packages associé.
## Modification des contrôles d'origine des packages
Les contrôles d'origine des packages sont configurés automatiquement en fonction de la manière dont la première version d'un package est ajoutée au référentiel. Pour plus d'informations, voir[Paramètres de contrôle de l'origine des packages par défaut](#default-package-origin-control-settings). Pour ajouter ou modifier des contrôles d'origine de package pour un package dans un CodeArtifact référentiel, effectuez les étapes de la procédure suivante.
**Pour ajouter ou modifier les contrôles d'origine des packages (console)**
1. Ouvrez la AWS CodeArtifact console sur [https://console.aws.amazon.com/codesuite/codeartifact/home](https://console.aws.amazon.com/codesuite/codeartifact/home).
1. Dans le volet de navigation, choisissez **Repositories**, puis le référentiel contenant le package que vous souhaitez modifier.
1. Dans le tableau **Packages**, recherchez et sélectionnez le package que vous souhaitez modifier.
1. Sur la page récapitulative du package, dans les **commandes Origin**, choisissez **Modifier**.
1. Dans **Modifier les contrôles d'origine**, choisissez les contrôles d'origine du package que vous souhaitez définir pour ce package. Les deux paramètres de contrôle de l'origine du package, Publish et Upstream, doivent être définis en même temps.
+ Pour autoriser la publication directe des versions du package, dans **Publier**, sélectionnez **Autoriser**. Pour bloquer la publication des versions du package, choisissez **Bloquer**.
+ **Pour autoriser l'ingestion de packages provenant de référentiels externes et l'extraction de packages depuis des référentiels en amont, dans **Sources en amont**, sélectionnez Autoriser.** Pour bloquer toute ingestion et extraction de versions de packages depuis des référentiels externes et en amont, choisissez **Bloquer.**
**Pour ajouter ou modifier les contrôles d'origine des packages (AWS CLI)**
1. Si ce n'est pas le cas, configurez le AWS CLI en suivant les étapes décrites dans[Configuration avec AWS CodeArtifact](get-set-up-for-codeartifact.md).
1. Utilisez la `put-package-origin-configuration` commande pour ajouter ou modifier les contrôles d'origine des packages. Remplacez les champs suivants :
+ *my\$1domain*Remplacez-le par le CodeArtifact domaine qui contient le package que vous souhaitez mettre à jour.
+ *my\$1repo*Remplacez-le par le CodeArtifact référentiel qui contient le package que vous souhaitez mettre à jour.
+ *npm*Remplacez-le par le format du package que vous souhaitez mettre à jour.
+ *my\$1package*Remplacez-le par le nom du package que vous souhaitez mettre à jour.
+ Remplacez *ALLOW* et par *BLOCK* les paramètres de contrôle de l'origine des packages souhaités.
```
aws codeartifact put-package-origin-configuration --domain my_domain \
--repository my_repo --format npm --package my_package \
--restrictions publish=ALLOW,upstream=BLOCK
```
## Publication et référentiels en amont
CodeArtifact n'autorise pas la publication de versions de packages présentes dans des référentiels en amont ou des référentiels publics accessibles. Supposons, par exemple, que vous souhaitiez publier un package `com.mycompany.mypackage:1.0` Maven dans un référentiel et que vous `myrepo` disposiez `myrepo` d'un référentiel en amont avec une connexion externe à Maven Central. Envisagez les scénarios suivants.
1. Les paramètres de contrôle de l'origine du package `com.mycompany.mypackage` sont **Publish : ALLOW** et **Upstream : ALLOW**. S'il `com.mycompany.mypackage:1.0` est présent dans le référentiel en amont ou dans Maven Central, CodeArtifact rejette toute tentative de publication dans ce référentiel `myrepo` avec une erreur de conflit 409. Vous pouvez toujours publier une version différente, telle que`com.mycompany.mypackage:1.1`.
1. Les paramètres de contrôle de l'origine du package `com.mycompany.mypackage` sont **Publish : ALLOW** et **Upstream : BLOCK**. Vous pouvez publier dans votre référentiel n'importe quelle version de `com.mycompany.mypackage` qui n'existe pas encore car les versions des packages ne sont pas accessibles.
1. Les paramètres de contrôle de l'origine du package `com.mycompany.mypackage` sont **Publish : BLOCK** et **Upstream : ALLOW**. Vous ne pouvez publier aucune version de package directement dans votre référentiel.