Deel 7: Api-eindpunt van de hoofdtoepassing

Vorige deel: Hoofd-app-opstartcode

Het URL-pad van de app /api/v1/getcode voor de API genereert een JSON-antwoord dat een alfanumerieke code en een tijdstempel bevat.

Eerst vertelt de @app.route decorator Flask dat de get_code-functie aanvragen verwerkt voor de /api/v1/getcode URL.

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

Vervolgens roept de app de API van derden aan, waarvan de URL zich in number_urlbevindt, waarbij de toegangssleutel wordt opgegeven die wordt opgehaald uit de sleutelkluis in de header.

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

De voorbeeld-API van derden wordt geïmplementeerd in de serverloze omgeving van Azure Functions. De eigenschap x-functions-key in de header is hoe Azure Functions verwacht dat een toegangssleutel in een koptekst wordt weergegeven. Zie HTTP-trigger van Azure Functions - Autorisatiesleutelsvoor meer informatie. Als het aanroepen van de API om welke reden dan ook mislukt, retourneert de code een foutbericht en de statuscode.

Ervan uitgaande dat de API-aanroep slaagt en een numerieke waarde retourneert, maakt de app vervolgens een complexere code met behulp van dat getal plus enkele willekeurige tekens (met behulp van een eigen random_char functie).

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()) }

De code variabele bevat hier het volledige JSON-antwoord voor de API van de app, die de codewaarde en een tijdstempel bevat. Een voorbeeld van een antwoord is {"code":"ojE-161-pTv","timestamp":"2020-04-15 16:54:48.816549"}.

Voordat het antwoord retourneert, wordt er echter een bericht in de opslagwachtrij geschreven met behulp van de methode send_message van de wachtrijclient:

queue_client.send_message(code)

return jsonify(code)

Wachtrijberichten verwerken

Berichten die zijn opgeslagen in de wachtrij, kunnen worden bekeken en beheerd via Azure Portal, met de Azure CLI-opdracht az storage message get of met Azure Storage Explorer. De voorbeeldopslagplaats bevat een script (test.cmd en test.sh) om een code aan te vragen bij het app-eindpunt en vervolgens de berichtenwachtrij te controleren. Er is ook een script om de wachtrij te wissen met behulp van de opdracht az storage message clear.

Normaal gesproken heeft een app zoals in dit voorbeeld een ander proces waarmee asynchroon berichten uit de wachtrij worden opgehaald voor verdere verwerking. Zoals eerder vermeld, kan het antwoord dat door dit API-eindpunt wordt gegenereerd, elders in de app worden gebruikt met tweeledige gebruikersverificatie. In dat geval moet de app de code na een bepaalde periode ongeldig maken, bijvoorbeeld 10 minuten. Een eenvoudige manier om deze taak uit te voeren, is het onderhouden van een tabel met geldige tweeledige verificatiecodes, die worden gebruikt door de aanmeldingsprocedure van de gebruiker. De app zou vervolgens een eenvoudig wachtrij-controleproces hebben met de volgende logica (in pseudocode):

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)

Deze pseudocode maakt gebruik van de optionele send_message-parameter van de visibility_timeout methode, waarmee het aantal seconden wordt opgegeven voordat het bericht zichtbaar wordt in de wachtrij. Omdat de standaardtime-out nul is, worden berichten die in eerste instantie door het API-eindpunt zijn geschreven, direct zichtbaar voor het wachtrij-controleproces. Als gevolg hiervan worden ze in de geldige codetabel meteen opgeslagen. Het proces zet hetzelfde bericht opnieuw in de wachtrij met de time-out, zodat de code 10 minuten later opnieuw wordt ontvangen, waarna het uit de tabel wordt verwijderd.

Het api-eindpunt voor de belangrijkste app implementeren in Azure Functions

De code die eerder in dit artikel wordt weergegeven, maakt gebruik van het Flask-webframework om het API-eindpunt te maken. Omdat Flask moet worden uitgevoerd met een webserver, moet deze code worden geïmplementeerd in Azure App Service of op een virtuele machine.

Een alternatieve implementatieoptie is de serverloze omgeving van Azure Functions. In dit geval zijn alle opstartcode en de API-eindpuntcode opgenomen in dezelfde functie die is gebonden aan een HTTP-trigger. Net als bij App Service gebruikt u functietoepassingsinstellingen om omgevingsvariabelen voor uw code te maken.

Een deel van de implementatie die eenvoudiger wordt, is het verifiëren met Queue Storage. In plaats van een QueueClient-object te verkrijgen met behulp van de URL van de wachtrij en een referentieobject, maakt u een wachtrijopslagbinding voor de functie. De binding verwerkt alle verificatie achter de schermen. Met een dergelijke binding krijgt uw functie een kant-en-klaar clientobject als parameter. Zie Azure Functions verbinden met Azure Queue Storagevoor meer informatie en voorbeeldcode.

Volgende stappen

In deze zelfstudie hebt u geleerd hoe apps worden geverifieerd met andere Azure-services met behulp van beheerde identiteit en hoe apps Azure Key Vault kunnen gebruiken om andere benodigde geheimen voor API's van derden op te slaan.

Hetzelfde patroon dat hier wordt gedemonstreerd met Azure Key Vault en Azure Storage, is van toepassing op alle andere Azure-services. De cruciale stap is dat u de juiste rol toewijst voor de app op de pagina van die service in Azure Portal of via de Azure CLI. (Zie Hoe Azure-rollen toewijzen). Controleer de servicedocumentatie om te zien of u andere toegangsbeleidsregels moet configureren.

Onthoud altijd dat u dezelfde rollen en toegangsbeleid moet toewijzen aan elke service-principal die u gebruikt voor lokale ontwikkeling.

Kortom, nadat u deze procedure hebt voltooid, kunt u uw kennis toepassen op een willekeurig aantal andere Azure-services en een willekeurig aantal andere externe services.

Eén onderwerp dat niet in deze zelfstudie wordt behandeld, is verificatie van gebruikers. Als u dit gebied voor web-apps wilt verkennen, begint u met het verifiëren en autoriseren van gebruikers end-to-end in Azure App Service.

Zie ook

  • Laatst bijgewerkt om