Oturumlar RESTfulness'i gerçekten ihlal ediyor mu?

RESTful API'sinde oturum kullanmak RESTfulness'i gerçekten ihlal ediyor mu? Her iki yönde de birçok fikir gördüm, ancak oturumların RESTsiz olduğuna ikna olmadım . Benim açımdan:

• RESTfulness için kimlik doğrulaması yasak değildir (aksi takdirde RESTful hizmetlerinde çok az kullanım olurdu)
• kimlik doğrulama, istekte, genellikle başlıkta bir kimlik doğrulama belirteci göndererek yapılır
• bu kimlik doğrulama belirtecinin bir şekilde edinilmesi gerekir ve iptal edilebilir, bu durumda yenilenmesi gerekir
• kimlik doğrulama belirtecinin sunucu tarafından doğrulanması gerekir (aksi takdirde kimlik doğrulama olmaz)

Peki oturumlar bunu nasıl ihlal ediyor?

• istemci tarafında, oturumlar çerezler kullanılarak gerçekleştirilir
• çerezler sadece fazladan bir HTTP başlığıdır
• bir oturum çerezi her zaman elde edilebilir ve iptal edilebilir
• oturum çerezleri gerekirse sonsuz bir yaşam süresine sahip olabilir
• oturum kimliği (kimlik doğrulama belirteci) sunucu tarafında doğrulanır

Bu nedenle, istemciye, bir oturum çerezi diğer herhangi bir HTTP üstbilgisi tabanlı kimlik doğrulama mekanizmasıyla tamamen aynıdır, tek fark, başka bir özel üstbilgi Cookieyerine üstbilgiyi kullanmasıdır Authorization. Sunucu tarafında çerez değeri eklenmiş bir oturum olmasaydı, bu neden bir fark yaratsın ki? Sunucu RESTful davrandığı sürece sunucu tarafı uygulamasının istemciyi ilgilendirmesi gerekmez . Bu nedenle, çerezler kendi başlarına bir API RESTless yapmamalıdır ve oturumlar sadece istemciye çerezlerdir.

Varsayımlarım yanlış mı? Oturum çerezlerini RESTless yapan nedir ?

İlk olarak, bazı terimleri tanımlayalım:

• RESTful:

  Bu bölümde açıklanan REST kısıtlamalarına uygun uygulamaları "RESTful" olarak nitelendirebilirsiniz. [15] Bir hizmet gerekli kısıtlamalardan herhangi birini ihlal ediyorsa, RESTful olarak değerlendirilemez.

  Wikipedia'ya göre .

• vatansız kısıtlama:

  Daha sonra istemci-sunucu etkileşimi için bir kısıtlama ekliyoruz: iletişim, bölüm 3.4.3'teki istemci-durumsuz sunucu (CSS) stilinde olduğu gibi, doğada vatansız olmalıdır (Şekil 5-3), böylece istemciden gelen her istek sunucu, isteği anlamak için gerekli tüm bilgileri içermelidir ve sunucuda depolanan herhangi bir bağlamdan yararlanamaz. Dolayısıyla oturum durumu tamamen müşteri üzerinde tutulur.

  göre Fielding tez .

Sunucu tarafı oturumları REST'in durumsuz kısıtlamasını ve dolayısıyla RESTfulness'i de ihlal eder.

Bu nedenle, istemciye bir oturum çerezi, Yetkilendirme veya başka bir özel başlık yerine Çerez başlığını kullanması dışında, diğer HTTP üstbilgisi tabanlı kimlik doğrulama mekanizmalarıyla tamamen aynıdır.

Oturum çerezleriyle, istemci durumunu sunucuda depolarsınız ve böylece isteğinizin bir bağlamı olur. Sisteminize bir yük dengeleyici ve başka bir servis örneği eklemeye çalışalım. Bu durumda oturumları hizmet örnekleri arasında paylaşmanız gerekir. Böyle bir sistemi korumak ve genişletmek zordur, bu nedenle kötü ölçeklenir ...

Bence çerezlerde yanlış bir şey yok. Çerez teknolojisi, saklanan verilerin her istekle otomatik olarak çerez başlıklarına eklendiği istemci tarafında depolama mekanizmasıdır. Bu tür bir teknoloji ile problemi olan bir REST kısıtlaması bilmiyorum. Bu yüzden teknolojinin kendisinde bir sorun yok, sorun kullanımı ile ilgili. Fielding, HTTP çerezlerinin neden kötü olduğunu düşündüğü hakkında bir alt bölüm yazdı .

Benim açımdan:

