WordPress REST API yetki hataları nasıl teşhis edilir?

WordPress REST API yetki hatasını teşhis etmek için önce isteğin kimlik doğrulama bilgisi taşıyıp taşımadığını, ardından kullanılan hesabın ilgili işlemi yapma iznine sahip olup olmadığını ve son olarak nonce, çerez veya Uygulama Parolası gibi doğrulama bilgilerinin doğru gönderildiğini kontrol edin. 401 çoğunlukla kimlik doğrulama eksikliği veya başarısızlığına, 403 ise kimliği bilinen kullanıcının işlemi yapmaya yetkisinin olmamasına işaret eder.

Hata yanıtını okuyarak başlayın​

Önce HTTP durum koduna değil, JSON yanıtındaki code, message ve varsa data alanlarına bakın. Örneğin rest_not_logged_in oturum bilgisinin ulaşmadığını, rest_cookie_invalid_nonce gönderilen nonce’un geçersiz olduğunu (çekirdekte403), rest_cannot_create ya da rest_forbidden ise işlemin mevcut kullanıcı için engellendiğini gösterir.

İsteğin gerçekten hangi yanıtı verdiğini görmek için gövdeyi ve başlıkları birlikte inceleyin:


Bu ilk POST örneği kimlik doğrulama göndermediği için standart çekirdekte başarılı kayıt değil401 yetki reddi beklenir; yalnız kontrollü bir test sitesinde deneyin. Geçerli kimlik ve yazı oluşturma capability’si gönderilirse yeni taslak nesnesi ve201 Created beklenir. 401 veya 403 alıyorsanız, henüz içerik verisini değiştirmeden kimlik doğrulama ve izin adımlarını kontrol edin.

Kimlik doğrulama türünü ayırın​

WordPress REST API çağrısı nereden yapıldığına göre farklı doğrulama bilgileri bekleyebilir:

1. Ziyaretçinin tarayıcısındaki giriş oturumu ile çağrı yapıyorsanız, WordPress oturum çereziyle birlikte geçerli bir X-WP-Nonce başlığı gönderin. Nonce, kullanıcının oturum açmış olmasını tek başına sağlamaz; mevcut oturumu doğrulayan çerez de isteğe ulaşmalıdır.
2. Harici bir komut satırı aracı veya sunucu uygulaması kullanıyorsanız, kullanıcı hesabı için oluşturulmuş Uygulama Parolasını temel kimlik doğrulama başlığıyla gönderin. Normal hesap parolasını kod içine koymayın.
3. Kullandığınız özel JWT, OAuth veya başka bir eklenti tabanlı yöntemin gerçekten etkin olduğunu ve ilgili başlık biçimini doğrulayın. WordPress çekirdeği, her özel doğrulama yönteminin başlığını kendiliğinden kabul etmez.

Uygulama Parolasıyla yapılan en küçük test şu şekildedir:


curl parola istediğinde ilgili kullanıcı için üretilmiş Uygulama Parolasını girin; normal hesap parolasını veya sırrı komut satırında/depo içinde tutmayın. Beklenen sonuç, kimliği doğrulanan kullanıcıyı açıklayan JSON yanıtıdır. 401 alırsanız parola, kullanıcı adı, HTTPS aktarımı veya sunucunun Authorization başlığını PHP/WordPress'e iletmesi incelenmelidir. 200 alıp yazı oluşturma isteğinde 403 alırsanız kimlik doğrulama çalışıyor, ancak hesabın ilgili yetkisi yoktur.

İzin ve endpoint kontrolü​

Kimlik doğrulandıktan sonra isteğin hedef endpoint'inin ve HTTP yönteminin doğru olduğundan emin olun. Bir endpoint'in listeleme işlemi GET ile çalışırken oluşturma, güncelleme veya silme için POST, PUT ya da DELETE ve ayrıca daha yüksek izin gerekebilir. Kullanıcı /wp-json/wp/v2/users/me çağrısını okuyabilir; bu, otomatik olarak yazı yayımlayabileceği anlamına gelmez.

