Python’da .env ile API Anahtarını Koddan Ayrı Saklama

Python .env kullanımı, API anahtarlarını, parolaları ve bağlantı dizelerini Python kaynak kodundan ayrı tutmak için kullanılan pratik bir yöntemdir. Bu bilgileri doğrudan .py dosyasına yazmak yerine ortam değişkenlerinden okumak ve yerel projede kullanılan, GitHub deposuna dahil edilmeyen bir .env dosyası oluşturmak daha güvenli bir çalışma alışkanlığıdır.

Bu yaklaşım, anahtarı otomatik olarak her türlü saldırıya karşı korumaz; ancak hassas bilgileri kod, yapılandırma ve sürüm kontrolü arasında ayırır. Özellikle ilk projesini GitHub’a gönderen Python geliştiricileri için bu ayrım, yanlışlıkla API anahtarı paylaşma riskini azaltan temel adımlardan biridir.

API Anahtarını Python Koduna Yazmak Neden Risklidir?

API anahtarı, parola ve veritabanı bağlantı dizesi gibi bilgiler kaynak kodunun bir parçası olmamalıdır. Çünkü bu bilgiler uygulamanın hangi hizmete, hangi hesapla veya hangi yetki düzeyiyle erişebileceğini belirleyebilir. Kod çalışırken anahtara ihtiyaç duyulabilir; fakat bu, anahtarın dosyanın içine açık metin olarak yazılması gerektiği anlamına gelmez.

Python temellerini ve kod içinde yapılandırma kullanımını daha sağlam öğrenmek isteyenler, birebir Python eğitimi kapsamında değişkenler, dosya yapısı ve proje çalışma alışkanlıklarını uygulamalı olarak pekiştirebilir.

Yeni başlayanların yaptığı yaygın hata

Aşağıdaki örnekte API anahtarı doğrudan Python dosyasına yazılmıştır:

import requests

API_KEY = "gercek-api-anahtariniz-buraya"
url = "https://api.example.com/data"

response = requests.get(
    url,
    headers={"Authorization": f"Bearer {API_KEY}"}
)

print(response.status_code)

Bu kod teknik olarak çalışabilir; ancak güvenli bir proje yapısı oluşturmaz. Dosyayı GitHub’a gönderdiğinizde anahtar da aynı commit’in içinde gönderilebilir. Depo herkese açık olarak oluşturulmuşsa, depoya erişebilen kişiler dosyanın o anki içeriğini görebilir. Depo özel olsa bile, ekip üyeleri, yanlış yetkilendirmeler, ekran görüntüleri veya daha sonra yapılan bir görünürlük değişikliği gibi durumlar hassas bilginin beklenenden fazla kişiye ulaşmasına yol açabilir.

Commit geçmişi neden önemlidir?

Bir anahtarı sonradan dosyadan silmek, anahtarın daha önceki commit’lerde bulunmadığı anlamına gelmez. Örneğin önce anahtarı ekleyip GitHub’a gönderir, ardından dosyayı düzenleyip anahtarı kaldırırsanız son dosya temiz görünebilir. Fakat önceki commit’lerdeki değişiklikler hâlâ sürüm geçmişinin bir parçası olabilir.

Bu nedenle güvenlik açısından önemli olan yalnızca mevcut dosyayı kontrol etmek değildir. GitHub’a gönderilmeden önce dosyanın geçmişteki değişiklikleri de dikkate alınmalıdır. Bir bilgi daha önce uzak depoya gönderildiyse, yalnızca dosyadan silmek yerine ilgili hizmetin yönetim panelinden anahtarı geçersiz kılmak veya yenilemek gerekir.

Anahtar görünür hâle gelirse ne olabilir?

Sonuçlar kullanılan hizmete ve anahtarın yetkilerine göre değişir; bu nedenle her servis için aynı senaryo geçerli değildir. Bununla birlikte görünür hâle gelen bir API anahtarı şu riskleri doğurabilir:

