\n
... more content ... \n",
"versionRevision": "REVISION-SAMPLE-55C752BEE9B772FC"
}
```
# Aktualisiere den Status der Paketversion
Jede Paketversion in CodeArtifact hat einen Status, der den aktuellen Status und die Verfügbarkeit der Paketversion beschreibt. Sie können den Status der Paketversion sowohl mit der AWS CLI als auch mit der Konsole ändern.
**Anmerkung**
Weitere Informationen zum Status der Paketversion, einschließlich einer Liste der verfügbaren Status, finden Sie unter[Status der Paketversion](packages-overview.md#package-version-status).
## Der Status der Paketversion wird aktualisiert
Wenn Sie den Status einer Paketversion festlegen, können Sie steuern, wie eine Paketversion verwendet werden kann, ohne sie vollständig aus dem Repository zu löschen. Wenn eine Paketversion beispielsweise den Status hat`Unlisted`, kann sie weiterhin wie gewohnt heruntergeladen werden, erscheint aber nicht in den Paketversionslisten, die auf Befehle wie zurückgegeben werden`npm view`. Die [UpdatePackageVersionsStatus API](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html) ermöglicht das Festlegen des Paketversionsstatus mehrerer Versionen desselben Pakets in einem einzigen API-Aufruf. Eine Beschreibung der verschiedenen Status finden Sie unter[Überblick über Pakete](packages-overview.md).
Verwenden Sie den `update-package-versions-status` Befehl, um den Status einer Paketversion in `Published``Unlisted`, oder `Archived` zu ändern. Informationen zu den für die Verwendung des Befehls erforderlichen IAM-Berechtigungen finden Sie unter[Erforderliche IAM-Berechtigungen, um den Status einer Paketversion zu aktualisieren](#update-package-version-status-iam). Im folgenden Beispiel wird der Status von Version 4.1.0 des npm-Pakets auf gesetzt. `chalk` `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
```
Beispielausgabe:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
In diesem Beispiel wird ein npm-Paket verwendet, aber der Befehl funktioniert auch für andere Formate. Mehrere Versionen können mit einem einzigen Befehl in denselben Zielstatus versetzt werden, siehe das folgende Beispiel.
```
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
```
Beispielausgabe:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Archived"
},
"4.1.1": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Beachten Sie, dass eine einmal veröffentlichte Paketversion nicht wieder in den `Unfinished` Status zurückversetzt werden kann. Daher ist dieser Status als Wert für den `--target-status` Parameter nicht zulässig. Um die Paketversion in den `Disposed` Status zu verschieben, verwenden Sie stattdessen den `dispose-package-versions` Befehl wie unten beschrieben.
## Erforderliche IAM-Berechtigungen, um den Status einer Paketversion zu aktualisieren
Um ein Paket `update-package-versions-status` anfordern zu können, müssen Sie über die `codeartifact:UpdatePackageVersionsStatus` entsprechende Berechtigung für die Paketressource verfügen. Das bedeutet, dass Sie die Berechtigung `update-package-versions-status` zum Aufrufen pro Paket erteilen können. Eine IAM-Richtlinie, die die Erlaubnis zum Aufrufen `update-package-versions-status` des npm-Pakets erteilt, *chalk* würde beispielsweise eine Aussage wie die folgende enthalten.
```
{
"Action": [
"codeartifact:UpdatePackageVersionsStatus"
],
"Effect": "Allow",
"Resource": "arn:aws:codeartifact:us-east-1:111122223333:package/my_domain/my_repo/npm//chalk"
}
```
## Der Status eines NPM-Pakets mit Gültigkeitsbereich wird aktualisiert
Verwenden Sie den Parameter, um den Paketversionsstatus einer npm-Paketversion mit einem Bereich zu aktualisieren. `--namespace` Verwenden Sie beispielsweise den folgenden Befehl, um die Liste der Version 8.0.0 von `@nestjs/core` aufzuheben.
```
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
```
## Status für ein Maven-Paket wird aktualisiert
Maven-Pakete haben immer eine Gruppen-ID, die in als Namespace bezeichnet wird. CodeArtifact Verwenden Sie den `--namespace` Parameter, um die Maven-Gruppen-ID beim Aufrufen anzugeben. `update-package-versions-status` Verwenden Sie beispielsweise den folgenden Befehl, um Version 2.13.1 des Maven-Pakets `org.apache.logging.log4j:log4j` zu archivieren.
```
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
```
## Angabe einer Paketversionsrevision
Eine Paketversionsrevision ist eine Zeichenfolge, die einen bestimmten Satz von Elementen und Metadaten für eine Paketversion angibt. Sie können eine Paketversionsrevision angeben, um den Status von Paketversionen zu aktualisieren, die sich in einem bestimmten Status befinden. Um eine Paketversionsrevision anzugeben, verwenden Sie den `--version-revisions` Parameter, um eine oder mehrere durch Kommas getrennte Paketversionen und die Revisionspaare der Paketversionen zu übergeben. Der Status einer Paketversion wird nur aktualisiert, wenn die aktuelle Version der Paketversion dem angegebenen Wert entspricht.
**Anmerkung**
Der `—-versions` Parameter muss auch definiert werden, wenn der `--version-revisions` Parameter verwendet wird.
```
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
```
Um mehrere Versionen mit einem einzigen Befehl zu aktualisieren, übergeben Sie den Optionen eine kommagetrennte Liste von Versions- und Versionsrevisionspaaren. `--version-revisions` Der folgende Beispielbefehl definiert zwei verschiedene Revisionspaare für Paketversion und Paketversion.
```
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
```
Beispielausgabe:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Published"
},
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Published"
}
},
"failedVersions": {}
}
```
Wenn mehrere Paketversionen aktualisiert werden, `--version-revisions` müssen die übergebenen Versionen mit den Versionen identisch sein, an die übergeben wurde`--versions`. Wenn eine Revision falsch angegeben wurde, wird der Status dieser Version nicht aktualisiert.
## Verwenden Sie den erwarteten Statusparameter
Der `update-package-versions-status` Befehl stellt den `--expected-status` Parameter bereit, der die Angabe des erwarteten aktuellen Status einer Paketversion unterstützt. Wenn der aktuelle Status nicht mit dem übergebenen Wert übereinstimmt`--expected-status`, wird der Status dieser Paketversion nicht aktualisiert.
Beispielsweise haben die Versionen 4.0.0 und 4.1.0 des npm-Pakets `chalk` derzeit den Status. *my\$1repo* `Published` Bei einem Aufruf`update-package-versions-status`, der den erwarteten Status von angibt, können beide Paketversionen nicht aktualisiert `Unlisted` werden, da der Status nicht übereinstimmt.
```
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
```
Beispielausgabe:
```
{
"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"
}
}
}
```
## Fehler bei einzelnen Paketversionen
Es gibt mehrere Gründe, warum der Status einer Paketversion beim Aufrufen nicht aktualisiert wird`update-package-versions-status`. Beispielsweise wurde die Revision der Paketversion möglicherweise falsch angegeben oder der erwartete Status entspricht nicht dem aktuellen Status. In diesen Fällen wird die Version in der `failedVersions` Map in der API-Antwort enthalten sein. Wenn eine Version fehlschlägt, werden andere Versionen, die im selben Aufruf von angegeben wurden, `update-package-versions-status` möglicherweise übersprungen und ihr Status wird nicht aktualisiert. Solche Versionen werden auch mit dem Wert `errorCode` von `SKIPPED` in die `failedVersions` Map aufgenommen.
In der aktuellen Implementierung von werden alle anderen Versionen übersprungen`update-package-versions-status`, wenn der Status einer oder mehrerer Versionen nicht geändert werden kann. Das heißt, entweder wurden alle Versionen erfolgreich aktualisiert oder es wurden keine Versionen aktualisiert. Dieses Verhalten ist im API-Vertrag nicht garantiert. In future könnten einige Versionen erfolgreich sein, während andere Versionen bei einem einzigen Aufruf von fehlschlagen`update-package-versions-status`.
Der folgende Beispielbefehl beinhaltet einen Fehler bei der Aktualisierung des Versionsstatus, der auf eine nicht übereinstimmende Paketversion zurückzuführen ist. Dieser Aktualisierungsfehler führt dazu, dass ein weiterer Aufruf zur Aktualisierung des Versionsstatus übersprungen wird.
```
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
```
Beispielausgabe:
```
{
"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="
}
}
}
```
## Entsorgung von Paketversionen
Der `Disposed` Paketstatus verhält sich ähnlich wie`Archived`, mit dem Unterschied, dass die Paket-Assets dauerhaft gelöscht werden, CodeArtifact sodass dem Konto des Domaininhabers keine Kosten mehr für den Asset-Speicher in Rechnung gestellt werden. Weitere Informationen zum Status der einzelnen Paketversionen finden Sie unter[Status der Paketversion](packages-overview.md#package-version-status). Verwenden Sie den `dispose-package-versions` Befehl`Disposed`, um den Status einer Paketversion auf zu zu ändern. Diese Funktion ist unabhängig davon`update-package-versions-status`, dass das Löschen einer Paketversion nicht rückgängig gemacht werden kann. Da die Paketressourcen gelöscht werden, kann der Status der Version nicht wieder auf `Archived``Unlisted`, oder `Published` zurückgesetzt werden. Die einzige Aktion, die für eine entsorgte Paketversion ausgeführt werden kann, besteht darin, sie mithilfe des `delete-package-versions` Befehls zu löschen.
Für einen `dispose-package-versions` erfolgreichen Aufruf muss der aufrufende IAM-Principal über die `codeartifact:DisposePackageVersions` entsprechende Berechtigung für die Paketressource verfügen.
Das Verhalten des `dispose-package-versions` Befehls ist ähnlich wie`update-package-versions-status`, einschließlich des Verhaltens der `--expected-status` Optionen `--version-revisions ` und, die in den Abschnitten [Versionsrevision](#update-status-specify-package-version-revision) und [Erwarteter Status](#using-expected-status) beschrieben sind. Der folgende Befehl versucht beispielsweise, eine Paketversion zu löschen, schlägt jedoch fehl, weil der erwartete Status nicht übereinstimmt.
```
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
```
Beispielausgabe:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
Wenn derselbe Befehl erneut mit einem `--expected-status` of ausgeführt wird`Published`, ist die Löschung erfolgreich.
```
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
```
Beispielausgabe:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Disposed"
}
},
"failedVersions": {}
}
```
# Einstellungen zur Paketherkunft bearbeiten
In können Paketversionen einem Repository hinzugefügt werden AWS CodeArtifact, indem sie direkt veröffentlicht, aus einem Upstream-Repository heruntergeladen oder aus einem externen, öffentlichen Repository aufgenommen werden. Wenn Sie zulassen, dass Paketversionen eines Pakets sowohl durch direkte Veröffentlichung als auch durch Aufnahme aus öffentlichen Repositorys hinzugefügt werden, sind Sie anfällig für Angriffe, die Abhängigkeiten ersetzen. Weitere Informationen finden Sie unter [Angriffe zur Substitution von Abhängigkeiten](dependency-substitution-attacks.md). Um sich vor einem Angriff durch die Substitution von Abhängigkeiten zu schützen, können Sie die Kontrolle des Paketursprungs für ein Paket in einem Repository konfigurieren, um einzuschränken, wie Versionen dieses Pakets dem Repository hinzugefügt werden können.
Die Konfiguration von Kontrollen zur Paketherkunft sollte von jedem Team in Betracht gezogen werden, das zulassen möchte, dass neue Versionen verschiedener Pakete sowohl aus internen Quellen wie Direktveröffentlichungen als auch aus externen Quellen wie öffentlichen Repositorien stammen. Standardmäßig werden die Kontrollen für den Paketursprung darauf konfiguriert, wie die erste Version eines Pakets zum Repository hinzugefügt wird. Hinweise zu den Einstellungen für die Steuerung des Paketursprungs und deren Standardwerte finden Sie unter[Einstellungen zur Kontrolle des Paketursprungs](#package-origin-control-settings).
Um den Paketdatensatz nach der Verwendung des `put-package-origin-configuration` API-Vorgangs zu entfernen, verwenden Sie `delete-package` (siehe[Löschen Sie ein Paket oder eine Paketversion](delete-package.md)).
## Allgemeine Szenarien zur Paketzugriffskontrolle
Dieser Abschnitt enthält einige allgemeine Szenarien, wenn eine Paketversion zu einem CodeArtifact Repository hinzugefügt wird. Die Einstellungen zur Kontrolle des Paketursprungs werden für neue Pakete festgelegt, je nachdem, wie die erste Paketversion hinzugefügt wird.
In den folgenden Szenarien ist ein *internes Paket* ein Paket, das direkt von einem Paketmanager in Ihrem Repository veröffentlicht wird, z. B. ein Paket, das Sie oder Ihr Team erstellen und verwalten. Ein *externes Paket* ist ein Paket, das in einem öffentlichen Repository vorhanden ist und über eine externe Verbindung in Ihr Repository aufgenommen werden kann.
**Eine externe Paketversion wird für ein vorhandenes internes Paket veröffentlicht**
Stellen Sie sich in diesem Szenario ein internes Paket, *PackageA*, vor. Ihr Team veröffentlicht die erste Paketversion für *PackageA in einem Repository*. CodeArtifact Da dies die erste Paketversion für dieses Paket ist, werden die Einstellungen für die Kontrolle des Paketursprungs automatisch auf **Veröffentlichen: Zulassen und **Upstream:**** Blockieren gesetzt. Sobald das Paket in Ihrem Repository vorhanden ist, wird ein Paket mit demselben Namen in einem öffentlichen Repository veröffentlicht, das mit Ihrem CodeArtifact Repository verbunden ist. Dies könnte ein versuchter Angriff zur Substitution von Abhängigkeiten auf das interne Paket sein, oder es könnte auch einfach ein Zufall sein. Unabhängig davon sind die Kontrollen zur Paketherkunft so konfiguriert, dass sie die Aufnahme der neuen externen Version blockieren, um sich vor einem möglichen Angriff zu schützen.
In der folgenden Abbildung ist *RepoA* Ihr CodeArtifact Repository mit einer externen Verbindung zu einem öffentlichen Repository. Ihr Repository enthält die Versionen 1.1 und 2.1 von *PackageA*, aber Version 3.0 ist im öffentlichen Repository veröffentlicht. Normalerweise würde *RepoA* Version 3.0 aufnehmen, nachdem das Paket von einem Paketmanager angefordert wurde. Da die Paketaufnahme auf **Blockieren** gesetzt ist, wird Version 3.0 nicht in Ihr CodeArtifact Repository aufgenommen und steht den damit verbundenen Paketmanagern nicht zur Verfügung.
![\[Einfache Grafik, die zeigt, dass eine neue externe Paketversion aus einem öffentlichen Repository blockiert wird.\]](http://docs.aws.amazon.com/de_de/codeartifact/latest/ug/images/package-origin-controls-one.png)
**Eine interne Paketversion wird für ein vorhandenes externes Paket veröffentlicht**
In diesem Szenario existiert ein Paket, *PackageB*, extern in einem öffentlichen Repository, das Sie mit Ihrem Repository verbunden haben. Wenn ein mit Ihrem Repository verbundener Paketmanager *PackageB* anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. **Da dies die erste Paketversion von *PackageB* ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream:** ALLOW konfiguriert.** Später versuchen Sie, eine Version mit demselben Paketnamen im Repository zu veröffentlichen. Entweder kennen Sie das öffentliche Paket nicht und versuchen, ein Paket, das nichts damit zu tun hat, unter demselben Namen zu veröffentlichen, oder Sie versuchen, eine gepatchte Version zu veröffentlichen, oder Sie versuchen, genau die Paketversion, die bereits extern existiert, direkt zu veröffentlichen. CodeArtifact lehnt die Version ab, die Sie veröffentlichen möchten, ermöglicht es Ihnen jedoch, die Ablehnung explizit zu überschreiben und die Version bei Bedarf zu veröffentlichen.
In der folgenden Abbildung ist *RepoA* Ihr CodeArtifact Repository mit einer externen Verbindung zu einem öffentlichen Repository. Ihr Repository enthält Version 3.0, die es aus dem öffentlichen Repository aufgenommen hat. Sie möchten Version 1.1 in Ihrem Repository veröffentlichen. Normalerweise könnten Sie Version 1.2 in *RepoA* veröffentlichen, aber da die Veröffentlichung auf **Blockieren** eingestellt ist, kann Version 1.2 nicht veröffentlicht werden.
![\[Einfache Grafik, die zeigt, dass eine neue externe Paketversion aus einem öffentlichen Repository blockiert wird.\]](http://docs.aws.amazon.com/de_de/codeartifact/latest/ug/images/package-origin-controls-two.png)
**Veröffentlichung einer gepatchten Paketversion eines vorhandenen externen Pakets**
In diesem Szenario existiert ein Paket, *PackageB*, extern in einem öffentlichen Repository, das Sie mit Ihrem Repository verbunden haben. Wenn ein mit Ihrem Repository verbundener Paketmanager *PackageB* anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. **Da dies die erste Paketversion von *PackageB* ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream:** ALLOW konfiguriert.** Ihr Team entscheidet, dass es gepatchte Paketversionen dieses Pakets im Repository veröffentlichen muss. Um Paketversionen direkt veröffentlichen zu können, ändert Ihr Team die Einstellungen zur Kontrolle des Paketursprungs in **Publish: ALLOW** und **Upstream: BLOCK**. Versionen dieses Pakets können jetzt direkt in Ihrem Repository veröffentlicht und aus öffentlichen Repositorys aufgenommen werden. **Nachdem Ihr Team die gepatchten Paketversionen veröffentlicht hat, setzt Ihr Team die Einstellungen für den Paketursprung auf **Publish: BLOCK und Upstream: ALLOW** zurück.**
## Einstellungen zur Kontrolle des Paketursprungs
Mit den Kontrollen zur Paketherkunft können Sie konfigurieren, wie Paketversionen zu einem Repository hinzugefügt werden können. Die folgenden Listen enthalten die verfügbaren Einstellungen und Werte für die Steuerung des Paketursprungs.
**Anmerkung**
Die verfügbaren Einstellungen und Werte unterscheiden sich bei der Konfiguration der Ursprungskontrollen für Paketgruppen. Weitere Informationen finden Sie unter [Herkunftskontrollen für Paketgruppen](package-group-origin-controls.md).
**Veröffentlichen**
Diese Einstellung konfiguriert, ob Paketversionen mithilfe von Paketmanagern oder ähnlichen Tools direkt im Repository veröffentlicht werden können.
+ **ZULASSEN**: Paketversionen können direkt veröffentlicht werden.
+ **BLOCK**: Paketversionen können nicht direkt veröffentlicht werden.
**Upstream**
Diese Einstellung konfiguriert, ob Paketversionen aus externen, öffentlichen Repositorys aufgenommen oder von Upstream-Repositorys beibehalten werden können, wenn dies von einem Paketmanager angefordert wird.
+ **ALLOW**: Jede Paketversion kann aus anderen CodeArtifact Repositorys beibehalten werden, die als Upstream-Repositorys konfiguriert sind, oder von einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.
+ **BLOCKIEREN**: Paketversionen können nicht aus anderen CodeArtifact Repositorys aufbewahrt werden, die als Upstream-Repositorys konfiguriert sind, oder von einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.
## Standardeinstellungen für die Kontrolle des Paketursprungs
Die Standardeinstellungen für die Kontrolle des Paketursprungs werden auf der Grundlage der Einstellungen für die Ursprungskontrolle der Paketgruppe konfiguriert, die dem Paket zugeordnet ist. Weitere Informationen zu Paketgruppen und zur Kontrolle der Herkunft von Paketgruppen finden Sie unter [Arbeiten mit Paketgruppen in CodeArtifact](package-groups.md) und[Herkunftskontrollen für Paketgruppen](package-group-origin-controls.md).
Wenn ein Paket mit einer Paketgruppe verknüpft ist, deren Einschränkungseinstellungen `ALLOW` für jeden Einschränkungstyp aktiviert sind, basieren die Standardsteuerungen für den Paketursprung für ein Paket darauf, wie die erste Version dieses Pakets dem Repository hinzugefügt wurde.
+ Wenn die erste Paketversion direkt von einem Paketmanager veröffentlicht wird, lauten die Einstellungen **Publish: ALLOW und Upstream****: BLOCK**.
+ Wenn die erste Paketversion aus einer öffentlichen Quelle aufgenommen wurde, lauten die Einstellungen **Publish: BLOCK und **Upstream: ALLOW****.
**Anmerkung**
Für Pakete, die vor etwa Mai 2022 in CodeArtifact Repositorys existierten, gelten standardmäßig die Einstellungen **Publish: ALLOW und Upstream:** **ALLOW**. Die Kontrolle des Paketursprungs muss für solche Pakete manuell festgelegt werden. Die aktuellen Standardwerte wurden seitdem für neue Pakete festgelegt und ab dem Start der Funktion am 14. Juli 2022 durchgesetzt. Weitere Informationen zur Einstellung von Kontrollen zur Herkunft von Paketen finden Sie unter[Die Einstellungen für den Paketursprung werden bearbeitet](#edit-package-origin-controls).
Andernfalls, wenn ein Paket einer Paketgruppe zugeordnet ist, die mindestens eine Einschränkungseinstellung von `BLOCK` oder hat`ALLOW_SPECIFIC_REPOSITORIES`, dann werden die Standardeinstellungen für die Ursprungskontrolle für dieses Paket auf **Publish: ALLOW und Upstream:** **ALLOW gesetzt**.
## Wie die Kontrollen zur Herkunft von Paketen mit den Ursprungskontrollen für Paketgruppen interagieren
Da Pakete über Einstellungen für die Ursprungskontrolle und die zugehörigen Paketgruppen über Einstellungen für die Ursprungskontrolle verfügen, ist es wichtig zu verstehen, wie diese beiden unterschiedlichen Einstellungen miteinander interagieren.
Die Wechselwirkung zwischen den beiden Einstellungen besteht darin, dass eine Einstellung von `BLOCK` immer Vorrang vor einer Einstellung von hat`ALLOW`. In der folgenden Tabelle sind einige Beispielkonfigurationen und ihre effektiven Origin Control-Einstellungen aufgeführt.
| Einstellung zur Kontrolle des Paketursprungs | Einstellung zur Kontrolle des Ursprungs von Paketgruppen | Effektive Einstellung für die Ursprungskontrolle |
| --- | --- | --- |
| VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: ZULASSEN | VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: ZULASSEN | VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: ZULASSEN |
| VERÖFFENTLICHEN: BLOCKIERENSTROMAUFWÄRTS: ZULASSEN | VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: ZULASSEN | VERÖFFENTLICHEN: BLOCKIERENSTROMAUFWÄRTS: ZULASSEN |
| VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: ZULASSEN | VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: BLOCKIEREN | VERÖFFENTLICHEN: ZULASSENSTROMAUFWÄRTS: BLOCKIEREN |
Das bedeutet, dass ein Paket mit den Ursprungseinstellungen **Publish: ALLOW** und **Upstream:** ALLOW quasi auf die Origin-Control-Einstellungen der zugehörigen Paketgruppe zurückstellt.
## Die Einstellungen für den Paketursprung werden bearbeitet
Die Kontrollen zur Paketherkunft werden automatisch konfiguriert, je nachdem, wie die erste Paketversion eines Pakets zum Repository hinzugefügt wurde. Weitere Informationen finden Sie unter[Standardeinstellungen für die Kontrolle des Paketursprungs](#default-package-origin-control-settings). Gehen Sie wie folgt vor, um Steuerungen für den Paketursprung für ein Paket in einem CodeArtifact Repository hinzuzufügen oder zu bearbeiten.
**Um Steuerelemente für den Paketursprung hinzuzufügen oder zu bearbeiten (Konsole)**
1. Öffnen Sie die AWS CodeArtifact Konsole unter [https://console.aws.amazon.com/codesuite/codeartifact/home](https://console.aws.amazon.com/codesuite/codeartifact/home).
1. Wählen Sie im Navigationsbereich **Repositories** und dann das Repository aus, das das Paket enthält, das Sie bearbeiten möchten.
1. Suchen Sie in der Tabelle **Pakete** nach dem Paket, das Sie bearbeiten möchten, und wählen Sie es aus.
1. Wähle auf der Seite mit der Paketübersicht in **Origin Controls** die Option **Bearbeiten** aus.
1. Wählen **Sie unter „Ursprungskontrollen bearbeiten“** die Kontrollen für den Paketursprung aus, die Sie für dieses Paket festlegen möchten. Beide Einstellungen für die Steuerung des Paketursprungs, Publish und Upstream, müssen gleichzeitig festgelegt werden.
+ Um das direkte Veröffentlichen von Paketversionen zuzulassen, wählen Sie unter **Veröffentlichen** die Option **Zulassen** aus. Um die Veröffentlichung von Paketversionen zu blockieren, wählen Sie **Blockieren** aus.
+ **Um die Aufnahme von Paketen aus externen Repositorys und das Abrufen von Paketen aus Upstream-Repositorys zuzulassen, wählen Sie unter **Upstream-Quellen** die Option Zulassen aus.** **Um die gesamte Aufnahme und das Abrufen von Paketversionen aus externen und Upstream-Repositorys zu blockieren, wählen Sie Blockieren.**
**Um Kontrollen zur Paketherkunft hinzuzufügen oder zu bearbeiten ()AWS CLI**
1. Falls nicht, konfigurieren Sie das, AWS CLI indem Sie die Schritte unter befolgen[Einrichtung mit AWS CodeArtifact](get-set-up-for-codeartifact.md).
1. Verwenden Sie den `put-package-origin-configuration` Befehl, um Steuerelemente für den Paketursprung hinzuzufügen oder zu bearbeiten. Ersetzen Sie die folgenden Felder:
+ *my\$1domain*Ersetzen Sie es durch die CodeArtifact Domain, die das Paket enthält, das Sie aktualisieren möchten.
+ *my\$1repo*Ersetzen Sie es durch das CodeArtifact Repository, das das Paket enthält, das Sie aktualisieren möchten.
+ *npm*Ersetzen Sie es durch das Paketformat des Pakets, das Sie aktualisieren möchten.
+ *my\$1package*Ersetzen Sie es durch den Namen des Pakets, das Sie aktualisieren möchten.
+ Ersetzen Sie *ALLOW* und *BLOCK* durch Ihre gewünschten Einstellungen für die Kontrolle des Paketursprungs.
```
aws codeartifact put-package-origin-configuration --domain my_domain \
--repository my_repo --format npm --package my_package \
--restrictions publish=ALLOW,upstream=BLOCK
```
## Veröffentlichungs- und Upstream-Repositorys
CodeArtifact erlaubt nicht das Veröffentlichen von Paketversionen, die in erreichbaren Upstream-Repositorys oder öffentlichen Repositorys vorhanden sind. Nehmen wir zum Beispiel an, Sie möchten ein Maven-Paket `com.mycompany.mypackage:1.0` in einem Repository `myrepo` veröffentlichen und `myrepo` haben ein Upstream-Repository mit einer externen Verbindung zu Maven Central. Betrachten Sie die folgenden Szenarien.
1. Die Einstellungen für die Kontrolle des Paketursprungs `com.mycompany.mypackage` lauten **Publish: ALLOW** und **Upstream: ALLOW**. Wenn im Upstream-Repository oder in Maven Central vorhanden `com.mycompany.mypackage:1.0` ist, wird jeder Versuch, darin zu veröffentlichen, `myrepo` mit einem 409-Konfliktfehler CodeArtifact zurückgewiesen. Sie könnten immer noch eine andere Version veröffentlichen, z. B. `com.mycompany.mypackage:1.1`
1. Die Einstellungen für die Kontrolle des Paketursprungs `com.mycompany.mypackage` lauten **Publish: ALLOW** und **Upstream: BLOCK**. Sie können jede Version von `com.mycompany.mypackage` in Ihrem Repository veröffentlichen, die noch nicht existiert, da auf Paketversionen nicht zugegriffen werden kann.
1. Die Einstellungen zur Kontrolle des Paketursprungs `com.mycompany.mypackage` lauten **Publish: BLOCK** und **Upstream: ALLOW**. Sie können keine Paketversionen direkt in Ihrem Repository veröffentlichen.