Şu ayrım teşhisi hızlandırır:


Özel bir endpoint geliştiriyorsanız, endpoint'in permission_callback kuralını da inceleyin. Bu kural her isteği yanlışlıkla reddedebilir veya yalnızca giriş yapılmış olmayı yeterli sanabilir. İzin kontrolü, yapılacak eylem için gereken capability'yi değerlendirmelidir.

Uygulanabilir teşhis sırası​

1. Aynı isteği önce GET /wp-json/ veya kimlik doğrulama gerektirmeyen bilinen bir endpoint ile çalıştırarak REST API'nin genel olarak erişilebilir olduğunu test edin.
2. İstek yanıtındaki durum kodunu, code ve message alanlarını kaydedin; yalnızca tarayıcının gösterdiği genel hata metnine güvenmeyin.
3. Kimlik doğrulamayı ayrı olarak /wp-json/wp/v2/users/me ile test edin. Bu adım başarısızsa içerik oluşturma isteğini incelemeye geçmeyin.
4. Kimlik doğrulama başarılıysa aynı kullanıcıyla önce okuma, sonra oluşturma veya güncelleme isteğini deneyin. Fark, eksik capability ya da endpoint iznini gösterir.
5. Tarayıcı çağrısında çerez ve nonce'un aynı oturuma ait olduğunu; harici çağrıda ise Authorization başlığının sunucuya ulaştığını kontrol edin.
6. Sorun yalnızca özel route'ta görülüyorsa route kaydı, HTTP yöntemi, permission_callback ve eklentinin rol yetkilerini birlikte inceleyin.

Hiç nonce gönderilmemesi cookie REST akışında kullanıcıyı anonim kabul ettirebilir; geçersiz nonce403’ü ise kimlik doğrulanmış ama capability eksik demek değildir. WAF/CDN’nin HTML403’ünü WordPress JSON hatasıyla karıştırmayın. Application Password kendi başına genişletilmiş yetki vermez; bağlı kullanıcının yetkilerini kullanır ve cookie nonce’u aynı şekilde gerektirmez. Gerçek Authorization/cookie/nonce değerlerini teşhis kaydında maskeleyin.

Sık yapılan hatalar​

Nonce değerini statik olarak saklamak, nonce'u çerez olmadan göndermek ve normal WordPress parolasını uygulama koduna yazmak en yaygın hatalardır. Ayrıca 403 yanıtını her zaman “şifre yanlış” diye yorumlamak yanlıştır; çoğu durumda kullanıcı tanınmış, fakat istenen işlem için yetkisi yetersizdir. Güvenlik eklentileri veya sunucu kuralları da REST isteklerini engelleyebilir. Bunu ayırt etmek için aynı kimlik doğrulama testiyle yalnızca belirli endpoint'in mi, yoksa tüm REST isteklerinin mi başarısız olduğunu karşılaştırın.

Kaynaklar​

• WordPress: REST kimlik doğrulama
• WordPress: REST cookie nonce hata davranışı

Sık sorulan sorular​

Nonce ile Uygulama Parolası aynı şey midir?​

Hayır. Nonce, oturum açmış tarayıcı isteğini koruyan kısa ömürlü bir doğrulama değeridir. Uygulama Parolası ise harici uygulamanın kullanıcı hesabı adına kimlik doğrulaması yapması için kullanılan ayrı bir bilgidir.

GET çalışırken POST neden yetki hatası veriyor?​

GET çoğunlukla okuma yetkisi ister; POST ise oluşturma veya değiştirme yetkisi gerektirir. Hesabın rolü, ilgili capability ve endpoint'in izin kuralı POST için yeterli olmayabilir.

Özel endpoint'te her zaman 403 alıyorsam nereye bakmalıyım?​

Önce endpoint'in permission_callback işlevini ve döndürdüğü değeri kontrol edin. Ardından route'un gerçekten yüklendiğini, beklenen HTTP yöntemini kullandığınızı ve kontrol edilen capability'nin kullanıcı rolünde bulunduğunu doğrulayın.