Kimlik Doğrulama

Sayfayı kopyala

Shopify Flow webhook'unuzu statik belirteç veya HMAC SHA-256 imzasıyla koruyun; Stripe, GitHub ve Slack gibi göndericiler için hazır ayarları kullanın.

Bir webhook URL’sini bilen herkes bu URL’ye istek gönderebilir; bu nedenle, bir yabancının Shopify Flow iş akışlarınızı tetiklemesini engelleyen şey kimlik doğrulamadır. Bu ayarı, her bir webhook için ayrı ayrı, webhook’un Güvenlik bölümünden yapabilirsiniz.

Üç yöntem

Yöntem	Arayanın kimliğini nasıl kanıtladığı	Şu durumlarda kullanın:
Yok	Hiçbir şey	Yalnızca test amaçlıdır - asla üretim ortamında kullanılmaz
Statik belirteç	Bir istek başlığında sabit bir gizli değer	Hemen hemen her entegrasyon (n8n, Make, Zapier, kendi kodunuz)
HMAC SHA-256	İstek ve paylaşılan gizli anahtardan hesaplanan bir imza	Gönderici, webhook’larını imzalar (Stripe, GitHub, Slack, …)

Statik belirteç

Güçlü bir rastgele belirteç elde etmek için webhook üzerindeki “oluştur” düğmesine basın ya da kendi belirteçinizi yapıştırın. Çağrı yapan taraf bunu bir başlık içinde gönderir:

Webhook düzenleyicisi: sol tarafta ad ve kimlik doğrulama; sağ tarafta ise durum, webhook URL’si ve webhook kimliğini içeren Uç Nokta kartı; bunların üstünde Canlı Önizleme, Test ve Kullanım seçenekleri yer almaktadır — Statik bir jeton: Göndericinin bunu nasıl ileteceğini seçin, jetonu oluşturun veya yapıştırın ve Uç Nokta kartından webhook URL’sini kopyalayın.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: your-token" \
  -d '{"orderId":"1001"}'

Başlık adını değiştirme

Bazı sistemler yalnızca halihazırda kullandıkları bir başlığı gönderebilir. Gelişmiş Ayarlar’da Auth başlık adını belirleyin; biz de X-Api-Key yerine o başlıktan jetonu okuruz:

bash

  -H "X-Custom-Auth: your-token"

Başlık adlarında büyük/küçük harf ayrımı yapılmaz. Ayrılmış adlar reddedilir - Host, Authorization, Cookie, X-Forwarded-*, X-Webhook-*, CF-* ve benzeri. Bunlar, proxy sunucuları ve CDN’ler tarafından ayarlanır veya yeniden yazılır; dolayısıyla bunlardan okunan bir jeton, saldırgan tarafından kontrol edilebilir hale gelir.

Token'ın gittiği yerler

Her gönderen, istediği başlığı ekleyemez. Gönderen, jetonu nasıl iletir? “Webhook” sekmesinde bunun için dört seçenek sunulmaktadır:

Seçim	Gönderici şunları gönderir:	Şu durumlarda kullanın:
Özel bir başlıkta	`X-Api-Key: <token>` veya seçtiğiniz başlık adı	Varsayılan ayar ve çoğu entegrasyonun yaptığı şey
Taşıyıcı token olarak	`Authorization: Bearer <token>`	Bu araçta bir “Bearer” veya “API-token” alanı bulunmaktadır
Kullanıcı adı ve şifre olarak	HTTP Basic: Seçtiğiniz bir kullanıcı adı ve şifre olarak jeton kullanılır	Bu araç yalnızca Temel kimlik doğrulama özelliğini sunmaktadır
URL'de	`?token=<token>` veya seçtiğiniz parametre adı	Gönderen yalnızca düz bir URL’ye erişebilir ve başlık ayarlayamaz

Authorization, kasıtlı olarak ayrılmış bir özel başlık adı olarak kalır: Bearer ve Basic, bu başlığı kullanmanın desteklenen yöntemleridir ve her ikisi de sizin adınıza işlenir. Bu iki yöntemde verilen bir 401 yanıtı, bir WWW-Authenticate başlığını da içerir; çünkü bazı HTTP istemcileri, kimlik bilgilerini ancak kimlik doğrulama talebi aldıktan sonra gönderir.

URL seçeneği, bu dört seçenekten en zayıf olanıdır - URL’ler günlük dosyalarına, yönlendirme kaynaklarına ve tarayıcı geçmişine kaydedilir - bu nedenle, yalnızca gönderen size başka seçenek bırakmadığında bu seçeneği kullanın. Uygulama, jetonu içeren tamamlanmış URL’yi gösterir ve isteği kaydettiği her yerde bu parametreyi gizler.

HMAC SHA-256

Gönderen, paylaşılan bir gizli anahtar kullanarak istek üzerinde bir imza hesaplar; biz de bunu yeniden hesaplayıp karşılaştırırız. Sızdırılmış bir istek, içeriği değiştirilerek tekrar gönderilemez; çünkü istek gövdesi artık imzayla eşleşmez.