• RESTfulness için kimlik doğrulaması yasak değildir (aksi takdirde RESTful hizmetlerinde çok az kullanım olurdu)
• kimlik doğrulama, istekte, genellikle başlıkta bir kimlik doğrulama belirteci göndererek yapılır
• bu kimlik doğrulama belirtecinin bir şekilde edinilmesi gerekir ve iptal edilebilir, bu durumda yenilenmesi gerekir
• kimlik doğrulama belirtecinin sunucu tarafından doğrulanması gerekir (aksi takdirde kimlik doğrulama olmaz)

Bakış açınız oldukça sağlamdı. Tek sorun, sunucuda kimlik doğrulama jetonu oluşturma konseptiydi. O kısma ihtiyacınız yok. İhtiyacınız olan şey, kullanıcı adını ve şifreyi istemcide depolamak ve her istekte göndermek. Bunu yapmak için HTTP temel yetkilendirmesinden ve şifreli bir bağlantıdan daha fazlasına ihtiyacınız yoktur:

• Şekil 1. - Güvenilir istemciler tarafından durumsuz kimlik doğrulaması

Her isteği doğrulamak zorunda olduğunuz için, işleri daha hızlı hale getirmek için muhtemelen bir bellek içi kimlik doğrulama önbelleğine ihtiyacınız vardır.

Şimdi bu, sizin tarafınızdan yazılmış güvenilir müşteriler tarafından oldukça iyi çalışır, ancak 3. taraf müşteriler ne olacak? Kullanıcı adı, şifre ve kullanıcıların tüm izinlerine sahip olamazlar. Bu nedenle, üçüncü taraf bir istemcinin belirli bir kullanıcı tarafından sahip olabileceği izinleri ayrı olarak depolamanız gerekir. Böylece istemci geliştiricileri üçüncü taraf istemcileri kaydedebilir ve benzersiz bir API anahtarı alabilir ve kullanıcılar üçüncü taraf istemcilerin izinlerinin bir kısmına erişmesine izin verebilir. Adı ve e-posta adresini okumak veya arkadaşlarını listelemek vb. Gibi ... 3. taraf bir istemciye izin verdikten sonra sunucu bir erişim belirteci oluşturur. Bu erişim belirteci, üçüncü taraf istemci tarafından kullanıcı tarafından verilen izinlere erişmek için kullanılabilir, örneğin:

• Şekil 2. - 3. taraf istemciler tarafından durumsuz kimlik doğrulaması

Böylece üçüncü taraf istemci erişim kodunu güvenilir bir istemciden (veya doğrudan kullanıcıdan) alabilir. Bundan sonra API anahtarı ve erişim belirteci ile geçerli bir istek gönderebilir. Bu en temel 3. taraf kimlik doğrulama mekanizmasıdır. Uygulama ayrıntıları hakkında her 3. taraf kimlik doğrulama sisteminin (ör. OAuth) belgelerinde daha fazla bilgi edinebilirsiniz. Tabii ki bu daha karmaşık ve daha güvenli olabilir, örneğin her bir isteğin ayrıntılarını sunucu tarafında imzalayabilir ve imzayı istekle birlikte gönderebilirsiniz, vb ... Asıl çözüm, uygulamanızın ihtiyacına bağlıdır.

Her şeyden önce, REST bir din değildir ve böyle düşünülmemelidir. RESTful hizmetlerinin avantajları olsa da, REST'in ilkelerini yalnızca uygulamanız için anlamlı oldukları ölçüde takip etmelisiniz.

Bununla birlikte, kimlik doğrulama ve istemci tarafı durumu REST ilkelerini ihlal etmez. REST, durum geçişlerinin durumsuz olmasını gerektirse de, bu sunucunun kendisine işaret eder. Kalbinde, tüm REST belgelerle ilgilidir. Vatansızlığın ardındaki fikir, SUNUCU'nun vatansız olmasıdır, müşteriler değil. Aynı istekte bulunan tüm müşteriler (aynı başlıklar, çerezler, URI, vb.) Başvuruda aynı yere götürülmelidir. Web sitesi, kullanıcının geçerli konumunu depoladıysa ve bu sunucu tarafı gezinme değişkenini güncelleyerek gezinmeyi yönettiyse, REST ihlal edilir. Aynı istek bilgilerine sahip başka bir istemci, sunucu tarafı durumuna bağlı olarak farklı bir konuma alınacaktır.

