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

8 Ekim 2023 Pazar

Kaynak Güncellemelerinin Geri Alınması

    Bazen istemcileri bir geri alma işlevi sağlanması gerekebilir. Örneğin; bir müşteri bir teklife yakın zamanda yapılan bazı değişiklikleri geri almak isteyebilir. Bu sorun, en son anlık görüntüyü yeniden etkinleştirme yeteneği eklenmiş bir anlık görüntü almaya benzer. 

Bir müşteri bir kaynağı güncellemek için her PUT gönderdiğinde bir anlık görüntü alınır.

Geri almak için bir denetleyici kaynağı sağlanmalı. Bir değişikliği geri almak için istemcinin POST isteği göndermesine izin verin. Kaynağın geçerli durumunu denetleme aamcıyla bir işlem günlüğüne kaydedin. Sunucu kaynağın durumunu en son anlık görüntünden geri yükler ve istemciyi kaynağın URI sine yönlendirir.

Örnek tarifte anlatılmış http://wiki.example.org/trails/ColcuckLake deki bir wiki belge düşünüldüğünde Kaynağın temsilinde geri alma işlemini gerçekleştirmek için bir bağlantı ekleyin.


# Request
GET /trails/ColchuckLake HTTP/1.1 Host: wiki.example.org

# Response
HTTP/1.1 200 OK
Last-Modified: Sun, 01 Nov 2009 16:24:56 GMT
Content-Type: application/atom+xml;type=entry;charset=UTF-8

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

<atom:name>Joe Hiker</atom:name>


</atom:author>
<atom:title>Colchuck Lake</atom:title> <atom:id>urn:example:wiki:trails:ColcuckLake</atom:id>
<atom:link href="http://wiki.example.org/trails/ColchuckLake" rel="self"/> <atom:link href="http://wiki.example.org/trails/ColchuckLake/s1" rel="previous"/> <atom:link href="http://wiki.example.org/trails/ColchuckLake/undo;

t=72f2a2342ce7dc806ae7697e138bad71" rel="http://wiki.example.org/rels/undo"/>

<atom:content xml:lang="en" atom:type="html"> ... updated draft ...

</atom:content> </atom:entry>

Kaynağı mevcut durumunu geri almak için URI  bağlantısı kurulur. İsmteci bir geri alma isteği göndermek için http://wiki.example.org/rels/undo ilişiki türünde bağlantıyı kullanabilir. Bu bağlantıdaki URI bir değişikliği geri alabilen bir denetleyici kaynağıdır.

# Request

POST /trails/ColchuckLake/undo;t=72f2a2342ce7dc806ae7697e138bad71 Host: wiki.example.org
Content-Length: 0

# Response
HTTP/1.1 303 See Other
Location: http://wiki.example.org/trails/ColcuckLake

Denetleyici kaynağın mevcut durumunu geri yükler ve denetim amacıyla geri alma isteğini günlüğe kaydeder. Kaynağa yönelik sonraki bir GET isteği geri yüklenen duruma sahip olacaktır.

# Request

GET /trails/ColchuckLake HTTP/1.1 Host: wiki.example.org

# Response
HTTP/1.1 200 OK
Last-Modified: Sun, 01 Nov 2009 16:24:56 GMT
Content-Type: application/atom+xml;type=entry;charset=UTF-8

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

<atom:name>Joe Hiker</atom:name>
</atom:author>
<atom:title>Colchuck Lake</atom:title> <atom:id>urn:example:wiki:trails:ColcuckLake</atom:id>
<atom:link href="http://wiki.example.org/trails/ColchuckLake" rel="self"/> <atom:content xml:lang="en" atom:type="html">

... updated draft ... </atom:content>

</atom:entry>

Yenilemek için bu kodlama örnekler kapsamında detaylandırılıp devam edebilir.


27 Şubat 2022 Pazar

RestFull WebService - Kaynak Taşıma

 

   Kaynağı taşıyabilen bir denetleyiciye bir bağlantı şablonu eklenmesi gerekir. Taşıma isteği göndermek için POST kullanılır. İsteği işledikten sonra yanıt kodu 201 veya 303 sonuca bağlı olarak döndürülür.

