موبائل ڈویلپمنٹ میں .env فائل: یہ کیا ہے، مقصد اور کام کرنے کا اصول

.env فائل کیا ہے اور اس کی ضرورت کیوں ہے

.env File ایک ترتیبی فائل ہے جو ماحولیاتی متغیرات کو سادہ ٹیکسٹ فارمیٹ KEY=VALUE میں ذخیرہ کرتی ہے۔ ہر لائن میں ایک متغیر ہوتا ہے: کلید کا نام اور اس کی قدر، مساوی نشان سے الگ کیا گیا۔

.env فائلیں جدید ڈویلپمنٹ کے ایک بنیادی مسئلے کو حل کرتی ہیں: مختلف ماحول (مقامی، ٹیسٹ، پروڈکشن) مکمل طور پر مختلف ترتیبات کا تقاضا کرتے ہیں۔ مقامی مشین پر 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 بناتا ہے (مقامی DB راستہ، ڈیبگ API کلیدیں)، جبکہ مشترکہ ترتیبات ریپوزٹری میں .env.example کے طور پر طے کی جاتی ہیں۔ یہ اس صورت حال کو ختم کرتا ہے جہاں git pull کے بعد کسی ڈویلپر کا بلڈ ایک نامعلوم ماحولیاتی متغیر کی کمی کی وجہ سے ٹوٹ جاتا ہے۔ ٹیم کا نیا رکن صرف .env.example کو .env میں کاپی کرتا ہے اور اپنی مقامی قدریں بھرتا ہے۔

.env فائل کا نحو اور ساخت

.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 فائل کا انضمام

.env کو جوڑنے کا طریقہ پلیٹ فارم پر منحصر ہے۔ Android Gradle پلگ ان استعمال کرتا ہے، iOS — xcconfig ترتیبی فائلیں، اور کراس پلیٹ فارم حل جیسے Flutter — مخصوص لائبریریاں۔

Android اور Gradle: BuildConfig سیٹ اپ

Android میں، .env gradle-dotenv پلگ ان کے ذریعے لوڈ کیا جاتا ہے۔ پلگ ان پروجیکٹ کی جڑ سے .env پڑھتا ہے اور BuildConfig میں قدریں شامل کرتا ہے، جس کے بعد وہ Kotlin یا Java کوڈ میں پیدا شدہ فیلڈز کے ذریعے دستیاب ہوتی ہیں۔

// build.gradle.kts (ایپ لیول)
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 فائلوں کے ذریعے ترتیب دیے جاتے ہیں۔ Swift میں .env لوڈ کرنے کے لیے DotEnv لائبریری یا حسب ضرورت کلیدوں کے ساتھ بلٹ ان Info.plist میکانزم استعمال کیا جاتا ہے۔

// Swift پروجیکٹ میں .env لوڈ کرنا
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 پیکیج استعمال ہوتا ہے، جو بلڈ مرحلے پر پروجیکٹ کی جڑ میں موجود ایک .env فائل سے Android کے لیے BuildConfig کلاس اور iOS کے لیے Info.plist میں مستقلات خود بخود پیدا کرتا ہے۔ یہ خاص طور پر ان اسٹارٹ اپس کے لیے آسان ہے جو Expo یا bare workflow استعمال کرتے ہیں: جڑ کی سطح پر ایک ہی .env تمام پلیٹ فارمز کے لیے ترتیبات کو نقل کیے بغیر ایک جیسے ماحولیاتی متغیرات حاصل کرنے کے لیے کافی ہے۔

.env فائل سیکیورٹی اور بہترین طریقہ کار

تمام فوائد کے باوجود، .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 — API کلیدیں اور پاس ورڈ ذخیرہ کرنے کے لیے Google Cloud سروس
• HashiCorp Vault — متحرک راز اور سرور سائیڈ انکرپشن والا آلہ
• Firebase Remote Config — موبائل ایپلیکیشنز کے لیے A/B جانچ کے ساتھ کلاؤڈ ترتیب
• GitLab CI/CD Variables — بلڈ پائپ لائنز کے لیے بلٹ ان راز ذخیرہ

Snyk State of Open Source Security (2024) کے مطابق، ریپوزٹریز کے ذریعے .env فائلوں کا رساو سروے میں شامل کمپنیوں کے درمیان تمام API کلید انکشاف کے واقعات کے 12% سے زیادہ کا سبب تھا۔ ایک مخصوص راز منتظم استعمال کرنے سے یہ خطرہ صفر تک کم ہو جاتا ہے۔

پری کمٹ ہکس کے نفاذ کے ذریعے اضافی تحفظ حاصل کیا جاتا ہے، جس میں husky اور lint-staged جیسے ٹولز استعمال کیے جاتے ہیں، جو چیک کرتے ہیں کہ ڈویلپر نے غلطی سے .env کو کمٹ میں شامل کیا ہے۔ git-secrets (AWS) اور talisman جیسے ٹولز ہر کمٹ کو API کلیدوں، ٹوکنز اور پاس ورڈز کے پیٹرن کے لیے اسکین کرتے ہیں، پائے جانے پر کمٹ کو بلاک کر دیتے ہیں۔ CI پائپ لائنز کے لیے، detect-secrets شامل کرنے کی سفارش کی جاتی ہے — ایک خودکار اسکینر جو ڈویلپر کی غلطی پر بھی .env فائل کو ریپوزٹری میں نہیں جانے دے گا۔