URL etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
URL etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

14 Mayıs 2021 Cuma

Sunuculardaki Koşullu PUT İstekleri


PUT istekleri için uygulama veya eşzamanlılık kontrolünün güncellemelerde olmaması, Last-Modified ve/veya ETAG başlıklarında nasıl uygulanacağını gösterilecektir. Kaynak henüz mevcut değilse ve sunucu PUT aracılıyla kaynak oluşturmayı destekliyorsa, istemci tarafından belirtilen URl de yeni bir kaynak oluşturun. Sunucu desteklemiyorsa kaynak oluşturma, istemciye 404 durumunu döndürün. 


Kaynak varsa aşağıdaki adımları uygulayalım.

* İstemci If-Unmodified-Since ve/veya If-Match üstbilgilerini içermiyorsa döndür, 403  cevap gövdesinde nedenini açıklayın.
* Sağlanan If-Unmodified-Since veya If-Match başlıkları gerçek sunucudaki gösterimin değiştirilmiş tarih-saat ve ETAG değerleri hata döndürürse. Kod 412 (Ön koşul başarısız)
*İstemci koşullu bir PUT isteği gönerirse ve sağlanan koşullar eşleşir kaynağı günceller ve 200 (OK) veya 204 (İçerik Yok) geri dönüş sağlanır.
İsteğe bağlı olarak, sağlanan güncellenmiş Son Değiştirilmiş ve/veya ETAG başlıklarını eklenebilir. Kaynak yanıt aynı zamanda güncellenen URI ile bir Content-Location başlığı içerir.

Sunucunun yapması gereken kontrollere genel bir bakış için.





Bunun işe yaraması için her zaman Last-Modified ve/veya ETAG başlıklarını eklediğinizden emin olun. Çünkü Sunucu istemciye bir temsil döndürür.


Koşullu PUT isteklerini uygulama adımları, koşullu PUT isteklerini uygulamaya benzer GET istekleri  için bir sonraki makalede ele alınacaktır.  Temel fark If-Unmodified-Since kullanılmasıdır. ve/veya If-Match-Since ve/veya If-None-Match başlıkları yerine If-Match başlıkları kullanılabilir.

Bir müşteri tarafından gönderilen PUT isteği;


# Process this request if and only if the included conditional tags match
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"

Sunucu koşullu üstbilgiler bekleniyorsa ancak istek hiçbirini bulamazsa dönüş yanıt kodu 403 olarak geri dönüş yapılabilir. İstek koşullu başlıklar bulursa, bunları Last-Modified ve/veya ETAG değerlerinin mevcut değerleri ile karşılaştırılmalıdır. Eğer onlar eşleşirse, sunucu güncellemeyi işleyebilir. 200 (OK) yanıtı döndürebilir. Değilse; sunucu dönüş yanıt kodu 412 (Ön Koşul Başarısız) döndürebilir. Bazı örnekler için bir sonraki makalelerde yer verilecektir.

Suncu istekleri üzerine hem son değiştirilmiş hemde ETAG üst bilgileri gönderirse, PUT isteğini yanlızca If-Unmodified-Since ve If-Match başlıkları mevcut değerlerle eşleşir.  İçlerinden biri başarısız olsa bile MATCH 412 döndürülür.

İşte PUT isteklerini koşullu yapmanın neden önemli olduğunu gösteren bir örnek; İstemcilerin değiştirilebileceği ve/veya içeriği yöneten wiki benzeri bir sunucu düşünün. İçeriği silin. Değiştirilmek isteyen A ve B olmak üzere iki müşteri olduğunu varsayın. Aşağıdaki sırayla bir kaynak istemci A kaynağın bir temsilini alır. A istemcisinin bir kullanıcısı, kaynağı yerel olarak bir metin düzenleyicisinde düzenlemeye başlar.

# Request from client A
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8
...


Müşteri B aynı kaynağın bir temsilini alır ve B istemcisinin bir kullanıcısı yerel olarak düzenlemeye başlar. 

# Request from client B
GET /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8

B istemcisinin kullancısı düzenlemlerini tamamlar ve bir PUT isteğinde bulunarak değişikliği sunucuya gönderir.

# Request from client B
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF-8

İLK GÜNCELLEME:
Bir kaç saniye sonra A istemcisinin kullanıcısı düzenlemelerini bitirir ve değişiklikleri  ile birlikte gönderir. Başka bir PUT isteği;

# Request from client A
PUT /reviews/notes_from_underground HTTP/1.1
Host: www.example.org

# Response
HTTP/1.1 204 OK
Content-Type: application/xml;charset-UTF-8

ikinci güncelleme ilk güncellemenin üzerine yazar.