Bir hareketin anlamı tamamen uygulamaya özgüdür. Kaynağın aynı veya farklı bir sunucuda farklı bir konuma gönderiliyor ve orjinal siliniyorsa,  yeniden kopyalamak anlamına gelebilir.  Alternatif olarak, bir kayanğın durumunu değiştirmeden değiştirmek anlamına da gelebilir. Bir hareketin ne anlama geldiği ve sunucunun bunu nasıl uyguladığı hakkında ve  her iki durumunda da sabit olmayan bağlantı sürdürmek için müşteri kendi başına işi yapmak için endişelenmemelidir.

Bir fotoğraf albümünü ele alırsak, Albümün bir arkadaşlar klasörünün parçasıdır. Müşteri yaratılan albümü aile albümü klasörüne taşımak isterse Sunucu URI lerini albüm kategorisinde, bu taşıma işlemi albümün URI  inde bir değişikliğe neden olur.

Bir kaynağı taşımak, kopyalamaktan çok farklı değildir. Bu durumda sunucu istemcinin bir hedef için kriter sağlamasına izin vermek için bir URI veya URI  şablonu sağlayan bir kaynak oluşturur.

# Request
GET /albums/friends/2020/08/1011 HTTP/1.1
Host: www.example.org

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

<album xmlns:atom="http://www.w3.org/2005/Atom">
   <id>urn:example:album:1011</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1011"/>
   <link-template rel="http://www.example.org/rels/move"
       href="http://www.example.org/albums/friends/2020/08/1011/move;
                t=dc4128786d463dc7e40c18457d1826fa?group={category}"/>
   <category>friends</category> > Kaynağın kategorisini değiştirmek için URI şablonuna sahip bağlantı..
   ...
</album>

Bu gösterimde sunucu, istemcinin bir kategori belirtmesi ve kaynağın taşınması için bir URI şablonu kullanır.

# Request
POST /albums/friends/2020/08/1011/move;t=dc4128786d463dc7e40c18457d1826fa?
   group=family HTTP/1.1 > Kategoriyi değiştirme talebi

Host: www.example.org
Content-Length: 0

# Response
HTTP/1.1 201 Created
Content-Type: application/xml;charset=UTF-8
Location: http://www.example.org/family/2020/08/1021 > Yeni Kaynak.
Content-Location: http://www.example.org/family/2020/08/1021

<album>
   <id>urn:example:album:1021</id>
   <atom:link rel="self" href="http://www.example.org/family/albums/2020/08/1021"/>
   <category>family</category>
...

Bu isteğin sonucu URI http://www.example.org/albums/ adresinde yeni bir kaynaktır. aile /2020/08/1021

Sunucu, müşteri orjinal albüme erişmeye çalıştığı durumlarda bir 410 veya 4040  döndürebilir.

13 Şubat 2022 Pazar

RestFull WebService - Kaynakların Birleştirilmesi

 

   Kaynakları bileştirmek için uygulamaya özel bir denetleyici kaynak tasarlamak gereklidir. Müşteri alt birleştirilecek kaynakların URI leri veya tanımlayıcıları ile bu URI bir GET isteği uygular, bu işlem için denetleyici sorgu parametleri olarak kullanılır. Sunucu Last-Modified ve ETAG döndürür. Temsilcinin gövdesinde birleştirilecek kaynakların bir özeti ile başlığını içerir. Varlık etiketine bir sıra numarası veya bir zaman damgası rastgele verilir. Özeti doğruladıktan sonra, istemci If-Unmodified-Since ve If-Match bir POST isteğinde bulunur. Birleştirilmeye neden olmak için aynı URI, If-Match başlıkları ile desteklenir.

Birleştirmeden sonra If-Match başlık değeri bir işlem günlüğünden saklar ve URL'in URI içeren bir Konum başlığı ile 201 yanıt kodunu döndürür. Gelecekte bir müşteri aynı If-Match değeri 412 döndürür.

