- Konu sahibi
- #1
HTTP 401, sunucunun isteği kimlik doğrulaması yapılmadığı veya gönderilen kimlik bilgilerinin geçersiz olduğu için kabul etmediğini belirten durum kodudur. En sık korumalı bir yönetim paneline, API uç noktasına veya kullanıcı hesabı gerektiren bir sayfaya geçersiz, eksik ya da süresi dolmuş oturum bilgileriyle erişildiğinde görülür. Bu hata, genellikle “yetki yok” anlamındaki HTTP 403 ile karıştırılır: 401 kimlik doğrulama aşamasının başarısız olduğunu, 403 ise sunucunun isteği anladığı halde yerine getirmeyi reddettiğini ifade eder. Bu ret izin eksikliğinden kaynaklanabilir; her 403 kimliğin tanındığını kanıtlamaz.
İstemci bir kaynak için istek gönderir. Sunucu bu kaynağın kimlik doğrulaması istediğini belirler ve HTTP standardına göre 401 yanıtında en az bir doğrulama istemi içeren
Örneğin bir API, taşıyıcı belirteç bekliyorsa istek şu yapıda olabilir:
Buradaki belirteç yalnızca örnektir; gerçek servis kendi ürettiği ve geçerlilik süresi dolmamış bir belirteç ister. Yanıt yine 401 ise belirteç eksik, hatalı biçimde gönderilmiş, süresi dolmuş veya sunucu tarafından doğrulanamıyor olabilir.
Bir web tarayıcısında 401 görüyorsanız sayfayı yenilemek tek başına yeterli olmayabilir. Oturum çerezi silinmiş, oturumun süresi dolmuş veya uygulama girişten sonra gerekli çerezi oluşturamamış olabilir.
Bir uygulama geliştiriyorsanız kimlik doğrulaması gerektiren her uç noktada başarısız durumun nedenini sunucu günlüğüne yazın; ancak parolaları, tam belirteçleri veya oturum sırlarını günlüğe kaydetmeyin. İstemciye de yalnızca sorunu teşhis etmeye yetecek genel bir hata döndürün.
Karar verirken önce sorunun kimlik doğrulama mı, izin mi, yoksa kaynak bulamama mı olduğunu ayırın:
Bu ayrım, doğrudan izinleri değiştirmek gibi yanlış bir müdahaleyi önler. İstek hiç kimlik doğrulama aşamasını geçmiyorsa önce rol veya dosya izni değiştirmek sorunu çözmez.
En yaygın hata, 401 yanıtını doğrudan “kullanıcının yetkisi yok” diye yorumlamaktır. Kullanıcı henüz tanınmamış olabilir; bu nedenle önce giriş veya kimlik bilgisi aktarımı incelenmelidir. Diğer bir hata, tarayıcıda parola doğru olduğu halde uygulamanın oturum çerezini kabul etmediğini fark etmemektir. Alan adı, HTTPS kullanımı, çerez kapsamı ve ters vekilin başlık aktarımı bu durumda kontrol edilmelidir.
Bir başka hata da API belirtecini URL parametresiyle göndermektir. Desteklenen kimlik doğrulama yöntemini kullanmak, belirtecin gereksiz yerlere yazılmasını ve günlüklerde görünmesini azaltır. Sorun yalnızca belirli bir istemcide oluşuyorsa aynı isteği yetkili ve güvenilir bir test aracıyla karşılaştırarak farkın başlık, çerez veya yönlendirme kaynaklı olup olmadığını belirleyin.
HTTP 401 nasıl çalışır?
İstemci bir kaynak için istek gönderir. Sunucu bu kaynağın kimlik doğrulaması istediğini belirler ve HTTP standardına göre 401 yanıtında en az bir doğrulama istemi içeren
WWW-Authenticate başlığını göndermek zorundadır. Bu başlık beklenen yöntemi açıklar. Başlığın eksik olduğu bir yanıt bu gerekliliği karşılamaz. İstemci daha sonra uygun kimlik bilgilerini göndererek isteği yeniden dener.Örneğin bir API, taşıyıcı belirteç bekliyorsa istek şu yapıda olabilir:
Bash:
curl -i https://api.example.com/profile \
-H "Authorization: Bearer ORNEK_TOKEN"
Buradaki belirteç yalnızca örnektir; gerçek servis kendi ürettiği ve geçerlilik süresi dolmamış bir belirteç ister. Yanıt yine 401 ise belirteç eksik, hatalı biçimde gönderilmiş, süresi dolmuş veya sunucu tarafından doğrulanamıyor olabilir.
Bir web tarayıcısında 401 görüyorsanız sayfayı yenilemek tek başına yeterli olmayabilir. Oturum çerezi silinmiş, oturumun süresi dolmuş veya uygulama girişten sonra gerekli çerezi oluşturamamış olabilir.
| Kod | Temel anlam | İlk kontrol |
|---|---|---|
| 401 | Kimlik doğrulaması eksik veya geçersiz | Oturum, belirteç ve Authorization başlığı |
| 403 | İstek anlaşıldı, yerine getirilmesi reddedildi | Rol, ACL ve kaynak izinleri |
| 404 | Kaynak bulunamıyor veya sunucu tarafından gizleniyor | URL, yönlendirme ve uygulama rotası |
HTTP 401 hatasını giderme adımları
- Yanıt başlıklarını ve sunucu günlüklerini kontrol edin.
WWW-Authenticatebaşlığında beklenen doğrulama yöntemini, günlüklerde ise eksik başlık, geçersiz belirteç veya süresi dolmuş oturum gibi nedeni arayın. - İstemcinin kimlik bilgilerini gerçekten gönderdiğini doğrulayın. API çağrısında
Authorizationbaşlığının doğru isimle, doğru şemayla ve araya istenmeyen boşluk ya da satır sonu girmeden iletildiğini kontrol edin. - Tarayıcı erişiminde hesaptan çıkıp yeniden giriş yapın. Sorun tek tarayıcıdaysa çerezin alan adı, süresi ve gönderilip gönderilmediğini inceleyin. Bozuk oturum tespit edilirse yalnız ilgili site oturumunu yenileyin; bütün tarayıcı verilerini silmek ilk teşhis adımı değildir.
- Kimlik bilgilerinin geçerliliğini doğrulayın. Parola değiştirilmişse eski parola, iptal edilmişse eski API anahtarı veya süresi dolmuşsa eski oturum belirteci kullanılmamalıdır.
- Ters vekil, yük dengeleyici veya web sunucusu yapılandırmasını inceleyin. Bu katmanların
Authorizationbaşlığını uygulamaya iletmemesi, uygulamanın her isteği kimliksiz görmesine ve sürekli 401 döndürmesine yol açabilir. - Kimlik doğrulama düzeltildikten sonra yanıt 403'e dönüşürse ret nedenini ayrıca inceleyin. Rol veya izin engeli olabilir; yalnız kod değişti diye kimliğin doğrulandığı sonucuna varmayın.
Bir uygulama geliştiriyorsanız kimlik doğrulaması gerektiren her uç noktada başarısız durumun nedenini sunucu günlüğüne yazın; ancak parolaları, tam belirteçleri veya oturum sırlarını günlüğe kaydetmeyin. İstemciye de yalnızca sorunu teşhis etmeye yetecek genel bir hata döndürün.
401, 403 ve 404 farkı
Karar verirken önce sorunun kimlik doğrulama mı, izin mi, yoksa kaynak bulamama mı olduğunu ayırın:
Bu ayrım, doğrudan izinleri değiştirmek gibi yanlış bir müdahaleyi önler. İstek hiç kimlik doğrulama aşamasını geçmiyorsa önce rol veya dosya izni değiştirmek sorunu çözmez.
Sık yapılan hatalar
En yaygın hata, 401 yanıtını doğrudan “kullanıcının yetkisi yok” diye yorumlamaktır. Kullanıcı henüz tanınmamış olabilir; bu nedenle önce giriş veya kimlik bilgisi aktarımı incelenmelidir. Diğer bir hata, tarayıcıda parola doğru olduğu halde uygulamanın oturum çerezini kabul etmediğini fark etmemektir. Alan adı, HTTPS kullanımı, çerez kapsamı ve ters vekilin başlık aktarımı bu durumda kontrol edilmelidir.
Bir başka hata da API belirtecini URL parametresiyle göndermektir. Desteklenen kimlik doğrulama yöntemini kullanmak, belirtecin gereksiz yerlere yazılmasını ve günlüklerde görünmesini azaltır. Sorun yalnızca belirli bir istemcide oluşuyorsa aynı isteği yetkili ve güvenilir bir test aracıyla karşılaştırarak farkın başlık, çerez veya yönlendirme kaynaklı olup olmadığını belirleyin.