Bu sıranın bir sonucu olarak, A müşterisi, B müşterisi tarafından yapılan değişikliklerin üzerine yazar. İstemci B'nin güncellemesi kaybolur.! ne müşteri A nede müşteri B de kayıp güncellemeden haberi yoktur.
Her iki PUT işlemi sonuçta başarılı oldu. Ancak daha sonra B'nin kullanıcısı güncellemelerinin kaybolduğunu görecektir. Her değişikliği kaydetmek için sunucuda uygulamazsanız bu kayıp güncelleştirmeyi algılamak için sunucuda hatayı ayıklayamazsınız.

PUT isteklerini koşullu yapmak güncelleme kaybını önler. Gelen bir istek müşteri B için;

# Request from client B
PUT /reviews/notes_from_underground HTTP/1.1 >> İlk koşullu güncelleme başarılı
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT
If-Match: "3f4a74db207d0447d46710a64971e777"

# Response
HTTP/1.1 204 No Content
Content-Location: http://www.example.org/reviews/notes_from_underground
Content-Type: application/xml;charset-UTF-8
Last-Modified: Sun, 09 Aug 2020 01:10:14 GMT
If-Match: "5dcb920acfd4f3943dbc1672756d7f43"

İlk koşullu güncelleme başarılı ;
Yanıt bir Content-Location başlığı ve güncellenmiş Last-Modified ve istemcinin gelecekteki isteklerde kullanabileceği ETAG değerleri.

İstemcinin isteği koşulluysa ve sunucu istemcinin isteği çatışmaları doğru bir şekilde tanımlayabilir.

# Request from client A
PUT /reviews/notes_from_underground HTTP/1.1 > 2 nci güncelleme Failed etti. 
Host: www.example.org
If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"
# Response
HTTP/1.1 412 Precondition Failed
Content-Type: application/xml;charset-UTF-8
<error>

   <message>The review you are trying to update has changed.</message>
   <description>You are trying to update a resource based on stale information.
   Get a new copy of this review, resolve any differences, and retry.</description>
</error>



3 Nisan 2021 Cumartesi

RestFull Web Service Sunucular Arasında İşlemler Nasıl Desteklenir



Sunucu sınırlarını aşan işlemlerin nasıl destekleneceği hakkında kısa bilgi paylaşımıdır. Örneklerde; bir kullanıcı profilini bir uygulamadan diğerine taşımayı özetleri içe aktarmayı içerir. Bir müşteri ilişkileri yönetimi uygulamasında beklenen tekliflerin, taslak sunucudan üretim sunucusundaki belgeler gönderimi. Bu kullanım durumunda birden çok sunucu durumunun değişmesine ihtiyaç doğuyor. İki veya daha fazla sunucu üzerinde içerik işlemlerinin nasıl değişeceğine küçük örnek ile bakacağız.

Sunucular arası operasyonun tasarlamak ve uygulamak için sunucuların birbirleriyle işbirliği yapmasına öncelikle izin verilmeli. (cross-server operations) Bunlar veri formatlar, arka uç ara yüzleri mutabakat sağlayan sunucuları içerebilir. Veri deposundan veri yükleme, onu karşılamak için normalleştirme işlemleri, diğer sunucu biçimleri ve ardından saklanması adımları.

Sunucu sınırlarını aşan işlemlerle karşılaşıldığında endişelerin ayrılması gerekir. 

Kişi listesini dışa aktarmak için bir bağlantıyla birlikte bir kullanıcının kişi listesini temsili mesajlaşma web hizmeti:

# Request

GET /user/smith/contacts HTTP/1.1

Host: contacts.example1.org


# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset=UTF-8


<contacts xmlns:atom="http://www.w3.org/2005/Atom">

   <atom:link rel="self" href="http://contacts.example2.org/user/smith/contacts"/>

   <atom:link rel="http://contacts.example1.org/rels/export-to-messaging"

      href="http://messaging.example2.org/user/smith/import;

               t=bcb9169866c69410be37f68210a6986c"

      title="Export contacts into to messaging."/>

   <contact>

      ...

   </contact>

   ...

</contact>

     title="Export contacts into to messaging."/> > Bir sunucudan diğerine veri aktarmak için bir URl ile bağlantı kurun.

http://contacts.example2.org/rels/export-to-messaging > anlamı: con ilişki türü ile anlayan bir istemci http://tacts.example2.org/rels/export-to-messaging > dışa aktarma işlemini başlatabilir. Bu bağlantı ilişkisi türünü dökümantasyonunu müşterinin yapması gerektiğini söylediğini varsayalım. 

Kişileri mesaj hizmetine aktarmak için bağlantının URl bir POST isteği gönderin.  Bağlantının  URl yetkisiz kullanımı önlemek için bir güvenlik anahtarı içerir.


# Request

