Postman'ın iki değişken alanı: yanlış olanı token'ınızı workspace'inize nasıl senkronize eder

Bir form alanının içine gizlenmiş güvenlik sınırı

Postman her environment değişkenine değer için iki slot verir ve dev.to'da yayımlanan bir rehbere göre bunları karıştırmak, kimlik bilgilerini sızdırmanın en kolay yollarından biri. Initial value Postman sunucularına yüklenir ve workspace'i görebilen herkese görünür olur; current value ise yalnızca yazıldığı makinede kalır.

Makale başarısızlık senaryosunu şöyle anlatıyor: bir geliştirici bir şeyi test etmek için bir bearer token'ı bir anlığına initial value sütununa yapıştırır. Postman onu senkronize eder. Bir ekip arkadaşı collection'ı başka bir workspace'e fork'lar ya da demo paylaşmak için workspace herkese açık hale getirilir ve token, kimse tek bir dikkatsiz karakter yazmadan dağıtılmış — muhtemelen indekslenmiş — olur. Hata gizli bilginin kendisi değil; onun düşünce sütunudur.\n Gönderi, yazarın Postman ile API testi üzerine yazdığı açık kaynak kitabının bir bölümünden uyarlanmıştır.

Beş kapsam ve en dar olan kazanır

Postman {{variable}} referanslarını beş kapsam üzerinden çözer ve en spesifik eşleşme öncelik alır: local, sonra data, sonra environment, sonra collection, sonra global.

• Global: herhangi bir environment'ın dışında var olur. Oluşturması hızlıdır ve prototipleme için uygundur ama kalıcı hiçbir şey için doğru değildir.
• Collection: collection'ın kendisiyle birlikte taşınır. Suite'e ait sabitler — API sürüm dizileri ya da sabit test kaydı ID'leri gibi — için idealdir, çünkü biri collection'ı environment'larınız olmadan içe aktarsa bile hayatta kalırlar.
• Environment: iş gücü olan kapsam; deployment'lar arasında farklılık gösteren her şeyi tutar — base URL'ler, kimlik bilgileri, tenant ID'leri.
• Data: veri güdümlü çalıştırmalarda her iterasyon bir satır okuyacak şekilde CSV veya JSON dosyasından iterasyon başına sağlanır.
• Local: script'lerin içinde ayarlanır, tek bir istek ya da iterasyon boyunca yaşar, sonra yok olur. Bu kapsam diğer her şeyi geçersiz kılar.

Script'ler her kapsama kendi API'si üzerinden erişebilir — pm.environment.get, pm.collectionVariables.set, pm.globals — buna karşılık pm.variables.get öncelik zincirini otomatik olarak takip eder.

Suite'leri taşınabilir kılan tek kural

Rehberin merkezindeki disiplin şudur: environment'lar değer olarak farklılaşmalı, yapı olarak asla. Staging ve Production'ı aynı değişken adlarıyla — baseUrl, token, tenantId — ama farklı değerlerle oluşturun ve her istekte {{baseUrl}} referansı kullanın. Böylece hiçbir istek hangi environment'ın mevcut olduğunu bilmez; tüm bir suite'i deployment'lar arasında değiştirmek tek tıklamalık bir eylem haline gelir ve CI'ı üçüncü bir environment'a yönlendirmek bir refactor değil, bir dosya işi olur.

Makale bir turnusol testi de sunuyor: environment değiştirmek için isteği düzenlediğinizi hiç fark ederseniz, bir değişken eksik demektir.

Gizli bilgiler gerçekte nerede yaşamalı

Rehber, artan dikkat sırasıyla dört kural veriyor:

1. Gizli bilgiler yalnızca current value'lara gider, asla initial value'lara değil. Bir token değişkeninin initial value'sı boş ya da SET-ME-LOCALLY gibi bir placeholder olabilir — ve bu placeholder'ın ekip arkadaşlarına senkronize olması bir özelliktir, çünkü neyi sağlamaları gerektiğini belgeler.
2. Değişkenin tipini secret olarak ayarlayın. Bu, değeri ekranda maskeler ve omuz üstünden bakmaya, ekran paylaşımlarına ve hata raporlarındaki ekran görüntülerine karşı korur.
3. Gerçekten hassas materyal için Postman Vault kullanın. Vault değerleri yerelde şifrelenir ve hiçbir zaman senkronize edilmez; {{vault:my-token}} olarak referans verilir. Yazar bunu, üretim kimlik bilgilerinin Postman'da bulunması gerekiyorsa doğru yer olarak nitelendiriyor.
4. CI'da hiçbir dosya gizli bilgi taşımaz. Dışa aktarılan environment JSON'u değerleri düz metin olarak saklar; dolayısıyla dışa aktarılan environment'lar commit'lenmeden önce temizlenmelidir. Gerçek kimlik bilgisi runtime'da pipeline'ın secret store'undan girer:

newman run collection. -e Staging.postman_environment.
--env-var "token=$API_TOKEN"

--env-var bayrağı, yalnızca o çalıştırma için environment kapsamlı bir değişken enjekte eder — diskte bir şey yok, repository'de bir şey yok ve CI loglarında maskelenir.

İki hata ayıklama kısayolu

Gönderi iki zaman kazandıran ipucuyla kapanıyor. İlki, URL çubuğundaki renk: çözümlenmiş bir {{variable}} turuncu, çözümlenmemiş olan kırmızı görünür. Kırmızı genellikle adda bir yazım hatası ya da on durumdan dokuzunda açılır listede hiçbir environment seçilmemiş olması demektir.

İkincisi, Postman'ın alt bilgisindeki Console, her isteği gerçekten gönderildiği haliyle gösterir — değişkenler çözümlenmiş, son header'lar dahil. Bir istek gizemli bir şekilde yanlış host'a gittiğinde ya da {{token}}'ı literal metin olarak gönderdiğinde, Console soruşturmayı saniyeler içinde bitirir ve script'lerden gelen console.log çıktısı da oraya düşer.

Neden önemli

Geliştirici araçları üzerinden sızan token'lar, tekrarlayan ve büyük ölçüde önlenebilir bir kaza sınıfıdır: kimlik bilgisi geçerlidir, paylaşım mekanizması tasarlanmış bir özelliktir ve hata, biri collection'ı fork' edene ya da bir workspace'i herkese açık hale getirene kadar görünmez kalır. Tek bir form alanının bir senkronizasyon sınırı olduğunu anlamak, sessiz bir başarısızlığı bilinçli bir tercihe dönüştürür.

Kazanç güvenliğin ötesine uzanır. Gizli bilgileri yerelde tutan aynı beş kapsamlı model, tek bir collection'ın staging, üretim ve CI'a karşı değiştirilmeden çalışmasına da izin verir ve "benim makinemde çalışıyor" sürtünmesinin tüm bir kategorisini ortadan kaldırır. Postman workspace'lerini paylaşan ya da collection'ları dokümantasyon olarak yayımlayan herhangi bir ekip için bu, trivia değil temel hijyendir — yazarın özetiyle: environment'lar arasında aynı adlar, gizli bilgiler current value'larda ya da Vault'ta ve CI'da --env-var.