Lekcja 5 / dostęp do API
Autoryzacja: tokeny, nagłówki i bezpieczne nawyki
W prawdziwym API nie każdy może zobaczyć wszystko. Jeśli request bez tokenu zwraca 401,
to nie musi być błąd endpointu. To może być API mówiące: „najpierw pokaż, kim jesteś”.
Sytuacja z pracy
Tester sprawdza listę zamówień użytkownika. Na frontendzie widzi błąd. W Postmanie odpala request
i dostaje 401 Unauthorized. Zanim zgłosi awarię listy zamówień, musi sprawdzić,
czy request ma poprawny token.
| Status | Najczęstszy sens | Pytanie QA |
|---|---|---|
200 | Dostęp przyznany | Czy dane należą do właściwego użytkownika? |
401 | Brak poprawnego uwierzytelnienia | Czy token istnieje i nie wygasł? |
403 | Użytkownik rozpoznany, ale bez uprawnień | Czy rola użytkownika ma dostęp? |
Token w headerze
Najczęściej token trafia do nagłówka Authorization. Wartość trzymasz w zmiennej,
żeby nie wklejać sekretu w każdym requestcie.
GET {{baseUrl}}/orders
Authorization: Bearer {{accessToken}}
- Pole Auth Type — tu wybierasz sposób uwierzytelnienia.
- Bearer Token — najczęstszy przypadek.
- Wartość podajesz zmienną
{{token}}, nie wklejasz jej na sztywno. - Postman sam dokleja nagłówek
Authorizationdo requestu.
W Postmanie możesz ustawić auth na poziomie kolekcji. Wtedy requesty dziedziczą konfigurację, a Ty nie powtarzasz tego samego headera w dziesięciu miejscach.
Bezpieczny nawyk
Authorization: Bearer {{accessToken}} i token zapisany w środowisku lokalnym.
Token wklejony na stałe do requestu, screena albo opisu zgłoszenia.
W testach API często pracujesz z danymi dostępowymi. Nie chodzi o paranoję, tylko o podstawową higienę: sekret ma być łatwy do podmiany, niewidoczny w przypadkowych miejscach i nie powinien trafić do publicznych materiałów.
Ćwiczenie
Utwórz zmienną accessToken w environment. Ustaw fikcyjną wartość, na przykład
demo-token-123. Dodaj header Authorization z wartością
Bearer {{accessToken}} i sprawdź w Postman Console, jaki request wychodzi.
Mini-zadanie
Usuń zmienną accessToken i sprawdź, jak wygląda request z nierozwiązaną zmienną.
Większa praktyka
Napisz checklistę dla błędu 401: token istnieje, token nie wygasł, wybrane jest dobre środowisko,
użytkownik ma właściwą rolę, request idzie na właściwy baseUrl.
Quiz
Czym różni się 401 od 403?
401 zwykle oznacza problem z uwierzytelnieniem, 403 brak uprawnień mimo rozpoznania użytkownika.
Dlaczego token lepiej trzymać w zmiennej?
Łatwiej go podmienić, ograniczasz powielanie i zmniejszasz ryzyko przypadkowego ujawnienia.
Czy błąd 401 zawsze oznacza zepsute API?
Nie. Najpierw sprawdź token, środowisko i nagłówki.
Co dalej?
Umiesz przygotować request z dostępem. Teraz dodamy testy, które same sprawdzą status, pola JSON i prostą regułę zamiast polegać wyłącznie na patrzeniu w odpowiedź.