// app.config.js - Exemplu de utilizare corectă vs incorectă
module.exports = ({ config }) => {
return {
...config,
// CORECT: Se folosește la build time pentru Sentry plugin
plugins: [
[
'@sentry/react-native/expo',
{
authToken: process.env.SENTRY_AUTH_TOKEN, // Din EAS Secret
},
],
],
extra: {
// CORECT: Doar chei publice la runtime
apiUrl: process.env.EXPO_PUBLIC_API_URL,
// GREȘIT: Nu expune chei private în extra!
// stripeSecret: process.env.STRIPE_SECRET_KEY,
},
};
};Am văzut săptămâna trecută un junior care a urcat accidental cheia de Stripe în repo-ul public de GitHub pentru că o pusese direct în app.json. Acum doi ani, pe o aplicație cu peste 12k utilizatori activi, era să facem o nefăcută similară cu niște chei de AWS S3. În ecosistemul Expo lucrurile s-au simplificat mult de la EAS încoace, dar încă există confuzie între ce e un secret de build time și ce rămâne expus în client.
Haideți să trecem prin cum le organizez eu pe proiecte ca să nu ai nopți albe.
Fișierele .env locale: rapid, dar înșelător
Pentru dezvoltare locală, e simplu: folosești suportul nativ din Expo SDK 49+. Ai fișiere .env.development, .env.production și .env.local.
Metoda asta funcționează brici pentru URL-uri de API, dar trebuie să înțelegi un lucru esențial: orice variabilă care începe cu EXPO_PUBLIC_ va fi bundled direct în fișierele JavaScript ale aplicației tale. Orice persoană cu un decompiler banal de APK sau un proxy gen Charles poate să îți citească cheia respectivă.
Dacă ai o cheie privată (ex: un secret de Firebase Admin, chei de Stripe Secret API, JWT secret), aceea NU are ce căuta în .env cu prefixul EXPO_PUBLIC.
EAS Secrets: unde se întâmplă magia în cloud
Când dai eas build, aplicația ta nu se mai compilează pe laptopul tău, ci pe mașinile celor de la Expo. Aici intervin EAS Secrets. Le setezi din CLI direct în cloud:
eas secret:create --name SENTRY_AUTH_TOKEN --value 12345...
Aceste variabile sunt injectate doar în mediul de build EAS pe durata compilării.
Când le folosești?
- Când ai chei necesare numai în procesul de build nativ (de exemplu, token-ul de la Sentry ca să urci source map-urile, sau credențiale de NPM privat).
- Când folosești Expo Config Plugins (
app.config.js) care au nevoie de chei pentru a genera cod nativ înainte de compilare.
Marele avantaj? Nu ajung pe GitHub, nu stau pe laptopul tuturor devilor din echipă și le poți schimba din dashboard-ul Expo fără să atingi codul.
Unde greșește lumea: secretul care ajunge în JS
Un trade-off de care mă lovesc frecvent: EAS Secrets sunt disponibile la build time, nu la runtime pentru utilizatorul final, decât dacă le expui tu explicit în app.config.js sub proprietatea extra.
Dacă le pui în extra, ele ajung din nou în JS bundle! EAS Secrets nu înseamnă criptare magică la runtime pe telefon. Dacă aplicația mobilă are nevoie de un secret ca să apeleze un API extern direct, arhitectura e greșită. Soluția corectă e un backend propriu care să facă apelul securizat, iar aplicația mobilă vorbește doar cu backend-ul tău.
Cum le combin eu pe proiecte mari
La un proiect recent am economisit vreo 4 ore de debug pe săptămână configurând mediile așa:
.env.development(commited în git, conține doar endpoint-uri locale/staging și chei publice)..env.local(în.gitignore, pentru suprascrieri locale per developer).- EAS Secrets (setate pe mediile
previewșiproductiondin EAS) pentru Sentry, credențiale de App Store/Google Play și webhook-uri de CI/CD.
Voi ce abordare folosiți când aveți nevoie de chei specifice pe staging vs producție în Expo? Mai folosește cineva react-native-config sau ați trecut toți pe EAS?