Verloop van blob instellen

Artikel
02/03/2024

Met de Set Blob Expiry bewerking wordt een vervaldatum ingesteld voor een bestaande blob. Deze bewerking is alleen toegestaan voor accounts met hiërarchische naamruimten. Van toepassing op serviceversie 2020-02-10 en hoger.

Aanvraag

De Set Blob Expiry aanvraag kan als volgt worden samengesteld. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount door de naam van uw opslagaccount:

AANVRAAG-URI voor PUT-methode	HTTP-versie
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=expiry`	HTTP/1.1

Geëmuleerde opslagservice-URI

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de Blob Storage-poort op als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount:

AANVRAAG-URI voor PUT-methode	HTTP-versie
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=expiry`	HTTP/1.1

Zie Use the Azurite emulator for local Azure Storage development (De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkeling) voor meer informatie.

URI-parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:

Parameter	Beschrijving
`timeout`	Optioneel. De `timeout` parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie.

Aanvraagheaders

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Aanvraagheader	Beschrijving
`Authorization`	Vereist. Hiermee geeft u het verificatieschema, de accountnaam en de handtekening op. Zie Verificatie voor de Azure Storage-services voor meer informatie.
`Date` of `x-ms-date`	Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Verificatie voor de Azure Storage-services voor meer informatie.
`x-ms-version`	Vereist voor alle geverifieerde aanvragen. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
`x-ms-lease-id:<ID>`	Vereist als de blob een actieve lease heeft. Als u deze bewerking wilt uitvoeren op een blob met een actieve lease, geeft u de geldige lease-id voor deze header op.
`x-ms-expiry-option`	Vereist. Zie ExpirationOption als u de vervaldatumoptie voor de aanvraag wilt opgeven.
`x-ms-expiry-time`	Optioneel. Het tijdstip waarop het bestand is ingesteld om te verlopen. De notatie voor de vervaldatum is afhankelijk van `x-ms-expiry-option`. Zie ExpiryOption voor meer informatie.
`x-ms-client-request-id`	Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt. Zie Azure Blob Storage bewaken voor meer informatie.

ExpiryOption

U kunt de volgende waarden als header x-ms-expiry-option verzenden. Deze header is niet hoofdlettergevoelig.

Verloopoptie	Description
`RelativeToCreation`	Hiermee stelt u de vervaldatum in ten opzichte van het tijdstip waarop het bestand wordt gemaakt. `x-ms-expiry-time` moet worden opgegeven als het aantal milliseconden dat moet worden verstreken vanaf het moment van maken.
`RelativeToNow`	Hiermee stelt u de vervaldatum ten opzichte van de huidige tijd in. `x-ms-expiry-time` moet worden opgegeven als het aantal milliseconden dat vanaf de huidige tijd verstrijkt.
`Absolute`	`x-ms-expiry-time` moet worden opgegeven als een absolute tijd, in RFC 1123-indeling.
`NeverExpire`	Hiermee stelt u in dat het bestand nooit verloopt of wordt de huidige vervaldatum verwijderd. `x-ms-expiry-time` mag niet worden opgegeven.

Aanvraagbody

De hoofdtekst van de aanvraag voor deze aanvraag is leeg.

Voorbeeldaanvraag

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=expiry HTTP/1.1  
  
Request Headers:  
x-ms-version: 2020-02-10  
x-ms-date: Sun, 25 Sep 2020 14:37:35 GMT
x-ms-expiry-option: RelativeTonow
x-ms-expiry-time: 30000  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=

Antwoord

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 200 (OK).

Zie Status- en foutcodes voor meer informatie over statuscodes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook aanvullende standaard-HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Description
`ETag`	Bevat een waarde die de versie van het bestand vertegenwoordigt. De waarde staat tussen aanhalingstekens.
`Last-Modified`	Retourneert de datum en tijd waarop de map voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum/tijdwaarden weergeven in kopteksten voor meer informatie. Elke bewerking die de map of de eigenschappen ervan wijzigt, wordt de laatste wijzigingstijd bijgewerkt. Bewerkingen op bestanden hebben geen invloed op het tijdstip van de laatste wijziging van de map.
`x-ms-request-id`	Identificeert op unieke wijze de aanvraag die is gedaan en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie.
`x-ms-version`	Geeft de Blob Storage-versie aan die is gebruikt om de aanvraag uit te voeren.
`Date`	Een UTC-datum/tijd-waarde die wordt gegenereerd door de service, die de tijd aangeeft waarop het antwoord is geïnitieerd.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Date: Sun, 25 Sep 2011 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Set Blob Expiry bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt het gebruik van Microsoft Entra ID met beheerde identiteiten aan om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie met gedeelde sleutels.

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of beheerde Azure-identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.

Zie Toegang tot blobs autoriseren met Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra gebruiker, groep, beheerde identiteit of service-principal om de Set Blob Expiry bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Set Blob Expiry bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: sas voor gebruikersdelegatie, service-SAS en account-SAS.

Als best practice voor beveiliging raden we u aan Microsoft Entra referenties te gebruiken in plaats van de sleutel van het opslagaccount, die gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u Microsoft Entra referenties om, indien mogelijk, een SAS voor gebruikersdelegatie te maken.

Wanneer gedeelde sleuteltoegang niet is toegestaan voor het opslagaccount, is een service-SAS-token of een ACCOUNT-SAS-token niet toegestaan op een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

SAS voor gebruikersdelegatie

Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Set Blob Expiry bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist als onderdeel van het SAS-token voor gebruikersdelegatie.

Zie een SAS voor gebruikersdelegatie Creatie voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert de toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Voor het aanroepen van de Set Blob Expiry bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist als onderdeel van het service-SAS-token.

Zie een service-SAS Creatie voor meer informatie over de service-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Verloop van blob instellen	Blob (b)	Object (o)	Schrijven (w)

Zie Creatie een account-SAS Creatie voor meer informatie over de account-SAS.

Opmerkingen

De semantiek voor het instellen van een vervaldatum op een blob is als volgt:

Set Expiry kan alleen worden ingesteld op een bestand en niet op een map.
Set Expiry met een expiryTime in het verleden is niet toegestaan.
ExpiryTime kan niet worden opgegeven met een expiryOption waarde van Never.

Notitie

Een verlopen bestand kan niet worden hersteld met behulp van de functie voor voorlopig verwijderen van blobs. Zelfs als u voorlopig verwijderen voor het account hebt ingeschakeld, wordt een verlopen bestand geen voorlopig verwijderde blob wanneer het verloopt. Alleen bestanden die zijn verwijderd, kunnen voorlopig verwijderde bestanden worden.

Billing

Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties hebben bijvoorbeeld een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Set Blob Expiry aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Verloop van blob instellen	Premium blok-blob Standaard v2 voor algemeen gebruik	Andere bewerkingen
Verloop van blob instellen	Standaard v1 voor algemeen gebruik	Schrijfbewerkingen

Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorie.

Delen via