Schemat API i env

Environment variables i .env

Bez tego nie pójdziemy dalej — pora wyjaśnić koncepcję zmiennych środowiskowych. Wiesz zapewne, czym jest typowa zmienna i jak wygląda w różnych językach programowania. Zmienna środowiskowa to również para nazwa–wartość, z tą różnicą, że jest przechowywana przez system operacyjny i udostępniana uruchamianym programom. Dobrym przykładem jest zmienna PATH: dzięki niej programy można uruchamiać bez podawania pełnej ścieżki, ponieważ system przeszukuje katalogi zapisane właśnie w tej zmiennej w poszukiwaniu plików wykonywalnych.

Nam zależy przede wszystkim na dostępie do wartości pewnej zmiennej zwanej kluczem API. Może już wiesz, jaką formę ma klucz API. A dla tych, którzy nie wiedzą: nie jest to typowe hasło w stylu kotek. Na razie wystarczy wiedzieć, że klucz to nic nieznaczący ciąg znaków (z naszego punktu widzenia), który chcemy trzymać poza kodem. Skoro jest to zwykła zmienna, ktoś mógłby zapytać, czemu nie przypisać klucza po prostu bezpośrednio w programie. I niektórzy tak robią. Z punktu widzenia samego programu nie jest to błąd, bo wszystko działa jak należy. Z punktu widzenia innych ludzi też nie najgorzej — udostępniając cały kod, dajemy im dostęp do tego klucza, więc razem z autorem, który puścił swój klucz w świat, mogą wspólnie cieszyć się jego subskrypcją i tokenami. A tak na poważnie: ze względów bezpieczeństwa ważne zmienne, takie jak klucze API czy inne sekrety, warto trzymać poza kodem programu i jedynie wczytywać je w trakcie działania.

Mechanizm ten można porównać do szuflad: nasz program działa w jednej szufladzie, a gdy potrzebuje klucza, sięga do drugiej. Udostępniając program, pokazujemy zawartość tylko tej jednej szuflady, a nie wszystkich. Warto przy tym pamiętać, że samo trzymanie klucza jako zmiennej środowiskowej nie sprawia automatycznie, że jest on w 100% bezpieczny. Nie ma tu żadnej magii z szyfrowaniem — przechowywanie klucza w zmiennej środowiskowej służy przede wszystkim do oddzielenia sekretu od kodu. Dzięki temu eliminujemy główną przyczynę wycieków, jaką jest czynnik ludzki i nieuwaga przy udostępnianiu kodu. Na co dzień pojawiają się nowe przypadki, w których autorzy ujawniają swoje klucze właśnie przez to, że przez nieuwagę wrzucają plik .env do publicznego repozytorium — mimo że plik ten służy do bezpiecznego, oddzielonego od kodu przechowywania zmiennych środowiskowych. Poniżej pokażemy Ci na przykładzie, co to za plik i jak poprawnie przechowywać swój klucz API.

Tworzymy nasz tajny plik o nazwie .env (taka nazwa już się powszechnie utrwaliła i biblioteki również z niej korzystają) i wklejamy nasz tajny klucz w formie nazwa–wartość, jak poniżej:

SECRET="sk-ant-api03-UafsHDFCASFafnonDDasdZ5Er7exvqZw-Zkh-3gAA"

Do kompletu tworzymy plik .gitignore z wpisem:

.env

Celem tego wpisu jest powiedzenie Gitowi, żeby nigdy nie wrzucał naszego .env — a razem z nim kluczy — do repo. To wszystko, jeśli chodzi o bezpieczeństwo klucza (łącznie z uwagą, by nie udostępniać go nikomu). I jak, takie trudne?

Uwaga: Niektóre edytory, IDE oraz Git mogą tworzyć kopie zapasowe lub pliki tymczasowe zawierające tę samą zawartość co .env. Warto również dodać je do .gitignore, aby przez przypadek nie opublikować swoich kluczy.

.env
.env.*
!.env.example

# Visual Studio Code
.vscode/

# Kopie zapasowe i pliki tymczasowe
*.swp
*~
*.orig

Teraz pokażemy, jak ten klucz wczytać i już na nim operować w naszym programie. Funkcja load_dotenv() z biblioteki dotenv automatycznie wczytuje plik .env oraz jego zawartość do zmiennych środowiskowych procesu naszego programu. Następnie za pomocą os.getenv() pobieramy wartość spod wybranej nazwy. Tak jak poniżej wygląda pełny przebieg pracy ze zmiennymi środowiskowymi:

from dotenv import load_dotenv
import os

load_dotenv()

SECRET = os.getenv("SECRET")

print(SECRET)

sk-ant-api03-UafsHDFCASFafnonDDasdZ5Er7exvqZw-Zkh-3gAA

Warto tu zaznaczyć jedną rzecz: load_dotenv() ładuje zmienne wyłącznie do bieżącego procesu, a nie do całego systemu. Oznacza to, że wartości te istnieją tylko tak długo, jak działa nasz program — po jego zakończeniu znikają i nie są widoczne dla innych, niezależnych programów. Różni się to od „prawdziwych” systemowych zmiennych środowiskowych (jak wspomniana wcześniej PATH), które są ustawione na stałe i dziedziczone przez wszystkie nowo uruchamiane procesy. Dzięki temu .env działa lokalnie i nie zaśmiecamy nim systemu, a sekrety żyją tylko na czas działania programu.