Çerezler bir RESTful API'sinde kullanılmalı mı?


77

Kullanıcıların bir web API'sinde yetkili / kimliği doğrulanmış işlemleri nasıl yaptıkları ile özellikle ilgileniyorum.

Kimlik doğrulama çerezleri REST felsefesiyle uyumlu mu ve neden?




1
@JarrodRoberson Anladığım kadarıyla, başka bir sitedeki cevaplar, soruyu burada yinelenen olarak nitelendirmezdi
Tom Squires

5
@JarrodRoberson, her bir sitenin SSS'lerine dayanarak, sorunun bu siteye ait olduğunu ve Yığın Taşması'nın olmadığını iddia ediyorum. RESTful mimarisinin bu yönüyle ilgili tasarım metodolojisi / felsefesi ve takasları ile ilgileniyorum. Yığın Taşması, bu sitenin tasarım metodolojileri ve değişimlerle ilgili olduğu uygulama soruları içindir.
Brandon Linton

1
Burada @BrandonLinton ile aynı fikirdeyim, soru Stackoverflow için çok geniş, mimari ve tasarım metodolojisi ile ilgili. OP en iyi uygulamaları ve kalıpları, önerileri ve fikirleri istiyor - belirli bir cevap değil - bu nedenle hiçbir dil belirtilmedi. Dolayısıyla, buraya ait.
dooburt

Yanıtlar:


81

İdeal bir ReSTful hizmeti, istemcilerin (tarayıcıda bulunamayan ) bir istekte gereken herhangi bir görevi yerine getirmesini sağlar ; Çünkü bunun için gereken tam durum sunucu tarafından değil istemci tarafından tutulur. Müşteri devleti tam olarak kontrol ettiğinden, devleti kendi başına yaratabilir (eğer meşru ise) ve sadece "yapılması" için API ile konuşabilir.

Çerez istemek bunu zorlaştırabilir. Tarayıcıların yanı sıra müşteriler için, çerezleri yönetmek, sorgu paramlarına, basit istek başlıklarına veya istek gövdesine kıyasla oldukça büyük bir rahatsızlıktır. Öte yandan, Tarayıcıda, çerezleri kullanmak birçok şeyi daha da kolaylaştırabilir.

Bu nedenle, bir API ilk önce Authorizationihtiyacı olan kimlik doğrulama verileri için başlığa bakabilir , çünkü muhtemelen tarayıcı dışı istemcilerin koymayı tercih edeceği yer budur, ancak tarayıcı tabanlı istemcileri basitleştirmek ve kolaylaştırmak için bir oturum çerezi de kontrol edebilir. Sunucu tarafı için giriş yapın, ancak yalnızca normal Authorizationbaşlık eksikse.

Başka bir örnek, normal olarak ayarlanmış çok sayıda parametre gerektiren karmaşık bir istek olabilir. Etkileşimli olmayan bir istemci, tüm bu verileri tek bir istekte sıkışmada sorun yaşamaz; ancak, HTML formuna dayalı bir arayüz, talebi sunmadığı için, kullanıcıların sunmaması için isteği bir kaç sayfaya (bir 'sihirbaz' sayfası kümesi gibi) bölmeyi tercih edebilir. önceki seçimlere göre geçerli olmayan seçeneklerle. Ara sayfaların tümü, değerleri istemci tarafı çerezlerinde depolayabilir, böylece yalnızca kullanıcının isteği gönderdiği son sayfanın hiçbir sunucu tarafı etkisi olmaz. API, talep gövdesinde ihtiyaç duyulan özellikleri arayabilir ve gerekli parametreler bulunmuyorsa çerezlere geri dönebilir.

Düzenleme: RE @ @ Konrad adlı kullanıcının yorumunda:

Karşılaştırıldığında belirteçleri uygulamak zordur, çünkü belirteci bir yere koymadan kolayca geçersiz kılamazsınız.

er ... sen sunucu tarafındaki çerezleri onaylıyorsun, değil mi? Eğer sırf anlattı 24 saat sonra bir çerez atmak için tarayıcıyı o olacak anlamına gelmez. Bu çerez son derece teknik bir kullanıcı tarafından kaydedilebilir ve "kullanım süresi dolduktan" sonra tekrar kullanılabilir.

