Ondertekende tokens en geheime sleutels
Waar een sleutel woont
Je tokens zijn ondertekend, en ze verlopen. Elk ervan hangt af van een sleutel, en tot nu toe wordt die sleutel ter plekke gemaakt door new_key() en weggegooid. Waar komt de sleutel van de server vandaan?
Twee makkelijke antwoorden zijn allebei fout. Als new_key() elke keer draait als de server start, sterft elk token bij elke herstart. Als de sleutel een constante in reading_server.py is, heb je de vaste tokenstrings weer terug, met een langere
De sleutel moet de server van buiten zijn code gegeven worden, door wie de dienst draait. Die persoon is de beheerder (
Wat een programma meekrijgt als het start
Je kent al drie dingen die een programma meekrijgt als het start. Het krijgt zijn main leest met argparse. Het krijgt standaardinvoer om uit te lezen, en standaarduitvoer en standaardfout om naar te schrijven.
Er is een vierde: zijn omgeving (environment). De omgeving is een verzameling benoemde tekstwaarden die het programma als kopie meekrijgt van wat het ook startte. Een van die
READING_KEY=some-text python reading_server.py
Python in Practice noemde de linkerkant van een regel als proof_dir=... een shellvariabele. Zo voor een commando geschreven wordt hij deel van de omgeving van dat ene commando en van niets anders.
In Python komt de omgeving binnen als os.environ, dat zich gedraagt als een get:
De vier regels zijn None, een lege regel, 200, en de melding van de get geeft None terug voor een naam die er niet is, of de standaardwaarde die je meegeeft, hier lege tekst. Rechte haken geven een KeyError. En "20" + "0" is 200, niet 20, omdat elke waarde in een omgeving tekst is. Een getal of een sleutel die zo binnenkomt, moet eerst omgezet worden.
Met environ = {"PORT": "80"}, wat drukt print(environ["PORT"] + "80") af?
environ heeft geen READING_KEY. Wat drukt print(len(environ.get("READING_KEY", ""))) af?
Waar een sleutel niet mag staan
Een sleutel is gelekt zodra hij ergens staat waar meer mensen hem kunnen lezen dan hem zouden mogen hebben. Vier plekken komen steeds weer terug:
In de
. Iedereen die de code kan lezen, heeft de sleutel, en elke oude kopie van de code ook. In een logregel. Een log wordt door meer mensen gelezen, en op meer plekken bewaard, dan een sleutel zou mogen bereiken.
In een bestand dat met het project wordt opgeslagen. Het bestand reist mee waar het project ook heen gaat.
In een foutmelding. Een foutmelding belandt op een scherm of in een log.
Je zult gereedschappen tegenkomen die er helemaal op gericht zijn sleutels van die plekken weg te houden: .env-bestanden die instellingen voor één computer bevatten, .gitignore-regels die zo’n bestand buiten een gedeeld project houden, geheimenopslag, en de geheime instellingen van builddiensten. Deze cursus gebruikt er geen van. Het is genoeg om te weten waar ze voor dienen.
Waar mag een ondertekeningssleutel wonen?
Wat de omgeving wel en niet is
De omgeving houdt de sleutel los van de code. Dezelfde code kan op je computer draaien met een testsleutel en op de echte dienst met de echte, en geen van beide sleutels staat in een bestand van het project.
Het is geen kluis. Andere programma’s die als dezelfde gebruiker draaien, kunnen de omgeving van een programma misschien lezen, afhankelijk van het
Als de sleutel ontbreekt
Er blijft één vraag over voor de volgende les, en die is het waard om nu te beantwoorden. De server start, zoekt zijn sleutel, en vindt niets: de variabele is niet gezet. Denk na over hoe elke mogelijke reactie er van buitenaf uitziet. Een server die draait, ziet er gezond uit voor wie hem startte, welke sleutel hij ook gebruikt.
De server start en vindt geen sleutel. Welk gedrag is het veilige?
In de volgende les leest je server zijn sleutel uit de omgeving, en weigert hij zonder sleutel te starten.