Uwierzytelnianie graczy

Konta graczy w Twojej grze: gość, e-mail i hasło, weryfikacja adresu, reset hasła i weryfikacja dwuetapowa SMS. Konfigurujesz je w panelu Nunox, a gra korzysta z API.

Jak to działa#

Konfiguracja w panelu Nunox. W projekcie, osobno dla każdego środowiska (np. Development i Production), włączasz metody logowania, ustawiasz szablony wiadomości, politykę haseł i zabezpieczenia: Gracze → Uwierzytelnianie.
Gra woła API logowania. Każde żądanie wskazuje projekt i środowisko nagłówkami. W odpowiedzi gra dostaje idToken i sessionToken.
Gra trzyma sesję. idToken jest ważny godzinę. Przed jego wygaśnięciem gra odnawia go za pomocą sessionToken.
Serwer gry sprawdza tokeny. Twój serwer (albo inne usługi Nunox) weryfikuje podpis idToken kluczem publicznym, bez pytania usługi logowania przy każdym żądaniu.

Metody logowania#

Metoda	Do czego	Stan
Gość (anonimowe)	Gracz gra od razu, bez formularza. Konto można później zamienić na e-mail i hasło bez utraty postępu.	Dostępne
E-mail i hasło	Rejestracja i logowanie, weryfikacja adresu, reset hasła.	Dostępne
Weryfikacja dwuetapowa SMS	Drugi krok logowania z kodem SMS (opłacany z Nunox Credits).	Dostępne
Google, Apple, Discord, Steam, konsole	Logowanie kontem zewnętrznym.	Wkrótce

Adres usługi#

https://player-auth.services.api.sandbox.gamevious.com/v1/authentication

Adres tymczasowy. Docelowo usługa będzie dostępna pod https://player-auth.services.api.gamevious.com - bez „sandbox”. Środowisko gry i tak wybiera nagłówek X-Environment, więc po zmianie wystarczy podmienić adres w jednym miejscu.

Nagłówki każdego żądania#

Nagłówek	Wartość
`X-Project-Id`	Identyfikator projektu, np. `prj_gv_791c…`. Jest publiczny - można go wbudować w grę.
`X-Environment`	Identyfikator środowiska, np. `env_gv_e106…`. Zalecany zamiast nazwy - nazwy środowisk można zmieniać.
`Content-Type`	`application/json` przy żądaniach z treścią.
`Authorization`	`Bearer <idToken>` - tylko przy operacjach zalogowanego gracza (np. dodanie numeru telefonu).

Nie umieszczaj w grze kluczy API. Logowanie graczy nie wymaga klucza API ani sekretu - każdy może je wyciągnąć z pliku gry. Usługa chroni się sama: przyjmuje tylko metody włączone w panelu, ma limity na adres IP i na konto, a zapytania z przeglądarki przyjmuje wyłącznie z autoryzowanych domen z Ustawień.

Odpowiedź z tokenami#

Logowanie, rejestracja, gość i odnowienie sesji zwracają:

{
  "player": {
    "id": "ply_gv_957db5a7adeb41e58c1826e330",
    "displayName": "Gracz",
    "email": "gracz@example.com",
    "emailVerified": false,
    "accountState": "registered",
    "createdAt": "2026-10-18T17:10:25.807Z"
  },
  "idToken": "eyJhbGciOiJFZERTQSIs…",
  "expiresIn": 3600,
  "sessionToken": "AsfxWCI5g_ZIMjXOnepKIJ4Z…",
  "sessionExpiresAt": "2026-11-17T13:50:51.339Z"
}

Pole	Znaczenie
`player.id`	Stały identyfikator gracza w środowisku. Używaj go jako klucza w swoich danych - nie zmienia się po zamianie gościa na konto.
`idToken`	Token JWT (EdDSA) na godzinę. Wysyłasz go do swojego serwera i usług Nunox.
`sessionToken`	Token do odnawiania sesji. Przechowuj go bezpiecznie na urządzeniu. Każde odnowienie zwraca nowy - poprzedni przestaje działać.
`sessionExpiresAt`	Kiedy sesja wygaśnie bez aktywności (ustawienie „Długość sesji” w panelu).

Format błędów#

Każdy błąd ma kod HTTP i treść w tym samym formacie. Gra powinna reagować na error.code, a nie na treść komunikatu - komunikaty mogą się zmieniać.

{
  "error": {
    "code": "weak_password",
    "message": "The password does not meet the project's password policy.",
    "details": { "requirements": ["min_length", "numeric"] }
  }
}

Środowiska#

Gracze, konfiguracja i szablony są osobne dla każdego środowiska projektu. Gracz zarejestrowany w Development nie istnieje w Production. Przy testach zwracaj uwagę na przełącznik środowiska w nagłówku panelu - zmiany zapisują się w środowisku, które jest wybrane.