Bir birleştirme sunucuya sunulan iki veya daha fazla kaynağı içerir. Müşterinin iki belgeyi birleştirmenin ayrıntıları sunucuya bırakılmalıdır. Burada müşterinin iki albümü yeni bir albümle birleştirmek için URI alma isteği görünür.

# Request
GET /albums/merge?src=urn%3Aexample%3Aalbum%3A1011&
   dest=urn%3Aexample%3Aalbum%3A1012 HTTP/1.1 > Birleştirilmekte olan kaynakların mevcut durumu alma talebi

Host: www.example.org

# Response
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/xml;charset=UTF-8
Last-Modified: Sun, 08 Nov 2020 04:47:03 GMT > Gösterim için Last-Modified ve ETAG 
ETag: "d88a39e41c314f57917da04c920fd608"

<albums> > Birleştirilen kaynakların durumu
 <album>
    <id>urn:example:album:1011</id>
    <atom:link rel="self" href="http://www.example.org/albums/2020/08/1011"/>
    ...
</album>

<album>
   <id>urn:example:album:1012</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1012"/>
   ...
</album>
</albums>

Bu örnekte, istemci birleştirmek için iki kaynağın tanımlayıcılarını sağlar ve sunucu birleştirilecek kaynakların bir özetini döndürür. Alternatif olarak kullanabileceğiniz birleştirme parametreleri olarak URI lerdir.

 istemci tarafında, önceki yanıttaki albümlerin durumunu müşterinin birleştirme isteği göndermeden önce yerel olarak sahip olduğu ile aynıdır.

# Request
POST /albums/merge?src=urn%3Aexample%3Aalbum%3A1011&
   dest=urn%3Aexample%3Aalbum%3A1012 HTTP/1.1 > kaynak birleştirme isteği

Host: www.example.org
If-Unmodified-Since: Sun, 08 Nov 2020 04:47:03 GMT
If-Match: "d88a39e41c314f57917da04c920fd608" > Önkoşulları

# Response
HTTP/1.1 201 Created
Location: http://www.example.org/albmus/2020/08/1091
Content-Location: http://www.example.org/albmus/2020/08/1091
Content-Type: application/xml;charset=UTF-8
Last-Modified: Sun, 08 Nov 2020 05:30:10 GMT
ETag: "48be3ab269550ee00a84eb5a1a44f330"

<album>
   <id>urn:example:album:1091</id>
   <atom:link rel="self" href="http://www.example.org/albums/2020/08/1091"/>
   ...
</album>

Sunucu, yeni bir birleştirilmiş kaynak oluşturur. Bu işlem sırasında ne olduğuna bağlı olarak sunucunun kullanım durumları talep ederse, sunucu orjinal kaynakları silebilir.

9 Aralık 2021 Perşembe

Müşteriden Koşulsuz GET Talepleri Nasıl Yapılır

  HTTP 1.1 istemcilerin sona erme önbelleğini değiştirmesine ve yeni temsiller istemesine izin verir. Bu tarif bir kaynak aldıktan sonra bir kayanağın yeni bir temsilini almak için kullanabilirsiniz. 412 (Ön Koşul Başarısız ) veya en yenisini almak için başarılı bir PUT veya PATCH den sonra  bile oluşan temsildir. 

GET isteğinde; Cache-Control : non-cache ve Pragma: non-cache üst bilgilerini ekleyin.

İstemcinin bir kaynağı güncellemek için koşullu bir PUT isteğinde bulunduğunu varsayalım.  Katmanlı koşullar eşleşmiyor ve sunucu 412 yi döndürüyorsa.

# 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 2019 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

...

# Response

HTTP/1.1 412 Precondition Failed

Content-Length: 0


Müşteri artık yeni bir temsil almak için koşulsuz  kaynağından bir GET talebinde bulunabilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache> Önbellek kontrolü: önbelleksiz ve Pragma önbelleksiz üstbilgiler, istemci koşullu isteklerini ortadan kaldırır.
Pragma: no-cache

