.env File у мобилном развоју: шта је то, намена и принцип рада

Шта је .env File и зашто је потребан

.env File је конфигурациона датотека у којој се чувају променљиве окружења у једноставном текстуалном формату KEY=VALUE. Сваки ред садржи једну променљиву: име кључа и његову вредност раздвојене знаком једнакости.

.env датотеке решавају фундаментални проблем савременог развоја: различита окружења (локално, тестно, продукционо) захтевају потпуно различита подешавања. URL API сервера на локалној машини је http://localhost:8080, на продукционом серверу — https://api.production.com. Ако су ове вредности директно ушивене у код апликације, свако компајлирање за друго окружење захтева измену изворног кода.

Пракса чувања конфигурације ван главног кода апликације стандардизована је у манифесту The Twelve-Factor App (2011), који је истакао променљиве окружења као једини исправан начин конфигурисања апликације. Према анкети JetBrains Developer Ecosystem (2024), више од 67% мобилних програмера користи .env датотеке у својим пројектима.

За мобилни развој .env даје додатну предност: вредности се замењују у фази компајлирања преко Gradle (Android) или xcconfig (iOS), што омогућава креирање одвојених компајлирања за развој, стагинг и продукцију без промене изворног кода.

.env је посебно користан при раду у тиму: сваки програмер креира своју локалну .env датотеку са подешавањима за своје окружење (путања до локалне базе, debug API кључеви), а заједничка подешавања се фиксирају у .env.example у репозиторијуму. Ово елиминише ситуацију када се после git pull програмеру поквари компајлирање због недостатка променљиве окружења за коју није знао. Нови члан тима једноставно копира .env.example у .env и попуњава своје локалне вредности.

Синтакса и структура .env File

Формат .env је максимално једноставан: сваки ред је једна променљива облика KEY=VALUE. Размаци око знака једнакости се обично игноришу, али у већини библиотека се сматрају делом вредности, па их је боље избегавати.

Основна правила писања

Коментари почињу симболом # — цео ред после њега се игнорише. Празни редови се такође прескачу. Ако вредност садржи размаке, ставља се у двоструке или појединачне наводнике.

# Основна подешавања окружења
APP_NAME=MyMobileApp
APP_ENV=development

# API конфигурација
API_BASE_URL=http://localhost:3000/api
API_TIMEOUT=30000

# Осетљиви подаци
DB_PASSWORD=secret_password_123
JWT_SECRET=your_jwt_secret_key

Типови вредности и екранизација

Све променљиве у .env су стрингови, али библиотеке за учитавање могу да их конвертују у потребан тип. За екранизацију специјалних знакова користе се обрнуте косе црте и наводници. Ако вредност садржи знак # као део текста, потребно га је екранизовати као \#.

• Стрингови — без наводника или у наводницима: KEY=value или KEY="value with spaces"
• Бројеви — пишу се без наводника: PORT=8080
• Булове вредности — стрингови true/false: DEBUG=true
• Вишередни — обрнута коса црта на крају реда: KEY=line1\
line2
• Замена — у неким рашчлањивачима: DB_URL=${DB_HOST}:${DB_PORT}

Приликом учитавања .env, библиотеке могу да врше интерполацију променљивих — замењују вредности једних кључева унутар других. На пример, променљива DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@localhost/db ће отворити DB_USER и DB_PASS из исте датотеке.

Интеграција .env File у мобилне пројекте

Начин повезивања .env зависи од платформе. Android користи Gradle додатке, iOS — конфигурационе датотеке xcconfig, а вишеплатформска решења попут Flutter-а — специјализоване библиотеке.

Android и Gradle: подешавање BuildConfig

У Android-у се .env учитава преко додатка gradle-dotenv. Додатак чита .env из корена пројекта и додаје вредности у BuildConfig, након чега су доступне у Kotlin или Java коду преко генерисаних поља.

// build.gradle.kts (app level)
plugins {
    id("co.uzzu.dotenv") version "4.0.0"
}

android {
    buildFeatures {
        buildConfig = true
    }
}