Google'ın web hizmetleri, RESTful sistemine harika bir örnektir. Her istek üzerine kullanıcının kimlik doğrulama anahtarını içeren bir kimlik doğrulama başlığı gerekir. Sunucu kimlik doğrulama anahtarının durumunu izlediğinden, bu durum REST ilkelerini biraz ihlal eder. Bu anahtarın durumu korunmalı ve artık bir süre için erişim izni vermeyecek bir tür son kullanma tarihi / saati olmalıdır. Ancak, yazımın en üstünde bahsettiğim gibi, bir uygulamanın gerçekten çalışabilmesi için fedakarlıklar yapılmalıdır. Bununla birlikte, kimlik doğrulama jetonları, tüm olası istemcilerin geçerli zamanlarında erişim vermeye devam etmelerini sağlayacak şekilde saklanmalıdır. Bir sunucu kimlik doğrulama anahtarının durumunu başka bir yük dengeli sunucunun bu anahtara dayalı istekleri yerine getiremediği noktaya kadar yönetiyorsa, REST ilkelerini gerçekten ihlal etmeye başladınız. Google'ın hizmetleri, telefonunuzda kullandığınız bir kimlik doğrulama jetonunu yük dengeleme sunucusu A'ya karşı alabilmenizi ve masaüstünüzden yük dengeleme sunucusu B'ye basabilmenizi ve yine de sisteme erişebilmenizi ve aynı kaynaklara yönlendirilmesini sağlar. istekler aynıydı.

Tüm bunlar, mümkün olan en fazla REST özelliğini korumak için kimlik doğrulama belirteçlerinizin bir çeşit depolama deposuna (veritabanı, önbellek, ne olursa olsun) karşı doğrulandığından emin olmanız gerektiğidir.

Umarım bunların hepsi mantıklıdır. Henüz yapmadıysanız , Temsili Durum Transferi ile ilgili wikipedia makalesinin Sınırlamalar bölümünü de kontrol etmelisiniz . Özellikle REST ilkelerinin ne için tartıştığını ve nedenini aydınlatır.

Çerezler kimlik doğrulaması için değildir. Neden tekerleği yeniden icat ettiniz? HTTP'nin iyi tasarlanmış kimlik doğrulama mekanizmaları vardır. Çerezleri kullanırsak, HTTP'yi yalnızca bir aktarım protokolü olarak kullanırız, bu nedenle , kullanıcılara yanlış kimlik doğrulama sağladıklarını söylemek için kendi sinyal sistemimizi oluşturmamız gerekir (muhtemelen HTTP 401 kullanmak yanlış olmaz. Www-AuthenticateHTTP spesifikasyonlarının gerektirdiği gibi bir istemciye tedarik :)). Ayrıca Set-Cookie, sadece müşteri için bir öneri olduğuna dikkat edilmelidir . AuthorizationHer istek üzerine başlık otomatik olarak gönderilirken içeriği kaydedilebilir veya kaydedilemeyebilir (örneğin, çerezler devre dışı bırakılmışsa) .

Başka bir nokta, bir yetkilendirme çerezi almak için muhtemelen kimlik bilgilerinizi önce bir yere vermek isteyeceğinizdir. Eğer öyleyse, o zaman RESTless olmaz mıydı? Basit bir örnek:

• Denemek GET /açerezi olmadan
• Bir şekilde bir yetkilendirme isteği alıyorsunuz
• Gidin ve bir şekilde yetkilendirin POST /auth
• Sen al Set-Cookie
• Çerez GET /a ile deneyin . Ancak GET /abu durumda kasıtlı olarak davranmıyor mu?

Bunu özetlemek gerekirse, bir kaynağa erişirsek ve kimlik doğrulamamız gerekirse , başka bir yerde değil aynı kaynakta kimlik doğrulaması yapmamız gerektiğine inanıyorum .

Aslında, RESTfulness bir Evrensel Kaynak Tanımlayıcı tarafından belirtildiği gibi yalnızca KAYNAKLAR için geçerlidir. Bu nedenle, REST ile ilgili başlıklar, çerezler, vb. Şeylerden bahsetmek bile uygun değildir. REST, HTTP üzerinden rutin olarak yapılsa bile, herhangi bir protokol üzerinde çalışabilir.

Ana belirleyici şudur: URI olan bir REST çağrısı gönderirseniz, çağrı sunucuya başarılı bir şekilde yapıldığında, geçiş yapılmadığı varsayılarak URI aynı içeriği döndürür mü (PUT, POST, DELETE) ? Bu test, döndürülen hataları veya kimlik doğrulama isteklerini hariç tutar; çünkü bu durumda, istek henüz sunucuya gönderilmez; bu, verilen URI'ye karşılık gelen belgeyi döndürecek sunucu uygulaması veya uygulama anlamına gelir.

Benzer şekilde, bir POST veya PUT durumunda, belirli bir URI / yük yükleyebilir ve mesajı kaç kez gönderirseniz verin, her zaman aynı verileri güncelleyecek, böylece sonraki GET'ler tutarlı bir sonuç döndürecektir?

REST, uygulama verileriyle ilgilidir, bu verilerin aktarılması için gereken düşük düzeyli bilgilerle ilgili değildir.