# Response
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2019 05:20:10 GMT
Last-Modified: Sun, 09 Aug 2019 05:20:10 GMT > Sunucu uygulanabilir değiştirilmiş. Last-ETAG
ETag: "a3d3005f4a1632c88e8889af985e6294"
Expires: Sun, 09 Aug 2019 15:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
...


İstekleri non-cache yönergesi herhangi bir ara önbellekten önbelleğe sunmamasını ister. Temsil eder ve isteği kaynak sunucuya iletir.

Bazı önbelleklerin önbellek yok yönergesi sayacak şekilde yapılandırabildiğini unutmayalım. Böyle durumlarda önbellekler bir UYARI başlığı döndürebilir. 

# Request
GET /status HTTP/1.1
Cache-Control: no-cache
Pragma: no-cache
# Response
Date: Sun, 09 Aug 2019 00:56:14 GMT
Last-Modified: Sun, 09 Aug 2019 00:56:14 GMT
Expires: Sun, 09 Aug 2019 10:56:14 GMT
Cache-Control: max-age=36000,public
Content-Type: application/xml; charset=UTF-8
Age: 1021
Warning: 110



Warning başlığının değeri bir tamsayı kodudur ve bu örnekte şunu belirtir. Yanıt eski, bu başlıkla ilgili daha fazla ayrıntı için HTTP 1.1 e göz atmanız gerekir. 

NOT:
Gerekmedikçe koşulsuz GET talepleri yapmayın. Koşulsuz istekler performansı düşürür ve gecikmeyi artırır.


1 Mayıs 2021 Cumartesi

Müşterideki Koşullu GET ve HEAD Taleplerinin Yönetimi

Bir müşteri temsilleri yerel olarak deplolandığında koşullu GET veya HEAD isteklerini kullanabilir. Local depoadaki verilerin devamlı olarak güncel olup olmadığını kontrol etmek şartı ile.

Bir sunucu aynı kaynak için GET ve HEAD isteklerinde bulunurken, bu isteklerin "koşullu" yapmak için aşağıdaki maddelerden yaralanır.
* Deplolanan Last-Modified-Since başlığının değerine sahip If-Modified-Since başlığı 
* Deplolanan ETAG başlığı değerine sahip If-None-Match başlığı

Koşullu isteklerin desteklenmesi, Last-Modified ve ETAG başlıklarının depolanmasını ve daha sonra bunları sunucuya gelecek isteklerle birlikte yeniden kullanmak. Aşağıdaki isteğe göz atalım.

# Request
GET /person/joe HTTP/1.1
Host: www.example.org
# Response
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2009 02:55:46 GMT
Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT
Expires: Sun, 09 Aug 2009 03:55:46 GMT
Cache-Control: max-age=3600,must-revalidate
E-Tag: "3f4a74db207d0447d46710a64971e777"
Content-Type: application/xml; charset=UTF-8
<person xmlns="org:example:people" xmlns:atom="http://www.w3.org/2005/Atom">

   <name>John Doe</name>
   <address>

      <street>1 Main Street</street>
      <city>Seattle</city>
      <atom:link rel="self" href="http://www.example.org/person/john/address"/>
      <state>WA</state>
   </address>
   <atom:link rel="self" href="http://www.example.org/person/john"/>
</person>

Bu istek If-Modified içermediği için koşullu bir istek değildir. If-None-Match den itibaren.

Bu temsili müşterinin ileride kullanması için saklanıyorsa, aşağıdakilerin eklenmesi olasıdır.
Kişinin adı, adresi ve depodaki kaynağın URl ayrıca Last-Modified ve/veya ETAG değerlerini her bir temsilci için aynı deploya dahil edilmesi koşullu isteklerde bulunabilmemiz için kullanılması olasıdır.

Daha sonra sunucunun gösterimi aşağıdaki şekilde değiştirilip  değiştirilmediğini kontrol edebilirsiniz. İstekle birlikte If-Modified-Since ve/veya If-None-Match üstbilgiler ile birlikte.

