Skrivni API ključ v aplikaciji Expo: kaj zaščititi
Avtor: Mehdi Azizi
Posodobljeno , 7 min
Javni ključ Supabase, strežniška skrivnost, spremenljivke Expo: loči, kaj sme biti v tvoji aplikaciji za iPhone, in preizkusi dostop z dvema računoma.
Okoljska spremenljivka ni nujno skrivnost
V aplikaciji Expo je spremenljivka s predpono EXPO_PUBLIC_ namenjena kodi aplikacije. V njej ne sme biti strežniška skrivnost. Expo pojasnjuje, da so te vrednosti vgrajene v prevedeni JavaScript in jih lahko uporabniki aplikacije preberejo. Če ključ samo premakneš v datoteko .env, ga s tem torej ne zaščitiš. Vir: okoljske spremenljivke Expo.
Preden AI naročiš, naj »priklopi API«, razvrsti, kaj ji daješ: naslov storitve, ključ, ki je namenjen javni rabi, ali ključ, ki dovoljuje privilegirana dejanja. Od te razvrstitve je odvisno, kje mora koda teči.
Spodnja tabela je pripomoček za načrtovanje, ne revizija tvoje aplikacije.
| Element | Kam ga dati | Kaj preveriti |
|---|---|---|
| Javni naslov backenda | Konfiguracija aplikacije | Kaže na pravo okolje. |
| Ključ Supabase publishable ali starejši ključ anon | V aplikacijo, če so dovoljenja pravilno nastavljena | Pravila za podatke dejansko preprečujejo dostop do računa drugega uporabnika. |
| Ključ Supabase secret ali service_role | Samo na strežnik | Ne pojavi se niti v mobilnem bundlu niti v dnevnikih, do katerih ima dostop odjemalec. |
| Skrivni ključ ponudnika AI | Samo na strežnik | Aplikacija kliče tvoj strežnik, ki preveri uporabnika in omejitve, preden pokliče ponudnika. |
Supabase ločuje ključe, namenjene odjemalcem, od skrivnih ključev za zaupanja vredna okolja. Javni ključ identificira projekt, ne nadomesti pa dovoljenj nad podatki. Vir: API ključi Supabase.
Primer: izmišljena aplikacija za bralni dnevnik
Recimo, da imamo aplikacijo, v kateri Lea in Sami beležita svoje knjige in zasebne zapiske. Primer služi pripravi testov, ne opisuje pa rezultatov, dobljenih na kateri od aplikacij Devoria.
Običajen potek je videti v redu: Lea se prijavi in vidi svoje zapiske. A to še ne odgovori na pomembno vprašanje: ali strežnik zavrne Lein zahtevek za Samijev zapisek?
Filter v vmesniku, na primer »prikaži zapiske prijavljenega uporabnika«, izboljša prikaz. Avtorizacija pa mora veljati tudi na strani podatkov. V Supabase pravila Row Level Security omejijo, do katerih vrstic je mogoče dostopati glede na sejo. Supabase priporoča, da jih vklopiš za tabele, ki jih izpostavlja API, in razloži pravilnike za branje in pisanje. Vir: Row Level Security.
V svojem testnem projektu vsak zapisek poveži z lastnikom in posebej določi, kdo ga lahko bere, ustvari, ureja in briše. Preveri tudi datoteke: zaščitena vrstica v bazi ne dokazuje, da je slika zasebna.
Testni postopek z dvema testnima računoma
Pripravi dva računa, ki ju nadzoruješ, v vsakem drugo knjigo in kratek prepoznaven zapisek. Uporabi izmišljene podatke v dovoljenem testnem okolju.
- Preberi svoj zapisek. Račun A najde zapisek A.
- Preberi B-jev zapisek iz računa A. Zahtevek ne razkrije zasebne vsebine.
- Uredi B-jev zapisek iz računa A. Strežnik zavrne, zapisek B ostane nespremenjen.
- Ustvari v imenu B iz računa A. Strežnik zavrne to pripisovanje.
- Beri brez seje. Ne vrne se nobena zasebna vsebina.
- Odpri B-jevo zasebno datoteko iz računa A. Datoteka ni dostopna.
Zabeleži dejanski rezultat, testirano različico in morebitno napako. »Pravila so vklopljena« ni rezultat testa. Kot osnova za hranjenje teh dokazov ti lahko služi testna predloga med viri.
Plačljiv klic naj gre prek tvojega strežnika
Za funkcijo, ki povzame knjigo z AI API-jem, je potek lahko: aplikacija → tvoj strežnik → ponudnik → tvoj strežnik → aplikacija. Skrivni ključ ostane na strežniku. Ta arhitektura sama po sebi ni dovolj: nadzorovati moraš tudi dostop do strežnika.
V izmišljenem primeru mora strežnik med drugim preveriti sejo, preveriti, da knjiga pripada tej osebi, omejiti ponavljajoče se zahtevke in vrniti razumljivo napako, če se ponudnik ne odzove. Odjemalec sam ne odloča, ali ima uporabnik plačljiv dostop.
Pripravi štiri preizkuse: neprijavljen uporabnik, knjiga drugega računa, dosežena omejitev in nedosegljiv ponudnik. Zadnji pokaže, ali aplikacija zapusti stanje nalaganja, ne da bi izgubila vnos.
Kaj lahko naročiš svojemu asistentu za kodo
Tu je navodilo za pregled, ki ga prilagodi svojemu repozitoriju, vanj pa ne lepi skrivnih vrednosti:
Popiši spremenljivke, ki jih uporabljata mobilna koda in strežnik, in prikaži samo njihova imena. Poišči privilegirane klice na strani odjemalca. Za zasebne podatke opiši kontrole branja in pisanja, nato predlagaj testni postopek z dvema testnima računoma. Brez potrditve ne izvajaj nobene rotacije ključev ali sprememb v produkciji.
Odgovor beri skupaj z ustrezno kodo. Asistent lahko opazi nedoslednost, njegov odgovor pa ne nadomesti izvedbe testov. Vodnik ustvari aplikacijo s Claude Code razloži, kako to delo razdeliti.
Preden nadaljuješ z aplikacijo
Preprosto moraš znati razložiti tri stvari: katere vrednosti so javne, katere operacije gredo prek strežnika in kateri testi kažejo, da en račun ne vidi podatkov drugega. Če ti je katera od teh točk nejasna, jo razjasni, preden dodajaš nove funkcije.
Stran ustvari aplikacijo za iPhone ta korak umesti v celoten projekt. Če želiš napredovati po vrsti, ti iOS Kit ponuja pot v štirih korakih in začetno kodo, ki že vključuje račune in AI. Če ne veš več, pri katerem koraku nadaljevati, ti brezplačna diagnostika uredi projekt in ti pošlje moj kontrolni seznam proti zavrnitvam pri Apple.
Pogosta vprašanja
Kam dati skrivni API ključ v aplikaciji Expo?
Na svoj strežnik, nikoli v aplikacijo. Ključ Supabase secret ali service_role in skrivni ključ ponudnika AI morata ostati samo na strežniku. Aplikacija kliče tvoj strežnik, ki preveri uporabnika in omejitve, preden pokliče ponudnika. Preveri, da se noben od teh ključev ne pojavi v mobilnem bundlu ali v dnevnikih, do katerih ima dostop odjemalec.
Ali datoteka .env zaščiti moj API ključ v Expo?
Sama ne. Spremenljivka s predpono EXPO_PUBLIC_ je namenjena kodi aplikacije in v njej ne sme biti strežniška skrivnost. Expo pojasnjuje, da so te vrednosti vgrajene v prevedeni JavaScript in jih lahko uporabniki aplikacije preberejo. Če ključ samo premakneš v datoteko .env, ga s tem torej ne zaščitiš.
Kakšna je razlika med javnim in skrivnim API ključem?
Javni ključ je namenjen temu, da je v aplikaciji: identificira projekt, ne nadomesti pa dovoljenj nad podatki. Skrivni ključ dovoljuje privilegirana dejanja in je rezerviran za zaupanja vredna okolja. Pri Supabase lahko ključ publishable ali starejši ključ anon ostane v aplikaciji, če so dovoljenja pravilno nastavljena. Ključa secret in service_role ostaneta na strežniku.
Kako iz aplikacije Expo poklicati AI API, ne da bi razkril ključ?
Klic naj gre prek tvojega strežnika: aplikacija pokliče strežnik, ta pokliče ponudnika in nato odgovor vrne aplikaciji. Skrivni ključ ostane na strežniku. Strežnik mora tudi preveriti sejo, omejiti ponavljajoče se zahtevke in vrniti razumljivo napako, če se ponudnik ne odzove. Odjemalec sam ne odloča, ali ima uporabnik plačljiv dostop.
Kako preveriti, da vsak uporabnik vidi samo svoje podatke?
Pripravi dva testna računa, ki ju nadzoruješ, in v vsakem prepoznaven zapisek. Iz računa A poskusi brati, urejati in ustvarjati v imenu računa B, nato pa odpreti B-jevo zasebno datoteko. Preizkuse ponovi tudi brez seje: vsak zahtevek mora biti zavrnjen ali ne sme ničesar razkriti. Zabeleži dejanski rezultat, saj »pravila so vklopljena« ni rezultat testa.
Kako naj AI preveri ključe v moji aplikaciji?
Naroči ji, naj popiše spremenljivke mobilne kode in strežnika ter prikaže samo njihova imena, skrivnih vrednosti pa ne lepi vanjo. Naroči ji tudi, naj poišče privilegirane klice na strani odjemalca in predlaga testni postopek z dvema testnima računoma. Prepovej ji vsako rotacijo ključev ali spremembo v produkciji brez potrditve. Njen odgovor ne nadomesti izvedbe testov.