• Yetkisiz bir kişi sizin hesabınız üzerinden API isteği gönderebilir.
• Hesabınıza tanımlı kullanım kotası veya istek hakkı beklenmedik biçimde tüketilebilir.
• Ücretlendirme, kullanım takibi veya proje kaynakları açısından sorun oluşabilir.
• Anahtar daha geniş yetkilere sahipse, hizmetteki başka kaynaklara erişim riski artabilir.
• Bir bağlantı dizesi sızarsa, bağlantı dizesinde tanımlanan sisteme yetkisiz erişim denenebilir.

Buradaki temel fikir, anahtarın mutlaka kötüye kullanılacağı değildir. Sorun, anahtarın kontrolünüz dışındaki kişiler tarafından kullanılabilme ihtimalidir. Bir anahtarın koda yazılması, onu kullanan kişinin niyetinden bağımsız olarak paylaşılabilir bir metne dönüştürür.

Güvenli yaklaşımın temel mantığı

Daha güvenli yerel geliştirme akışında Python kodu anahtarın kendisini değil, anahtarın adını bilir. Örneğin uygulama, API_KEY adlı ortam değişkenini okumaya çalışır. Gerçek değer ise projenin dışında tutulan bir .env dosyasında bulunur. Bu dosya daha sonra .gitignore ile Git tarafından izlenmeyecek şekilde yapılandırılır.

Bu ayrımın avantajı, kodun paylaşılabilir kalmasıdır. Başka bir geliştirici projeyi indirdiğinde Python dosyasını görebilir; ancak yerel ortamınıza ait gerçek anahtar otomatik olarak kodla birlikte paylaşılmaz. Yine de bu korumanın çalışması için .env dosyasının gerçekten GitHub’a gönderilmediğini kontrol etmek gerekir.

.env Dosyası Nedir ve Python Projesine Nasıl Eklenir?

.env dosyası, bir uygulamanın ihtiyaç duyduğu yapılandırma değerlerini anahtar-değer biçiminde saklayan düz metin dosyasıdır. Örneğin API anahtarı, uygulama modu veya bağlantı bilgisi gibi değerler bu dosyada tutulabilir. Dosyanın amacı karmaşık bir şifreleme yapmak değil, hassas bilgileri Python kodundan ayırmaktır.

Python pratiğini kendi hızında ilerletmek ve dosya yapısı, değişkenler ile proje düzenini tekrar ederek öğrenmek isteyenler Python video eğitimleri üzerinden asenkron çalışma düzeni oluşturabilir.