# Request
GET /person/joe HTTP/1.1
If-Modified-Since: Sun, 09 Aug 2009 00:56:14 GMT
If-None-Match: "3f4a74db207d0447d46710a64971e777"
# Response
HTTP/1.1 304 Not Modified
Date: Sun, 09 Aug 2009 03:10:03 GMT
Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT
Expires: Sun, 09 Aug 2009 04:10:03 GMT
Cache-Control: max-age=3600,must-revalidate
E-Tag: "3f4a74db207d0447d46710a64971e777"

Sunucudan gelen yanıt, müşterinin temsilinin kopyasının hala güncelliğini koruduğu. Bu yanıt aynı zamanda güncellik ömrünü bir saat daha uzatır. Bu şekilde sunucu yanıt döner.

Temsilcinin bir kopyasına sahip değilseniz şartlı talepler göndermeyin.

24 Nisan 2021 Cumartesi

Sunuculardaki Koşullu GET isteklerinin Uygulanması

 


Koşullu GET istekleri sunucuya yanıt gövdesini atlama fırsatı verir. Koşullu istekler, istemcinin If-Modified-Since ve If-Match başlıklarının göndermesini içerir. Önceki bir istekten son Değiştirilen ve ETAG başlıklarına dayalıdır. Koşullu istekler müşteriden gelen isteklerin sayısını azaltmaz ancak kullanımdaki değişikliklerden dolayı azaltılabilir.

Sunucuyu son değşiklik saat ve tarih değerlerini ve/veya varlık etiklerini takip edecek şekilde tasarlanması gerekir. Son değiştirilme tarih ve saatini Last-Modified başlığı olarak ve varlık etiketine ETAG başlığı eklenmeli.

İstemci bir If gönderdiyse istemciden gelen GET ve HEAD isteklerine yanıt verirken None-Match başlığı değerini sunucudaki temsilin ETAG ile karşılaştırın. istemci If-Unmodified-Since gönderdiyse değerini sunucudaki temsil zamanı son değiştirilen ile karşılaştırın.

Kontrollerden herhangi biri yanlışsa veya istemci bu başlıklardan hiçbirini göndermediyse en son yeni ETAG ve/veya Last-Modified head dahil olmak üzere müşteriye sunumun kopyası değilse, istemciye 304(Değiştirilmedi) HTTP durum kodu mesaj olmadan döndürün.

Ön belleğe alınmış bir kopyanın ömrünü uzatmak için koşullu GET isteklerini kullanma sürecine doğrulama deniyor. Bunu desteklemek için sunucunun sona erme başlıklarını birlikte döndürmesi gerekiyor. İstemcilere koşullu üstbilgilerle ve 304 (Değiştirilmedi) önbelleğe alınmış bir yanıtın ömrünü uzatmak için kullanılabilir.

Aşağıdaki verilecek örnekte; müşterinin bir önbelleğe alınmış yanıtı depolamak ve önbelleğin işlenmesini sağlamak için önbellek alma proxy sunucusu otomatik olarak doğrular. Müşterinizin bir kopyasını saklıyorsanız, yerel deposunda bir temsil olup olmadığını kontrol etmek yerel olarak saklanan kopya hala yeni kabul edilir.

Son kullanma tarihi ile birlikte ETAG ve Last-Modified başlıklarını içeren bir gösterim önbelleğe alma başlıklarına örnek;


# Response

HTTP/1.1 200 OK

Date: Sun, 09 Aug 2009 00:56:14 GMT

Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT

Expires: Sun, 09 Aug 2009 01:56:14 GMT

Cache-Control: max-age=3600,must-revalidate

E-Tag: "3f4a74db207d0447d46710a64971e777"

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


Bu örnekteki ETAG başlığının değeri bir varlık etiketidir. iki GET yapılırsa ETAG başlığı için iki farklı değer ister ve alır. Bu temsilcinin yeniden yönlendirmesini değiştirir.

Sunucunun bu örnekteki amacı, bir önbelleğin bir sunucu için depolanan bir temsil sunmasına izin vermektir. Saat sona erdiğinde koşullu bir GET talebinde bulunarak sunumu doğrulamak. Aşağıdaki sıra doğrulama sürecini temsil eder.

# First request