Oturum verilerini sunucu tarafında saklamak istemiyorsanız, belirteci (çerez veya başka şekilde) saklamanız gerekir. Kendi kendine yeten bir kimlik doğrulama simgesi bazen Macaroon olarak adlandırılır . Bunun istemci ve sunucu arasında nasıl iletileceği (ister çerez, ister ekstra başlıklar isterse istek varlığının kendisi) kimlik doğrulama mekanizmasının kendisinden tamamen bağımsızdır.


4
+1, Yetkilendirme başlığını kullanmanın pratikliğini seviyorum, ancak müşteri için neyin işe yaradığına bağlı olarak çerezlere "geri dönüyorum".
Brandon Linton

"Tarayıcıların dışındaki müşteriler için çerezleri yönetmek oldukça büyük bir rahatsızlıktır ..." ile aynı fikirdeyim. Çogunlukla HTTP istemci kütüphaneleri çerezleri destekler, örneğin HttpClient. NET'te çerezleri sorunsuz bir şekilde kullanabilirsiniz ve bunun hakkında düşünmeniz gerekmez. Karşılaştırıldığında belirteçleri uygulamak zordur, çünkü belirteci bir yere koymadan kolayca geçersiz kılamazsınız.
Konrad

1
@Konrad, bazı tarayıcı dışı istemcilerde kolay olması nedeniyle hepsinde kolay olduğu anlamına gelmez. Yalnızca kullandığınız belirli bir müşteriyi desteklemeniz gerekiyorsa sorun değil, ancak soruyu halka açık API'lerle ilgili olarak yorumladım. içinde curlya wget, kurabiye yönetmek oldukça lanetlemek sakıncalı olduğunu ve gerçekten bir demet onlar hakkında düşünmek zorunda. Cevabımı düzenleyerek diğer noktanıza cevap verdim.
SingleNegationElimination

Yalnızca çerezleri kabul etmenin CSRF açıklarını açtığına dikkat edin. Ayrıca bakınız security.stackexchange.com/a/166798
Michael Osl

14

Evet ve Hayır - Nasıl kullandığınıza bağlı.

Çerezler, müşteride, müşteride, müşteride ve müşteride müşteri durumunu korumak için kullanılırsa, o zaman huzursuz olurlar.

Eğer sunucu durumunu cookie'ye kaydediyorsanız, temel olarak sadece istemciye yükü değiştiriyorsunuz - ki bu rahat değil.

Peki bazı örnekler nelerdir?

Dinlendirici:

  • Kimlik doğrulama ayrıntıları veya 'giriş yapın' gibi şeyler
  • Son görüntülenen sayfa veya uygulamadaki yer vb.

Huzurlu Değil:

  • Oturum bilgilerini saklama

Huzursuzluk, sunucunun vatansızlığından gelir. İstemciler uygulama durumunu koruyabilir ve sunucuya nereye gideceğini kararlaştırmak için nerede olduklarını söylemek için sunucuya gönderebilir. Temelde oturumlar / durumlar geçmişe dayalı verilere ihtiyaç duyar ve konuşmak için geçmiş isteklere dayanır, dinlendirici uygulamalar ideal değildir.


10
İstemcide bir "isLoggedIn" bayrağını saklarsanız, hiçbir kimlik doğrulaması kullanmayabilirsiniz.
tdammers

Bu kesinlikle anlamlıdır - uygulama durumunu müşteri tarafında depolamak REST ile tutarlı olmaz, ancak kendisini temsil etmek için kullandığı müşteri bilgileri iyi görünür.
Brandon Linton

1
Kimlik doğrulama bilgilerini çerezlere bırakmanın, siteler arası istek sahteciliği saldırıları olasılığını açık bıraktığını eklemek isterim. Daha iyi yollar var, Amazon’u kopyalamayı öneriyorum: docs.aws.amazon.com/AmazonS3/latest/API/…
Dobes Vandermeer

@tdammers, "isLoggedIn" bayrağı bir JWT'de ise? Daha sonra, JWT'nin uygun şekilde yayınlanması ve doğrulanması şartıyla güvenli olması gerekir.
Aaron J Spetner


12

Biri çerezleri kullanabilir. REST onlara izin verir.

REST, herhangi bir oturum bilgisinin istemci tarafında saklanmasını gerektirir, ancak kimlik doğrulama söz konusu olduğunda, bazı nedenlerin güvenlik nedeniyle sunucu tarafında kalması gerekir.

Blog yayınlarımdan birinden, kimlik doğrulama verilerinin REST ile ilgili olarak kabul edilmediğine dair genel bir anlaşma var. Bu nedenle, sunucular için bu oturum verilerinin bazılarını yanlarında tutmaları uygundur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.