Sağlayıcı ön ayarları

İmza sağlayıcısı bölümünden sağlayıcınızı seçin; biz de o sağlayıcının tam şemasını (başlık adı, kodlama, neyin imzalandığı ve imzanın ne kadar süreyle geçerli kalacağı) kullanarak doğrulama yapacağız. Sağlayıcının kontrol panelinden imza anahtarını yapıştırın, hepsi bu kadar.

Her biri kendi kurulum kılavuzuna sahip 22 yerleşik sağlayıcı bulunmaktadır: Calendly, Customer.io, GitHub, Lemon Squeezy, Linear, Mollie, Paddle, Paystack, Razorpay, Sanity, Sendcloud, Sentry, Shopify, Slack, Square, Standart Webhook'lar (OpenAI, Supabase), Stripe, Svix (Clerk, Resend), Typeform, Vercel, WooCommerce ve Zendesk. Kullandığınız sağlayıcı listede yoksa, özel bir şema kullanarak nasıl oturum açıldığını açıklayın.

Tam liste, özel seçenek ve yerleşik imza doğrulama aracı hakkında bilgi için bkz. İmzalı webhook'ların doğrulanması.

HMAC kimlik doğrulamasına sahip ve imza sağlayıcısı olarak Stripe’ı kullanan bir webhook; burada “imza gizli anahtarı” alanı, bu alanın neyi kontrol ettiği ve Stripe’a bağlanma adımları gösterilmektedir — İmzalı bir gönderen (burada Stripe): sağlayıcıyı seçin, imzalama gizli anahtarını yapıştırın; düzenleyici, hangi alanların işaretli olduğunu ve nasıl bağlanacağını gösterir.

Genel HMAC

Önceden tanımlanmış bir şema ya da özel bir şema olmadığından, kendi yöntemimizi kullanıyoruz: Çağrı yapan taraf, imza gizli anahtarını kullanarak X-Webhook-* başlık değerlerinin HMAC-SHA256 şifrelemesini içeren X-Signature başlığını gönderir.

bash

curl -X POST https://your-app-url/webhook/ab12cd34 \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Data: value1value2" \
  -H "X-Signature: <hmac-sha256 of the X-Webhook-* values>" \
  -d '{"data":"payload"}'

Bir reddedilme nasıl görünür?

Kimlik doğrulama başarısız olduğunda, nedeni belirten bir JSON gövdesi ile birlikte 401 kodu döndürülür - tam kod listesi için bkz. Geçmiş ve sorun giderme. Reddedilen çağrılar, webhook'u düzenlerken Canlı İstek Denetleyicisi'nde hâlâ görünür; böylece bir çağrının neden geri döndüğünü tam olarak görebilirsiniz.

Kesintiye yol açmadan sırrı döndürmek

Bir gizli anahtarı tek adımda değiştirmek, gönderen bu değişikliğe uyum sağlayana kadar eski anahtarla imzalanmış tüm isteklerin başarısız olması anlamına gelir. Webhook üzerinden gizli anahtarı döndürmek bu sorunu önler: statik jeton ve her imza şeması için, ana anahtarın yanı sıra kabul edilen ikinci bir** geçerli gizli anahtar** barındırır.

Yeni şifreyi İkinci geçerli şifre alanına girin ve kaydedin. Artık her ikisi de kabul ediliyor.
Göndericiyi yeni gizli anahtara geçirin.
Tanıt düğmesine basın; bu işlem, öğeyi ana alana taşır ve ikinci alanı temizler; ardından kaydedin.

Hiçbir istek hiçbir aşamada reddedilmez. İkinci gizli anahtar, ana gizli anahtarla tamamen aynı şekilde saklanır ve API tarafından asla geri döndürülmez; yalnızca ayarlanıp ayarlanmadığı bilgisi verilir.

Sırrı güvende tutmak

REST API’miz veya MCP sunucumuz, hiçbir erişim düzeyinde bu jetonu asla geri vermez; bunlar Yalnızca bunlardan birinin ayarlanıp ayarlanmadığını bildirir. Bkz. Geliştirici API'si ve MCP.
Depolandığı sırada şifrelenmiştir.
Döndürme işlemi anında geçerli olur; bu nedenle, aşağıdakini kullanmak yerine yukarıdaki ikinci gizli akışı kullanın: ana alanı üzerine yazmak.
Kaydedilen çağrı geçmişi, kimlik doğrulama başlığını, Temel kimlik bilgilerini ve URL belirtecini gizler, Yani, “Geçmiş” ekran görüntüsü gizli bilgilerinizi açığa çıkarmaz.

Daha da daraltmak

Kimlik doğrulama, arayanın gizli bilgiyi bildiğini kanıtlar. IP izin listeleri, aramanın nereden gelebileceğini sınırlar ve yukarıdaki modlardan herhangi biriyle birleştirilebilir.