GET /person/joe HTTP/1.1

Host: www.example.org

# First response

HTTP/1.1 200 OK

Date: Sun, 09 Aug 2009 00:44:14 GMT

Last-Modified: Sun, 09 Aug 2009 00:40:14 GMT

Expires: Sun, 09 Aug 2009 01:44:14 GMT

Cache-Control: max-age=3600,must-revalidate


...

# Second request after 10 minutes

GET /person/joe HTTP/1.1

Host: www.example.org

# Second response - returned by cache

HTTP/1.1 200 OK

Date: Sun, 09 Aug 2009 00:54:14 GMT

Last-Modified: Sun, 09 Aug 2009 00:40:14 GMT

Expires: Sun, 09 Aug 2009 01:44:14 GMT

Cache-Control: max-age=3600,must-revalidate

Age: 600


 HTTP/1.1 200 OK > Sunucu tarafından oluşturulan yanıt

Cache-Control: max-age=3600,must-revalidate > Yanıt 3600 saniye önbelleğe alınabilir ancak bu sürenin sonunda yeniden doğrulanması gereken dönem.

Age: 600 > Önbellek tarafından sunulan 600 saniyelik eski bir yanıt.

Bir saatlik sürenin dolmasından sonra istemciler tarafından yapılan istekler önbelleğin önbelleğe alınmış yanıtını gösterir.


# Third request after an hour

GET /person/joe HTTP/1.1

Host: www.example.org

# Request sent by the cache to the origin server
GET /person/joe HTTP/1.1
Host: www.example.org
If-Modified-Since: Sun, 09 Aug 2009 00:40:14 GMT
If-None-Match: "3f4a74db207d0447d46710a64971e777"

# Response generated by the server
HTTP/1.1 304 Not Modified
Date: Sun, 09 Aug 2009 01:54:14 GMT
Last-Modified: Sun, 09 Aug 2009 00:56:14 GMT
Expires: Sun, 09 Aug 2009 02:54:14 GMT
Cache-Control: max-age=3600,must-revalidate
E-Tag: "3f4a74db207d0447d46710a64971e777"
Content-Type: application/xml; charset=UTF-8

# Response returned by the cache
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2009 00:54:14 GMT
Last-Modified: Sun, 09 Aug 2009 00:40:14 GMT
Expires: Sun, 09 Aug 2009 01:44:14 GMT
Cache-Control: max-age=3600,must-revalidate

# Third request after an hour 

GET /person/joe HTTP/1.1 > Son kullanma tarihinden sonra müşteri talebi


# Request sent by the cache to the origin server

GET /person/joe HTTP/1.1 > Önbelleğe alınan yanıtı doğrulama isteği


HTTP/1.1 304 Not Modified> Kaynak sunucunun yanıtının değiştirilmediğini belirten yanıt parçası.


HTTP/1.1 200 OK> Önbelleğe alınmış bir  kopyayı içeren istemciye önbellek tarafından verilen yanıt.

Yanıt süresi dolmadığından sunucu ikinci isteği görmez ve önbelleğin hala bir kopyası mevcut. Üçüncü istek, doğrulama içi sunucuya ulaşır.  Üçüncü sunucunun yanıtı temsilin değişmediğini bildiriyor ve bir saate daha ömrünün olduğunu belirtiyor.

Bu örnekte, sunucunun sorumluluğu şu değerleri karşılaştırmaktır.

If-Modified-Since ve/veya If-None-Match başlıkları mevcut, değerleri ise bir kaynak gösterimi ile 200 (OK) veya 304 (Not Modified)


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 Şubat 2021 Cumartesi

İstemcilerin Kimlik Doğrulamasında Temel Kimlik Doğrulama Kullanımı

 

  İstemcide, müşteri tanımlayıcısının birleştirilmesi kullanıcı adı ve paylaşılan şifre <identifier>:<secret> ardından bu metinin Base64 kodlamasını dahil etmeniz gerekir. İstemci isteklerinde bir metin başlığı ortaya çıkaran metin değeri : Authorization: Basic <Base64 encoded value>