Ortam değişkeni, işletim sistemi veya çalıştırma ortamı tarafından uygulamaya sunulan isimlendirilmiş bir değerdir. Python kodu bu değeri os.getenv() veya os.environ üzerinden okuyabilir. Yerel geliştirmede python-dotenv paketi, proje klasöründeki .env dosyasındaki anahtar-değer çiftlerini okuyarak bunları Python’un ortam değişkenleri üzerinden kullanılabilir hâle getirebilir. Paketin resmî belgelerinde kurulum için pip install python-dotenv, temel kullanım için ise from dotenv import load_dotenv ve load_dotenv() yaklaşımı gösterilir. ([pypi.org](https://pypi.org/project/python-dotenv/?utm_source=openai))

Yerel Python projesine .env ekleme adımları

1. Proje klasörü oluşturun. Örneğin bilgisayarınızda api-projesi adında yeni bir klasör açın ve terminali bu klasörde çalıştırın.

2. Sanal ortam kullanmayı değerlendirin. Sanal ortam, bu projeye ait Python paketlerini diğer projelerden ayırır. Kullanmak zorunlu değildir; ancak başlangıçtan itibaren düzenli bir proje alışkanlığı sağlar.

   python -m venv .venv

   Windows’ta etkinleştirme için:

   .venvScriptsactivate

   macOS veya Linux’ta etkinleştirme için:

   source .venv/bin/activate

3. python-dotenv paketini kurun. Etkin sanal ortamınız varsa paket bu proje ortamına kurulur:

   python -m pip install python-dotenv

   Resmî PyPI dokümantasyonunda eşdeğer kurulum komutu pip install python-dotenv olarak verilir. python -m pip biçimi ise komutun seçtiğiniz Python yorumlayıcısının pip aracını kullanmasını açıkça belirtir. ([pypi.org](https://pypi.org/project/python-dotenv/?utm_source=openai))

4. Proje klasörünün kökünde .env dosyası oluşturun. Dosya adının başında nokta bulunur ve dosya uzantısı eklenmez. Dosya yapısı başlangıçta şu şekilde olabilir:

   api-projesi/
   ├── .env
   ├── app.py
   └── .venv/

5. Anahtar-değer biçimini kullanın. Her satıra bir değişken adı ve değer yazılır. Gerçek API anahtarınızı bu örneğe koymayın:

   API_KEY=ornek_anahtar_degeri
   API_BASE_URL=https://api.example.com
   APP_MODE=development

   Değişken adlarında boşluk kullanmamak ve adları tutarlı seçmek okunabilirliği artırır. Değer içinde boşluk veya özel karakter bulunduğunda tırnak kullanımı gerekebilir; başlangıç seviyesinde en güvenli yaklaşım, değerleri gereksiz biçimde karmaşıklaştırmadan yazmaktır.

6. Python dosyasından .env değerlerini okumaya hazırlanın. Önce load_dotenv() çağrılır, ardından değer os.getenv() ile okunur:

   import os
   from dotenv import load_dotenv
   
   load_dotenv()
   
   api_key = os.getenv("API_KEY")
   
   if not api_key:
       raise RuntimeError("API_KEY bulunamadı")
   
   print("API anahtarı yüklendi.")

   Bu örnekte gerçek anahtar ekrana yazdırılmaz. Kod yalnızca değişkenin bulunup bulunmadığını kontrol eder. Bir API isteği yapılacaksa api_key değeri ilgili istemciye veya istek başlıklarına aktarılabilir; ancak anahtarın kendisini hata mesajlarına, log dosyalarına veya ekran çıktısına yazdırmaktan kaçınmak gerekir.

.env dosyası çalışma sırasında nasıl kullanılır?

load_dotenv(), .env dosyasındaki değerleri okuyup Python sürecinin ortamında kullanılabilir hâle getirir. Böylece uygulama kodu, değerin nerede saklandığını bilmeden os.getenv("API_KEY") ile anahtarı alabilir. Resmî açıklamaya göre çağrı, açıkça farklı bir dosya yolu verilmediğinde uygun bir .env dosyasını bulmaya çalışır; ayrıca mevcut ortam değişkenlerini varsayılan davranışta otomatik olarak ezmez. ([pypi.org](https://pypi.org/project/python-dotenv/?utm_source=openai))

Ancak .env dosyasını oluşturmak tek başına yeterli değildir. Dosya hâlâ proje klasörünün içinde bulunduğu için Git tarafından izlenebilir. Bu yüzden bir sonraki güvenlik adımı, dosyanın GitHub’a gönderilmesini önlemek üzere .gitignore içine eklenmesidir.

Yanlış ve Doğru Python Kodunu Karşılaştırın

API anahtarını Python dosyasına doğrudan yazmak, programın çalışmasını kolaylaştırıyor gibi görünse de anahtarı kaynak kodun bir parçası hâline getirir. Bu dosya Git ile izleniyor veya GitHub’a gönderiliyorsa anahtar da aynı commit’in içinde yer alabilir.

Öncesi: API anahtarını doğrudan koda gömmek

Aşağıdaki örnekte API_KEY değişkeni gerçek bir anahtar yerine yalnızca örnek bir yer tutucu içeriyor. Gerçek kullanımda benzer bir değer yazıldığında sorun başlar:

import requests

API_KEY = "ornek-api-anahtari-123456"

response = requests.get(
    "https://api.example.com/data",
    headers={"Authorization": f"Bearer {API_KEY}"}
)

print(response.status_code)

Bu kod teknik olarak çalışabilir; ancak anahtar, dosyayı açan herkes tarafından görülebilir. Ayrıca dosya bir Git deposuna eklendiğinde anahtar commit içeriğine dâhil olabilir. Dosyayı daha sonra silmek, önceki commit’lerde bulunan değeri kendiliğinden ortadan kaldırmaz.

• API anahtarı kaynak kodda açıkça görünür.
• Dosyayı paylaşmak, anahtarı da paylaşmak anlamına gelebilir.
• Git geçmişine giren değer, yalnızca mevcut dosya silinerek tamamen ortadan kalkmayabilir.
• Aynı anahtar farklı bir dosyaya veya örnek kod parçasına kopyalanırsa takip etmek zorlaşır.

Sonrası: Anahtarı .env dosyasından okumak

Yerel Python projelerinde yaygın yaklaşım, anahtarı proje klasöründeki .env dosyasına yazmak ve Python kodunda bu değeri ortam değişkeni olarak okumaktır. python-dotenv, .env içindeki anahtar-değer çiftlerini okuyup Python ortam değişkenlerine yüklemek için kullanılabilir. Resmî kullanım örneklerinde load_dotenv() sonrasında değerlerin os.environ veya os.getenv() ile okunması gösterilir: python-dotenv PyPI.

Önce proje klasöründe, Python dosyanızla aynı çalışma alanında bulunan .env dosyasına örnek bir değer ekleyin:

API_KEY=ornek-api-anahtari-123456

Ardından Python dosyanızda bu değeri yükleyip okuyun:

import os
from dotenv import load_dotenv

load_dotenv()

api_key = os.getenv("API_KEY")

if not api_key:
    raise RuntimeError("API_KEY bulunamadı.")

print("API anahtarı yüklendi:", bool(api_key))

Beklenen çıktı şöyledir:

API anahtarı yüklendi: True

Bu örnekte API anahtarı Python kaynak kodunda bulunmaz. Python, çalışma sırasında .env dosyasındaki değeri api_key değişkenine alır. print(api_key) yerine yalnızca bool(api_key) yazdırılması da anahtarın terminal ekranında yanlışlıkla görünmesini önleyen basit bir alışkanlıktır.

os.environ ile de aynı değere ulaşabilirsiniz:

import os
from dotenv import load_dotenv

load_dotenv()

api_key = os.environ["API_KEY"]
print("Anahtar uzunluğu:", len(api_key))

Burada os.environ["API_KEY"] kullanıldığında değişken bulunamazsa Python hata verir. os.getenv("API_KEY") ise değer bulunamadığında None döndürür. Başlangıç seviyesinde hangi yöntemi seçerseniz seçin, eksik anahtar durumunu kontrol etmek önemlidir. Programın API isteği gönderilirken belirsiz bir hata vermesi yerine, sorunun yapılandırma değerinin eksik olduğunu açıkça bildirmesi daha anlaşılırdır.

.env dosyası tek başına güvenlik sağlamaz

.env kullanmak, anahtarı Python kodundan ayırır; fakat dosyanın kendisini şifrelemez. Dosyayı açabilen kişi içeriği okuyabilir. Bu nedenle asıl güvenlik, .env dosyasının Git tarafından izlenmesini ve commit edilmesini engellemekle birlikte oluşur.

Başka bir ifadeyle şu iki adım birlikte düşünülmelidir:

1. API anahtarını Python dosyasına yazmamak ve .env gibi yerel yapılandırma dosyasından okumak.
2. .env dosyasını .gitignore içine ekleyerek GitHub’a gönderilecek dosyaların dışında tutmak.

İlk adımı uygulayıp ikinci adımı atlarsanız risk devam eder. .env dosyası koddan ayrı olsa bile Git deposuna eklenebilir. Bu yüzden doğru yaklaşım, kod ile yerel yapılandırmayı ayırmak ve dosya takibini kontrol etmektir.

.gitignore İçine .env Eklemek Neden Zorunludur?

.gitignore, Git’e hangi dosya ve klasörlerin commit sırasında izlenmemesi gerektiğini bildiren proje dosyasıdır. GitHub’ın dokümantasyonunda da bir deponun kök dizinindeki .gitignore dosyasının takip edilmemesi gereken dosyaları belirtmek için kullanılabileceği açıklanır: GitHub Docs: Ignoring files.

Yerel Python projenizin kök klasöründeki .gitignore dosyasına yalnızca şu satırı ekleyin:

.env

Bu satır, adı tam olarak .env olan dosyanın Git tarafından yeni dosya olarak izlenmesini önler. Uygulamanız çalışırken Python yine kendi bilgisayarınızdaki .env dosyasını okuyabilir; dosyanın GitHub’a gönderilecek commit’lere dâhil edilmemesi amaçlanır.

.env dosyasının daha önce izlenip izlenmediğini kontrol edin

Önemli ayrım şudur: .gitignore çoğunlukla henüz Git tarafından izlenmeyen dosyalar için koruma sağlar. .env dosyasını daha önce git add veya commit işlemiyle izlemeye aldıysanız, sonradan .gitignore içine eklemek dosyayı geçmişten otomatik olarak çıkarmaz.

Dosyanın Git tarafından izlenip izlenmediğini kontrol etmek için proje klasöründe şu komutu çalıştırabilirsiniz:

git status
git ls-files .env

git ls-files .env komutu dosya adını döndürüyorsa .env hâlâ Git’in izlediği dosyalar arasındadır. Bu durumda dosyayı bilgisayarınızdan silmeden Git takibinden çıkarmak için şu komut kullanılabilir:

git rm --cached .env
git add .gitignore
git commit -m "Ortam dosyasını Git takibinden çıkar"
git push

git rm --cached .env komutu, dosyanın yerel kopyasını silmeden Git’in izleme listesinden çıkarmayı amaçlar. Böylece Python projeniz yerel .env dosyasını kullanmaya devam edebilir; ancak dosya sonraki commit’lerde izlenen bir dosya olarak görünmez.

Dosyayı silmek neden her zaman yeterli değildir?

Bir dosyayı çalışma klasöründen silmek ile Git geçmişinden kaldırmak aynı işlem değildir. .env dosyası önceki bir commit içinde yer aldıysa, dosyanın güncel sürümünü silmeniz yalnızca sonraki çalışma durumunu değiştirir. Eski commit’lerde dosyanın içeriği bulunmaya devam edebilir.

Bu nedenle iki farklı durum arasında ayrım yapın:

• Dosya hiç commit edilmediyse: .gitignore içine .env eklemek ve dosyanın izlenmediğini kontrol etmek genellikle doğru başlangıçtır.
• Dosya commit edildiyse: Dosyayı silmek veya .gitignore içine eklemek, eski commit’lerdeki içeriği tek başına temizlemez.
• Gerçek bir anahtar paylaşılmışsa: Anahtarın artık gizli kabul edilmemesi ve ilgili hizmetin yönetim panelinden yenilenmesi gerekir.

Özellikle GitHub’a push etmeden önce git status çıktısını ve commit’e girecek dosyaları inceleyin. Sadece dosya adının mevcut klasörde görünmemesine güvenmeyin; Git’in dosyayı hâlâ izleyip izlemediğini de kontrol edin.

İlk GitHub projenizi hazırlarken amaç yalnızca kodu çalıştırmak değil, hangi dosyanın paylaşılabilir olduğunu da ayırt etmektir. Kaynak kodu, requirements.txt gibi proje dosyaları ve açıklama belgeleri genellikle paylaşılabilirken, yerel ayarları ve hassas değerleri içeren .env dosyası proje dışında tutulmalıdır.

Anahtarı Yanlışlıkla GitHub’a Gönderdiyseniz Ne Yapmalısınız?

Bir API anahtarını GitHub’a gönderdiğinizi fark ettiğinizde yalnızca dosyadan anahtarı silmek yeterli değildir. Öncelik, anahtarın kullanılabilirliğini sağlayıcının kendi yönetim ekranından iptal etmek veya yenilemektir. Ardından yeni anahtarı yerel projenizde güvenli biçimde tanımlamalı ve eski değerin Git geçmişindeki kopyalarını kontrol etmelisiniz.

GitHub’ın hassas verileri repository geçmişinden kaldırma rehberi, kimlik bilgisi niteliğindeki veriler için önce ilgili sırrın iptal edilmesini veya yenilenmesini, geçmiş temizleme işlemlerinin ise dikkatli planlanmasını önerir. Aşağıdaki kontrol listesi, kişisel bir Python projesinde ilk müdahaleyi düzenlemenize yardımcı olur.

Sızıntı sonrası uygulanabilir kontrol listesi

1. Sızıntıyı doğrulayın ve kapsamını belirleyin.

   Önce hangi dosyada ve hangi commit içinde API anahtarının göründüğünü tespit edin. GitHub’daki dosya görünümünü, commit listesini ve değişiklik ekranını inceleyin. Anahtar yalnızca son commit’te mi yer alıyor, yoksa daha eski commit’lerde, farklı bir dosyada veya yeniden adlandırılmış bir dosyanın geçmişinde de bulunuyor mu kontrol edin.

2. İlgili anahtarı sağlayıcının yönetim ekranından iptal edin veya yenileyin.

   API anahtarını üreten hizmetin kendi hesabınız, proje ayarlarınız veya anahtar yönetimi ekranını kullanın. İptal etme ya da yenileme adımlarının kullanılan hizmete göre değişebileceğini unutmayın. Buradaki amaç, GitHub’dan dosyayı silmek değil, açığa çıkan değerin kullanılmasını engelleyecek işlemi doğrudan anahtarın sahibi olan hizmet üzerinde yapmaktır.

3. Yeni anahtarı eski değerin yerine güvenli biçimde yerleştirin.

   Yeni değer aldıktan sonra onu Python dosyanıza yapıştırmak yerine yerel .env dosyanıza yazın. Kodunuzun bu değeri os.getenv() veya benzeri bir ortam değişkeni okuma yöntemiyle almasını sağlayın. Eski anahtarın geçtiği satırı silmek, yeni anahtarı yine kaynak koduna yazmak anlamına gelmemelidir.

4. .env ve .gitignore durumunu kontrol edin.

   Proje klasöründe gerçekten .env dosyası bulunduğundan ve .gitignore içinde .env satırının yer aldığından emin olun. Ayrıca dosyanın daha önce Git tarafından izlenmeye başlanıp başlanmadığını kontrol edin. Bir dosyanın .gitignore içine sonradan eklenmesi, daha önce izlemeye alınmış bir dosyayı otomatik olarak geçmişten çıkarmaz.

5. Repository geçmişinde eski değeri tarayın.

   GitHub’daki mevcut dosyaları kontrol etmekle yetinmeyin. Commit geçmişinde, eski branch’lerde veya farklı dosya yollarında aynı değerin bulunup bulunmadığını araştırın. Bir dosyayı güncel sürümden silmek, o dosyanın eski commit’lerdeki kopyalarını otomatik olarak ortadan kaldırmaz.

6. Gerekirse Git geçmişini temizlemek için yedekli bir plan hazırlayın.

   Eski API anahtarı geçmiş commit’lerde görünmeye devam ediyorsa Git geçmişinin yeniden yazılması gündeme gelebilir. Bu işlem basit bir dosya silme işleminden farklıdır; commit kimlikleri değişebilir, branch’ler etkilenebilir ve zorla gönderim gerekebilir. Önce repository’nin ayrı bir yedeğini alın, hangi branch ve etiketlerin etkileneceğini belirleyin, ardından kullanılacak yöntemi anlayarak ilerleyin.

   Özellikle ekip üyelerinin yerel kopyaları varsa, geçmiş temizleme işleminden önce koordinasyon yapılmalıdır. Hazırlıksız bir geçmiş değişikliği, eski kopyaların yeniden gönderilmesine veya temizlenmiş geçmişin tekrar kirlenmesine yol açabilir.

7. Ekip üyelerini veya proje sahibini bilgilendirin.

   Repository ortak kullanılıyorsa durumu saklamayın. Hangi anahtarın, hangi dosyada ve yaklaşık hangi commit içinde göründüğünü; iptal veya yenileme işleminin yapılıp yapılmadığını ve geçmiş temizliği gerekip gerekmediğini açıkça paylaşın. Böylece başka bir kişinin eski branch’i kullanarak aynı değeri yeniden yayınlama ihtimali azalır.

Dosyayı silmek ile geçmişi temizlemek arasındaki fark

Örneğin .env dosyasını yerel klasörden silip yeni bir commit oluşturduğunuzu düşünün. Repository’nin güncel görünümünde dosya artık yer almayabilir; ancak anahtarın bulunduğu önceki commit hâlâ Git geçmişinde durabilir. Bu nedenle dosyayı silmek, sızıntının izini otomatik olarak ortadan kaldırmaz.

Anahtar geçersiz hâle getirildikten sonra geçmiş temizliği yapılması, değerin eski commit’lerde görünmesini azaltmaya yardımcı olabilir. Ancak bu işlem; başka yerel klonlar, fork’lar, pull request kayıtları veya daha önce kopyalanmış içerikler gibi farklı kopyaların ayrıca değerlendirilmesini gerektirebilir. Bu yüzden geçmişi yeniden yazmayı, yedek almadan ve etkilerini anlamadan denemeyin.

Push öncesi son kontrol

• .env dosyası proje klasöründe var mı?
• .gitignore içinde .env satırı bulunuyor mu?
• git diff çıktısında gerçek API anahtarı veya başka bir hassas değer görünüyor mu?
• Örnek yapılandırma dosyasında gerçek anahtar yerine yalnızca değişken adı veya örnek bir yer tutucu bulunuyor mu?

GitHub’a Push Etmeden Önce Güvenli Çalışma Akışı

Yeni başlayan bir Python geliştiricisi için güvenli çalışma akışı, karmaşık araçlardan önce birkaç düzenli alışkanlığa dayanır: hassas değeri .env içine yazmak, Python’da ortam değişkeninden okumak, .env dosyasını Git dışında bırakmak ve commit öncesi değişiklikleri gözden geçirmek.

python-dotenv paketi, .env içindeki anahtar-değer çiftlerini okuyarak bunların Python sürecindeki ortam değişkenleri gibi kullanılmasına yardımcı olur. Kurulum ve temel kullanım mantığı için paketin PyPI üzerindeki resmî proje sayfasını esas alabilirsiniz.

Her projede uygulanabilecek adım adım akış

1. Hassas bilgiyi .env dosyasına yazın.

   Proje klasörünün kökünde .env adlı bir dosya oluşturun. API anahtarını burada değişken adıyla birlikte tanımlayın:

   API_KEY=gercek_deger_burada

   Bu dosya yerel çalışma ortamınız içindir. Gerçek değeri Python dosyasına, README içeriğine, ekran görüntüsüne veya herkese açık bir örnek dosyasına eklemeyin.

2. Python kodunda ortam değişkeninden okuyun.

   Kodun görevi, anahtarın kendisini saklamak değil, çalışma sırasında yapılandırma değerini okumaktır. Örnek bir kullanım şu şekildedir:

   import os
   from dotenv import load_dotenv
   
   load_dotenv()
   
   api_key = os.getenv("API_KEY")
   
   if not api_key:
       raise ValueError("API_KEY bulunamadı")
   
   print("API anahtarı yüklendi.")

   Buradaki print() satırı gerçek anahtarı ekrana yazdırmaz; yalnızca değerin bulunup bulunmadığını kontrol eden basit bir örnektir. Gerçek projede API anahtarını hata mesajlarına, log kayıtlarına veya terminal çıktısına yazdırmamaya dikkat edin.

3. .env dosyasını .gitignore içine ekleyin.

   Proje kök dizinindeki .gitignore dosyasına şu satırı ekleyin:

   .env

   Bu ayar, Git’in çalışma klasöründeki .env dosyasını yeni değişiklikler arasında göstermemesine yardımcı olur. Ancak dosya daha önce commit edildiyse yalnızca bu satırı eklemek yeterli değildir; önceki bölümdeki sızıntı kontrolünü uygulamalısınız.

4. Ekip veya proje için .env.example oluşturun.

   Başka bir bilgisayarda projeyi çalıştıracak kişinin hangi değişkenleri tanımlaması gerektiğini göstermek için .env.example adlı bir dosya oluşturabilirsiniz. Bu dosyada gerçek anahtar bulunmamalıdır:

   API_KEY=your_api_key_here
   API_BASE_URL=https://example.com

   Bu dosya, gerekli değişken adlarını ve beklenen yapılandırma biçimini gösterir. Gerçek anahtar ise yalnızca ilgili kişinin kendi yerel .env dosyasına yazılmalıdır. .env.example dosyasının paylaşılması ile gerçek kimlik bilgisinin paylaşılması aynı şey değildir; önemli ayrım, dosyada kullanılabilir bir gizli değer bulunup bulunmamasıdır.

5. Commit oluşturmadan önce değişiklikleri inceleyin.

   Dosyaları Git’e eklemeden önce hangi satırların değiştiğini gözden geçirin. Özellikle yeni başlayan projelerde API anahtarı; Python dosyasına, JSON yapılandırmasına, README’ye veya test verisine yanlışlıkla eklenebilir. git diff çıktısını okumak, bu tür hataları GitHub’a gitmeden önce fark etmenin en pratik yollarından biridir.

6. GitHub’daki dosyaları yeniden kontrol edin.

   Push işleminden sonra repository’nin dosya listesini, son commit’i ve değişiklik ekranını açın. .env dosyasının yayınlanan dosyalar arasında bulunmadığını; buna karşılık .env.example dosyasının gerçek bir anahtar içermediğini doğrulayın.

Basit bir proje klasörü nasıl görünebilir?

python-projem/
├── app.py
├── .env
├── .env.example
├── .gitignore
└── requirements.txt

Bu yapıda app.py ortam değişkenini okur, .env gerçek yerel değeri taşır, .env.example gerekli değişken adlarını gösterir ve .gitignore gerçek yapılandırma dosyasının Git’e eklenmesini önlemeye yardımcı olur. requirements.txt ise projenin ihtiyaç duyduğu Python paketlerini belirtir; API anahtarının kendisini içermez.

İlk Python projenizi yüklemeden önce değişken, dosya, Git ve temel kod mantığınızı gözden geçirmek isterseniz ücretsiz kodlama bilgisi testi üzerinden hangi konuları tekrar etmeniz gerektiğini kontrol edebilirsiniz.

Bu akışı her push işleminden önce birkaç dakika uygulamak, sonradan anahtar iptal etme ve Git geçmişi temizleme gibi daha zahmetli adımların önüne geçer.

Sık Sorulan Sorular

API anahtarını .env dosyasına yazmak tek başına güvenli mi?

Hayır. .env dosyasına yazmak, anahtarı kaynak kodundan ayırır; ancak dosyanın Git’e eklenmemesi, paylaşılmaması ve cihazınızda gereksiz kişilere açılmaması da gerekir. Bu nedenle .env dosyasını .gitignore içine ekleyin, gerçek anahtarı log çıktısına yazdırmayın ve örnek dosyalarda yalnızca değişken adlarını paylaşın.

.env dosyasını .gitignore’a ekledikten sonra daha önce push edilmiş anahtar silinmiş olur mu?

Hayır. .gitignore yalnızca Git’in izleme davranışını etkiler; daha önce commit edilmiş bir anahtarın eski commit’lerdeki kopyalarını otomatik olarak silmez. Önce anahtarı sağlayıcının yönetim ekranından iptal etmek veya yenilemek, ardından repository geçmişini ve diğer kopyaları değerlendirmek gerekir.

Python’da .env dosyasındaki değeri nasıl okuyabilirim?

Önce python-dotenv paketini kurup kodunuzda from dotenv import load_dotenv ve import os kullanabilirsiniz. load_dotenv() çağrısından sonra değer, örneğin os.getenv("API_KEY") ile okunabilir. Değer bulunamadığında programın anlaşılır bir hata vermesi, eksik yapılandırmayı erken fark etmenizi sağlar.

.env.example dosyasında gerçek API anahtarı bulunmalı mı?

Hayır. .env.example dosyasında gerçek API anahtarı bulunmamalıdır. Bu dosyada yalnızca gerekli değişken adlarını ve gerekirse örnek bir yer tutucuyu gösterin. Gerçek değer, her geliştiricinin kendi yerel .env dosyasına yazılmalıdır.

Anahtarımı GitHub’a gönderdiğimi fark edersem ilk olarak ne yapmalıyım?

İlk olarak açığa çıkan anahtarı kullandığınız hizmetin kendi yönetim ekranından iptal edin veya yenileyin. Ardından hangi dosya ve commit içinde göründüğünü belirleyin, yeni anahtarı .env dosyasına taşıyın ve eski değerin Git geçmişinde bulunup bulunmadığını kontrol edin. Sadece dosyayı silmekle yetinmeyin.

Güvenli GitHub kullanımı tek seferlik bir ayar değil, her commit öncesi tekrarlanan kısa bir kontrol alışkanlığıdır.