Przejdź do treści
Wróć do kursuAPI i QA / Lekcja 5 z 8

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.

StatusNajczęstszy sensPytanie QA
200Dostęp przyznanyCzy dane należą do właściwego użytkownika?
401Brak poprawnego uwierzytelnieniaCzy token istnieje i nie wygasł?
403Uż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}}
Postman: menu Auth Type z opcją Bearer Token
Token ustawiaj w Authorization. Dla najczęstszego przypadku wybierasz Bearer Token i podajesz wartość przez zmienną.

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

Dobrze
Authorization: Bearer {{accessToken}} i token zapisany w środowisku lokalnym.
Źle
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ź.

Lekcja 5: Autoryzacja: tokeny, nagłówki i bezpieczne nawyki | Postman od podstaw dla QA | Mikołaj Mikołajczak