Sunucuda metnin kodunu çözün ve şifrenin aynı olduğunu doğrulayın. İstemci sunucunun bir kaynak için temel kimlik doğrulaması gerektiğini önceden biliyorsa her istek geldiğinde yetkilendirme üst bilgisi içerilebilir. 401 alınması önlenebilir.

iki kişi için temel ve özet kimlik doğrulama gibi kimlik doğrulama şemaları kullanılabilir.

Senaryolar: Bir müşteri korunan bir kaynağa kendi adına eriştiğinde ve bir müşteri bir kullanıcı adına korumalı bir kaynağa erişiyorsa.

İstemcide güvenli bir şekilde saklanmadıkça hiç bir sır gerçekte güvenli değildir.


Temel kimlik doğrulama; HTTP 1.0'a kadar uzanır ve daha sonra RFC 2617 tarafından belirtilir. Temel kimlik doğrulamasında istemci Base 64 paylaşılan şifre kodlar ve bunu Yetkilendirme isteği başlığı ile destekler.

Base64 kodlaması tersine çevrilebilir. Aşağıdaki durumlarda temel kimlik doğrulaması kullanmayın. Sunucuya bağlanmak için TLS kullanmaz.


Aşağıdaki kodda bir kaynağa erişmeye çalışan bir istemcinin ilk isteğine yer verilmiş.


# Request

GET /photos HTTP/1.1

Host: www.example.org


# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App"

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


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

   <message>Unauthorized.</message>

</error>

# Request
GET /photos HTTP/1.1 > Kimlik bilgileri olmayan bir istek

# Response

401 Unauthorized

WWW-Authenticate: Basic realm="Photos App" > Temel kimlik doğrulaması kullanarak kimlik bilgilerini sağlamayı zorlayan yanıt.

Kaynak korunduğundan, sunucu istemcinin kimlik bilgilerini sağlamasını ister. Basic adlı bir kimlik doğrulama şeması kullanarak, gerçek değeri opak dizedir. Sunucuda korunan bir alanı tanımlar.

İstemcinin / kullanıcının paylaşılan gizli değeri ile photoapp.001 olarak tanımlandığını varsaydığımızda basicauth. istemci photoapp.001. dizesinin Base64 kodlamasını hesaplar.  Cauth ve Yetkilendirme başlığıyla aşağıdaki isteği gönderir.

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==

# Response

HTTP/1.1 200 OK

Content-Type: application/xml;charset-UTF8

Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA== > Sunucu kimlik bilgilerini Base64 kullanarak çözer yöneticinin, istemcinin kattığı sunucu tarafından bilinenle eşleşir ve istemciye izin verilir. Sunucu alınan istekte bir istek daha alırsa yada yetkilendirme başlığı yoksa veya sağlanan yetkilendirme başlığındaki bilgiler ile eşleşmiyorsa sunucu WWW-Authentication hatasını döndürür.

Kimliği doğrulanmış yanıtlar hassas bilgiler içerdiğinden Cache-Control ve Expires üst bilgileri yanıtı için uygundur.
Örneğin; Yanıt istemciye özeldir, paylaşmayı önlemek için Cache-Control :private kullanın. Yanıtı saklamaktan veya diğer istemcilere sunmakta için gelen önbelleklerde kullanılır.

# Request
GET /users/admin HTTP/1.1
Host: www.example.org
Authorization: Basic cGhvdG9hcHAuMDAxOmJhc2ljYXV0aA==
# Response
HTTP/1.1 200 OK
Cache-Control: max-age:3600,private
Vary: Authorization
Content-Type: application/xml;charset-UTF8

Yetkilendirme Başlığını Genişletme

Özet Kimlik Doğrulaması ve OAuth kimlik bilgilerini sunucuya göndermek için bu başlık kullanılır. Örneği Amazonun Basit Deploma Hizmeti (s3)bu başlığı kullanarak istemciler aşağıdaki istek başlığı kullanarak sunucuya kimlik doğrulaması yapar.

Authorization: AWS AWSAccessKeyId:Signature