POST /user/smith/import;t=bcb9169866c69410be37f68210a6986c HTTP/1.1

Host: messaging.example2.org

# Response

HTTP/1.1 303 See Other

Location: http://messaging.example2.org/user/smith

Content-Type: application/xml;charset=UTF-8


POST /user/smith/import;t=bcb9169866c69410be37f68210a6986c HTTP/1.1 > Veriyi dışarıya aktarma talebi

Location: http://messaging.example2.org/user/smith > Dışarıya aktarma sonuçlarını sağlayan URl.

 İstemci bu isteği gönderdiğinde mesajlaşma hizmeti bir arka uç isteğinde bulunur. Bu istek Rehber hizmetinin bir kopyasını alabilmek için Rehber web hizmetine bağlanır. Bu işlemler sırasında sunucular arasında güvenliğin nasıl yönetildiğine dair mesajlaşma web servisi mevcut olabilir. Kişiler web hizmetinin URl dahil edilen bir belirteç yardımıyla.

Bu süreçte sunucular kişi listesi verilerinin yapıldığından emin olmaktan sorumludur. Müşteri yalnızca operasyonu tetiklemekten sorumludur. Bu istemciyi sunucunun uygulama ayrıntılarından ayrı tutar. Eşzamanlı kontrol, Eşzamanlı , veri formatlarındaki farklılıklar v.b Sunucu arasındaki koordinasyonun sonuçlarındandır.

Teknik veya organizasyon nedeniyle böyle bir koordinasyon mümkün olmadığında veya bölgesel sorunlardan dolayı,  istemcinin tüm kişileri indirmekten başka seçeneği yoktur. 

13 Mart 2021 Cumartesi

URL lerdeki Hasas Bilgiler

 

  URL üzerindeki verilerin kurcalandığını algılamak için algoritmaları kullanarak URL üzerindeki verilerin dijital imzasını hesaplayabiliriz. HMAC-SHA1 ve RSA-SHA1 gibi. URL kaynağına imzayı bir sorgu parametresi gibi eklemek.

URL lerdeki veriler gizliyse AES, Blowfish veri algoritmalarını şifreleyin. DES, Triple DES, Serpent, Twofish v.b URL dahil olan sonucu Base64 olarak kodladığınızdan emin olun.

Örnekte; Sigorta teklif örneğinde; sunucu gösterimindeki bir bağlantıda bir alıntı yayınlamak için kullanılan verileri kodlar.  Teklife göre sigorta satın almak için bağlantıyı kullanır.

# Request

GET /quotegen?fname=...&lname=...&... HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset=UTF-8

<quote xmlns:atom="http://www.w3.org/2005/Atom">

   <driver>

      ...

   </driver>

   <vehicle>

      ...

   </vehicle>

   <offer>

      ...

      <valid-until>2009-08-02</valid-until>

      <atom:link href="http://www.example.org/quotes/buy?fname=...&lname=...&..."

               rel="http://www.example.org/quotes/buy"/>

   </offer>

</quote>


Bağlantıda kullanılan URL deki kodlanan durum kurcalamaya eğimlidir. Bunu önlemek için sunucu teklif oluşturmak için kullanılan tüm önemli parametrelerin imzasını içerebilir.

http://www.example.org/quotes/buy?fname=...&lname=...&...&sign=f5b244520c2a452a0ee8c8b6ab5b6828317d2f7f


Bu örnekteki imza HMAC-SHA1 ve bilinen bir imza kullanılarak hesaplanmıştır. İstemci bir talep de bulunduğunda sunucu imzayı yeniden hesaplar, URL dahil edilen verilerin bir kısmı ve URL de bulunan imza ile karşılaştırın. Bu değer arasındaki herhangi bir fark verilerin tahrif edildiğini gösterir.

Sunucu bunun yerine durumu şifreleyebilir ve şifreli durumu kullanabilir.

http://www.example.org/quotes/buy?gZwEW9oJIlZhYa1CuJ9IshGyvYJp2Gfo99M5115
hWRKk497mkAOrnBZhkSb18UBzYftLpnryxUT2Y0C8GFDpNT64hypV4kMu


TLS kullanmak bir seçenek olmadığında; sunucu istemcinin gövdeyi eklemesini isteyebilir. İmzadaki talebin durumunda, sunucunun bir tanımlayıcı ataması ve her müşteri için paylaşılan bir  imza ve müşterinin kullanması gereken algoritmayı belgelendiren imzalar oluşturur. Örnek; OAuth istekleri için şunlar içerir.
* Talebin gövdesinde yer alan herhangi bir parametrenin imzası;
* Özet kimlik doğrulaması qop=auth-int ile birlikte; isteğin gövdesini de özetin bir parçası olarak kullanır.

Her iki yaklaşımda talebin bütünlüğünü sağlar.