Del 7: Api-slutpunkt för huvudprogram

Föregående del: Startkod för huvudappen

Appens URL-sökväg /api/v1/getcode för API:et genererar ett JSON-svar som innehåller en alfanumerisk kod och en tidsstämpel.

Först meddelar @app.route dekoratör Flask att funktionen get_code hanterar begäranden till /api/v1/getcode URL.

@app.route('/api/v1/getcode', methods=['GET'])
def get_code():

Därefter anropar appen API:et från tredje part, vars URL finns i number_url, och tillhandahåller åtkomstnyckeln som den hämtar från nyckelvalvet i headern.

headers = {
    'Content-Type': 'application/json',
    'x-functions-key': access_key
    }

r = requests.get(url = number_url, headers = headers)

if (r.status_code != 200):       
    return "Could not get you a code.", r.status_code

Exempel-API:et från tredje part distribueras till den serverlösa miljön i Azure Functions. Egenskapen x-functions-key i rubriken är hur Azure Functions förväntar sig att en åtkomstnyckel ska visas i ett huvud. Mer information finns i HTTP-utlösare för Azure Functions – auktoriseringsnycklar. Om det inte går att anropa API:et av någon anledning returnerar koden ett felmeddelande och statuskoden.

Förutsatt att API-anropet lyckas och returnerar ett numeriskt värde konstruerar appen sedan en mer komplex kod med det talet plus några slumpmässiga tecken (med hjälp av sin egen random_char funktion).

data = r.json()
chars1 = random_char(3)
chars2 = random_char(3)
code_value = f"{chars1}-{data['value']}-{chars2}"
code = { "code": code_value, "timestamp" : str(datetime.utcnow()) }

Variabeln code här innehåller det fullständiga JSON-svaret för appens API, som innehåller kodvärdet och en tidsstämpel. Ett exempelsvar skulle vara {"code":"ojE-161-pTv","timestamp":"2020-04-15 16:54:48.816549"}.

Innan svaret returneras skriver det dock ett meddelande i lagringskö med hjälp av queue-klientens send_message-metod:

queue_client.send_message(code)

return jsonify(code)

Bearbeta kömeddelanden

Meddelanden som lagras i kön kan visas och hanteras via Azure-portalen, med Azure CLI-kommandot az storage message get eller med Azure Storage Explorer. Exempellagringsplatsen innehåller ett skript (test.cmd och test.sh) för att begära en kod från appslutpunkten och sedan kontrollera meddelandekön. Det finns också ett skript för att rensa kön med hjälp av kommandot az storage message clear.

Vanligtvis skulle en app som den i det här exemplet ha en annan process som asynkront hämtar meddelanden från kön för vidare bearbetning. Som tidigare nämnts kan svaret som genereras av den här API-slutpunkten användas någon annanstans i appen med tvåfaktorsautentisering. I så fall bör appen ogiltigförklara koden efter en viss tidsperiod, till exempel 10 minuter. Ett enkelt sätt att göra den här uppgiften är att underhålla en tabell med giltiga tvåfaktorautentiseringskoder som används av användarens inloggningsprocedur. Appen skulle då ha en enkel köskådningsprocess med följande logik (i pseudokod):

pull a message from the queue and retrieve the code.

if (code is already in the table):
    remove the code from the table, thereby invalidating it
else:
    add the code to the table, making it valid
    call queue_client.send_message(code, visibility_timeout=600)

Den här pseudokoden använder send_message-metodens valfria visibility_timeout parameter, som anger antalet sekunder innan meddelandet visas i kön. Eftersom standardtimeouten är noll blir meddelanden som ursprungligen skrevs av API-slutpunkten omedelbart synliga för kövisningsprocessen. Därför lagrar den processen dem i den giltiga kodtabellen direkt. Processen köar samma meddelande igen med en tidsgräns, så att processen återigen tar emot meddelandet 10 minuter senare, då den tar bort det från tabellen.

Implementera huvudappens API-slutpunkt i Azure Functions

Koden som visas tidigare i den här artikeln använder Flask-webbramverket för att skapa dess API-slutpunkt. Eftersom Flask måste köras med en webbserver måste sådan kod distribueras till Azure App Service eller till en virtuell dator.

Ett alternativt distributionsalternativ är den serverlösa miljön i Azure Functions. I det här fallet skulle all startkod och API-slutpunktskoden finnas i samma funktion som är bunden till en HTTP-utlösare. Precis som med App Service använder du funktionsprograminställningar för att skapa miljövariabler för koden.

En del av implementeringen som blir enklare är att autentisera med Queue Storage. I stället för att hämta ett QueueClient-objekt genom att använda köns-URL och ett autentiseringsobjekt, skapar du en kölagringsbindning för funktionen. Bindningen hanterar all autentisering i bakgrunden. Med en sådan bindning får funktionen ett färdigt klientobjekt som parameter. Mer information och exempelkod finns i Ansluta Azure Functions till Azure Queue Storage.

Nästa steg

I den här självstudien har du lärt dig hur appar autentiserar med andra Azure-tjänster med hjälp av hanterad identitet och hur appar kan använda Azure Key Vault för att lagra andra nödvändiga hemligheter för API:er från tredje part.

Samma mönster som visas här med Azure Key Vault och Azure Storage gäller för alla andra Azure-tjänster. Det avgörande steget är att du tilldelar rätt roll för appen på den tjänstens sida på Azure-portalen eller via Azure CLI. (Se Så här tilldelar du Azure-roller). Kontrollera tjänstdokumentationen för att se om du behöver konfigurera andra åtkomstprinciper.

Kom alltid ihåg att du måste tilldela samma roller och åtkomstprinciper till varje service principal som du använder för lokal utveckling.

När du har slutfört den här genomgången kan du använda dina kunskaper för valfritt antal andra Azure-tjänster och valfritt antal andra externa tjänster.

Ett ämne som inte beskrivs i den här självstudien är autentisering av användare. Om du vill utforska det här området för webbappar börjar du med Autentisera och auktorisera användare från slutpunkt till slutpunkt i Azure App Service.

Se även

  • Last updated on