Burada AWS Amazon tarafından kullanılan kimlik doğrulama şeması için tanımlayıcıdır.  Amazon aynı verilerin imzasını hesaplayarak istemcinin kimliğini doğrular.


7 Şubat 2021 Pazar

İstemcilerin Kimlik Doğrulamasında Özet Kimlik Doğrulama

 Temel kimlik doğrulamaya benzer istemcinin kimlik bilgilerinin özetini sunucuya göndermesi dışında yeniden kimlik gönderim saldırılarını önlemek için mekanizmaları sağlar.

İstemci erişim için bir Yetkilendirme başlığı eklemeden bir istek gönderdiğinde korumalı kaynak dönüş kodu olarak 401 ile birlikte özet kimlik doğrulama şemasında bilgiler alır. Bu bilgiler bir kez yada sınırlı sayıda alınabilen bilgilerdir.

Sağlanan özetin içerisinde depolanan kimlik bilgilerinin bir özetiyle eşleştiğini doğruladıktan sonra Authentication-Info başlığı ekleyin. Bu bilgi sunucu tarafında eşdeğerdir.

İstemciler genel olarak özeti hesaplamak için MD5 kullanır. Temel kimlik doğrulamasından farklı olarak bu teknik şifrelenmemiş bir paylaşılan sırrı değiş tokuş etmez.


# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

         qop="auth"

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

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

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1

Host: www.example.org

Authorization: Digest username="photoapp.001", realm="Sample app",

nonce="6cf093043215da528d7b5039ed4694d3",
         uri="/photos", response="89fba5bf5e5f9dd69865258c21860956",
         cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"
# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset-UTF8

GET /photos HTTP/1.1   > kimlik bilgisi olmayan bir istek;

# Response

401 Unauthorized

WWW-Authenticate: Digest realm="Sample app", nonce="6cf093043215da528d7b5039ed4694d3",

qop="auth" > nonce içeren yanıt

cnonce="c019e396409afe784ae9f203b8dfdf7e", nc=00000001, qop="auth"  > Yanıt yönergesi içeren istek.

Temel kimlik doğrulamasından farklı olarak özet kimlik doğrulaması, istemcinin bir özet sağlaması gerekir.

realm : Sunucudaki korumalı alanı tanımlayan opak bir dize.

nonce: Her 401 Yetkisiz yanıtıyla benzersiz şekilde oluşturulan dize. Bir özet oluştururken bu değeri kullanmaları gerekir. Yeniden isteklerde kullanılan bazı değerlerden daha eski nonce yönergeleri kullanarak yapılan saldırıları içerir.

qop: Özet kimlik doğrulaması yönergeler için iki değer belirtir. Aut ve Auth-int. 

Auth:  Sunucunun istemci kimlik doğrulaması için özet kimlik doğrulaması kullandığını belirtir.

Auth-int: Sunucunun bu kimlik doğrulamasını aynı zamanda isteklerin bütünlüğü Qop = auth-int istemcilerin isteğinin gövdesine özeti hesaplarken ekler. 

*İstemci / Kullanıcı tanımlayıcısının, alanı ve paylaşılan gizli değer aşağıdaki şekilde birleştirin.  MD5 değerini hesaplayın. Değeri : A1 dir.
<identifier>:<realm>:<secret>

*İstek Yönetimini ve istek URL sini <method>:<URI> MD5 ekleyin. Sonucunun A2 olduğunu söyleyin.

*A1, nonce ve A2 yi <A1>:<nonce>:<A2> olarak birleştirin ve MD5 değerini hesaplayın.

Kullanıcı elde edilen değeri yanıt değeri olarak kullanır.

Nonce kullanımında; Sunucular tek seferlik veya sınırlı kullanımlı bir belirteç kullanarak saldırıların yeniden tekrarlanma olasılığını sınırlayabilir.

Tek seferlik veya sınırlı kullanılan biletler, requestlerde sunucunun kullanılan tüm belirteçlerinin günlüğünün tutulması gerekir.

WWW-Autheticate başlığı ayrıca domanin, opaque gibi diğer direktifleri içerebilir.