kotlin {
    // Приступ у коду: BuildConfig.API_BASE_URL
    buildConfigField("String", "API_BASE_URL",
        "\"" + dotenv.get("API_BASE_URL") + "\"")
}

iOS и Xcode: повезивање Config

У iOS-у се променљиве окружења обично подешавају преко xcconfig датотека. За учитавање .env у Swift-у користи се библиотека DotEnv или уграђени механизам Info.plist са прилагођеним кључевима.

// Учитавање .env у Swift пројекту
import DotEnv

struct AppConfig {
    static func load() {
        let env = DotEnv(Bundle.main)
        env.load()

        let apiURL = ProcessInfo.processInfo
            .environment["API_BASE_URL"] ??
            "https://default.api.com"
    }
}

Flutter и Dart: библиотека flutter_dotenv

За Flutter постоји пакет flutter_dotenv који учитава променљиве из .env током иницијализације апликације. .env датотека се поставља у корен пројекта, а променљиве постају доступне преко класе dotenv.

// pubspec.yaml
dependencies:
  flutter_dotenv: ^5.1

// main.dart — учитавање при покретању
import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: '.env');
  var apiUrl = dotenv.get('API_BASE_URL');
  runApp(MyApp(baseUrl: apiUrl));
}

Сва три приступа обједињује заједнички принцип: .env се учитава у фази компајлирања или при покретању апликације, вредности се кеширају и користе у коду преко генерисаних константи. Ово спречава доспевање осетљивих података у репозиторијум.

За React Native се користи пакет react-native-config који у фази компајлирања аутоматски генерише класу BuildConfig за Android и константе у Info.plist за iOS из једне .env датотеке у корену пројекта. Ово је посебно згодно за стартапове који користе Expo или bare workflow: довољна је једна .env датотека на кореном нивоу, и све платформе добијају исте променљиве окружења без дуплирања конфигурација.

Безбедност и најбоље праксе .env File

Упркос свим предностима, .env није потпуно решење за чување тајни у продукционом окружењу. Пружа основни ниво заштите, али при неправилној употреби може довести до цурења поверљивих података.

Заштита преко .gitignore

Најважније правило — .env никада не сме да доспе у систем за контролу верзија. Датотека се додаје у .gitignore одмах након креирања, а у репозиторијум се комитује само датотека-узорак .env.example са празним или фиктивним вредностима.

# .env.example — комитује се у репозиторијум
APP_NAME=
APP_ENV=development
API_BASE_URL=http://localhost:3000
API_TIMEOUT=30000
# DB_PASSWORD — не наводити чак ни у примеру!
# JWT_SECRET — не наводити чак ни у примеру!

# .gitignore
# Dotenv датотеке
.env
.env*.local

Алтернативе за продукционо окружење

За продукционе пројекте препоручује се коришћење професионалних решења за управљање тајнама. .env у продукцији је дозвољен само ако се датотека налази ван document-root-а сервера и има строга права приступа.

• AWS Secrets Manager — облачно складиште тајни са ротацијом кључева и аудитом приступа
• Google Secret Manager — Google Cloud услуга за чување API кључева и лозинки
• HashiCorp Vault — алат са динамичким тајнама и шифровањем на страни сервера
• Firebase Remote Config — облачна конфигурација са A/B тестирањем за мобилне апликације
• GitLab CI/CD Variables — уграђено складиште тајни за компајлирање цевовода

Према Snyk State of Open Source Security (2024), цурење .env датотека преко репозиторијума било је узрок више од 12% свих инцидената са откривањем API кључева међу анкетираним компанијама. Коришћење засебног менаџера тајни омогућава смањење овог ризика на нулу.

Додатна заштита се постиже увођењем pre-commit хукova коришћењем алата попут husky и lint-staged, који проверавају да ли је програмер случајно додао .env у комит. Алати попут git-secrets (AWS) и talisman скенирају сваки комит у потрази за обрасцима API кључева, токена и лозинки, блокирајући комит при откривању. За CI цевоводе препоручује се додавање провере detect-secrets — аутоматског скенера који неће пропустити .env датотеку у репозиторијум чак ни при грешци програмера.