Aşağıdaki blog yazısında, Roy Fielding tüm REST fikrinin güzel bir özetini verdi:

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

"RESTful bir sistem bir sabit durumdan diğerine ilerler ve bu sabit durumların her ikisi de potansiyel bir başlangıç ​​durumu ve potansiyel bir son durumdur. Yani, RESTful sistemi basit bir dizi her zaman ya REST'te olacak ya da bir RESTful durumundan başka bir RESTful durumuna geçecek şekilde kurallar.Her bir durum, içerdiği temsil (ler) ve sağladığı geçişler (üniforma ile sınırlı) ile tamamen anlaşılabilir. Sistem karmaşık bir durum diyagramı olabilir, ancak her kullanıcı aracısı her seferinde yalnızca bir durumu görebilir (mevcut sabit durum) ve bu nedenle her durum basittir ve bağımsız olarak analiz edilebilir. kullanıcı, OTOH, istediği zaman kendi geçişlerini oluşturabilir (ör. bir URL girin, bir yer imi seçin,bir düzenleyici vb. açın). "

Bilgilerin URI ve POST yükünün bir parçası olmadığı sürece, çerezler veya başlıklar yoluyla gerçekleştirilmiş olsun, kimlik doğrulama konusuna gidildiğinde, gerçekten REST ile hiçbir ilgisi yoktur. Yani, vatansız olmakla ilgili olarak, sadece uygulama verileri hakkında konuşuyoruz.

Örneğin, kullanıcı bir GUI ekranına veri girerken, istemci hangi alanların girildiğini, hangilerinin girilmediğini, eksik olan herhangi bir alanın vb. sunucu tarafından. Sunucuya gönderilen, IDENTIFIED kaynağında (URI tarafından) değiştirilmesi gereken tüm alan kümesidir, böylece bu kaynakta bir RESTful durumundan diğerine geçiş gerçekleşir.

Böylece, istemci kullanıcının ne yaptığını izler ve sunucuya yalnızca mantıksal olarak tam durum geçişleri gönderir.

HTTP erişimi, temel erişim kimlik doğrulaması, RBAC için uygun değildir, çünkü temel erişim kimlik doğrulaması, tanımlamak için her seferinde şifrelenmiş kullanıcı adı: parolayı kullanırken, RBAC'da gerekli olan kullanıcının belirli bir arama için kullanmak istediği Roldür. RBAC, kullanıcı adındaki izinleri değil, rolleri doğrular.

Bunun gibi birleştirme yapmak için uğraşabilirsiniz: usernameRole: şifre, ancak bu kötü bir uygulamadır ve aynı zamanda verimsizdir, çünkü bir kullanıcının daha fazla rolü olduğunda, kimlik doğrulama motorunun tüm rolleri birleştirmede test etmesi gerekir ve her çağrı tekrarlanır. Bu, RBAC'ın en büyük teknik avantajlarından birini, yani çok hızlı bir yetkilendirme testini yok edecektir.

Böylece bu sorun temel erişim kimlik doğrulaması kullanılarak çözülemez.

Bu sorunu çözmek için, oturumun sürdürülmesi gereklidir ve bu, bazı cevaplara göre REST ile çelişiyor gibi görünüyor.

REST'in din muamelesi görmemesi gereken yanıtı sevdiğim şey bu. Karmaşık iş vakalarında, örneğin sağlık hizmetlerinde, RBAC kesinlikle yaygın ve gereklidir. Ve REST'i kullanmalarına izin verilmezse üzücü olurdu, çünkü tüm REST araçları tasarımcıları REST'e bir din gibi davranacaktı.

Benim için HTTP üzerinden oturum açmanın pek bir yolu yok. Bir sessionId ile çerezleri veya sessionId ile bir başlık kullanabilirsiniz.

Birinin başka bir fikri varsa bunu duymaktan memnun olurum.

jetonun, jetonu doğrulayarak ve bilgileri çözerek kimlik doğrulaması yapan, içinde kodlanmış tüm gerekli bilgileri içermesi gerektiğini düşünüyorum https://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

1. Oturumlar RESTless değil
2. Yani sadece http kullanım için REST hizmeti mi yoksa yanlış bir şey mi aldım? Çerez tabanlı oturum yalnızca kendi (!) Http tabanlı hizmetler için kullanılmalıdır! (Çerezle çalışmak, örneğin Mobil / Konsol / Masaüstü / vb. Gibi bir sorun olabilir.)
3. 3D parti geliştiricileri için RESTful hizmeti sağlarsanız, asla çerez tabanlı oturum kullanmayın, güvenlikle ilgili sorunları önlemek için jeton kullanın.