Sunucular Arasındaki İşlemler

 

   Bu tarif sunucu sınırlarını aşan işlemler üzerine yazılmış bir makaledir. Örneklerde bir kullanıcı profilini bir uygulamadan diğerine geçmeyi bekleyen tekliflerin özetlerini bir müşteri ilişkileri yönetimi uygulamasına içe aktarmayı veya halihazırda taslak sunucusunda bulunan üretim sunucusunda bir belge yayınlamayı içeriyor.  Bu tür kullanım durumları birden çok sunucuda durum manipülasyonuna  ihtiyaç duyar.

Sunucular arası işlemleri tasarlamak ve uygulamak için sunucuların birbirleriye işbirliği yapılmasına izin verin. Bu sunucuların veri formatları arka uç arayüzleri ve eşzamanlılık kontrolü üzerinde anlaşmaların yanı sıra bir veri deposunda veri yüklemeyi diğer sunucunun formatına uyacak şeklide normalleştirmeyi ve ardından depolamayı içerebilir. Sunuculardan birinin işlemi tetiklemek için istemcilere bir bağlantı sağlamasına izin verin. 

Sunucu sınırlarını aşan işlemlerle karşılaşıldığında endişelerin ayrılması kilit bir endişe olmalıdır. iki Web hizmetini düşünürsek biri kullanıcıların bağlantılarını yönetiyor. http://contacts.example1.org üzerinde çalışır ve e-posta, metin mesajları, sesli posta v.b gibi diğer yönetim mesajlaşmaları ise http://messaging.example2.org üzerinde çalışır.  Kullanım durumu, bir kullanıcının kişilerini mesajlaşma web hizmetine aktarılmasına izin vermektedir. Bunu desteklemek için kişiler web hizmetinin, kişileri mesajlaşma web hizmet aktarmak için bir bağlantı içerdiğini varsayın. Kişi listesini mesajlaşma web hizmetine aktarmak için bir bağlantıyla birlikte bir kullanıcının kişi listesinin temsili buradadır.

# 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>

Verileri bir sunucudan diğerine aktarmak için URI ile bağlantı kurun. http://contacts.example2.org/rels/export-to-messaging ilişki türüyle bağlantının anlamını anlayan bir istemci, dışa aktarma işlemini başlatabilir. Bu bağlantı ilişki türünün belgelerinin, istemcinin, kişileri mesaj hizmetine aktarmak için bağlantının URI'sine bir POST isteği göndermesi gerektiğini söylediğini varsayalım. Bağlantının URI yetkisiz kullanım önlemek için bir güvenlik belirteci 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

#Request : Verileri dışarıya aktarma isteği 

Dışa aktarma sonuçlarını sağlaya URI istemci bu isteği gönderdiğinde mesajlaşma hizmeti kişilerin bir kopyasını almak için kişiler web hizmetine bir arka uç isteğinde bulunur. Bu işlem sırasında sunucular arasında güvenliğin nasıl yönetildiğine bağlı olarak mesajlaşma web hizmeti URI bulunan belirteci kişiler web hizmetine sunabilir. Bu süreçte kişi listesi verilerinin mesaj sunucusunda kullanılabilir olmasını sağlamaktan sunucular sorumludur.  İstemci yalnızca işlemi tetiklemekten sorumludur. Bu istemcinin eşzamanlılık kontrolü, atomsallık, veri formatlarındaki farklılık v.b dahil olmak üzere sunucunun uygulama ayrıntılarından ayrılmasını sağlar. Bu sunucular arasındaki koordinasyonun sonucudur. 

NOT:

Teknik ve organizasyonel sorunlar nedeniyle böyle bir koordinasyon mümkün olmadığında müşterinin tüm kişileri http://contacts.example2.org/user/contacts adresinden indirilip mesajlaşma servisine gönderilmesinden başka bir seçenek yoktur.

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.

POST isteklerini Koşullu Yapma

PUT veya DELETE den farklı olarak yapılan bir kaynağa gönderilen POST isteğinin sonucu, herhangi bir istek URI deki kaynağa yapılan değişiklikler sunucuda yeni bir kaynak oluşturabilir. Yanıt kodu 201 veya sonucu farklı bir URI ile tanımlanayabilirsiniz. Yanıt kodu 303. Bu durumda müşterinin bir temsili olmayacak ve şartlı yerel olarak depolanan üstbilgiler dahil. Bu tür POST isteklerini yapmak için bağlantıların nasıl kullanılacağını gösterir. POST  istekleri koşullu veya yanıtsız hale getirmek için bu tarifi uygulayabiliriz. 

Müşteri tarafından sunulması için POST u sunucunun yinelemeleri algılayabileceği ve önleyebileceği şekilde uygulamak istiyoruz.

İstemcilerin her POST isteği için bir bağlantı aracılığıyla sunucu tarafından sağlanan tek seferlik bir URI oluşturmak için  bir jeton içerir. POST isteğinin yalnızca bir kullanım için geçerli olan sunucu. Kullanılan tüm jetonları bir sunucu işlem günlüğünde saklanır. 

İstemci bir POST isteği gönderdiğinde jetonun işlemde mevcut olup olmadığını doğrulayın. Varsa yanıt kodu 403 döndürün. Neden bodyde olduğunu açıklayın. Eğer mevcut değilse dönme isteğine 201 oluşturun yada 303 ile bağlı olarak işlemi sonuçlandırın. Ayrıca belirteci işlem günlüğünde saklayın.

Sunucunun belirli bir miktar transfer etmesi gereken banka havalesi uygulaması olduğunu düşünelim.  Bir hesaptan diğer bir hesaba para aktarımı. Sunucu bir denetleyici kaynağı kullanarak bu transferi uygulayın.

# Request

POST /transfers> İki banka hesabının kaynağına müşteri mevcut durum olduğunu düşündüğü şeye dayanarak bir POST isteği gönderir. 

Host: example.org

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

<transfer>

   <source>urn:example:org:account:1</source>

<target>urn:example:org:account:2</target>

<currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 201 Created> Sunucu istemcinin isteğini şuanki duruma dayanıp dayanmadığını hesap kaynalarına göre doğurlayamıyor.

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

Location: http://www.example.org/transactions/1

Content-Location: http://www.example.org/transactions/1

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

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <atom:link href="http://www.example.org/transactions/1" rel="self"/>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

Bu örnekte; http://www.example.org/trans tarafından tanımlanan kaynak ters bir denetçi kaynağıdır. Bu örnekteki POST isteğinin sonucu şu şekildedir. iki hesap kaynağının değiştirilmesi ve  yeni bir kaynağın oluşturulaması. Bunu yapmak için istek koşulu olarak; sunucu değerin bir işlev olarak belirteç kullanması gerekir. iki hesap kaynağının mevcut durumu bulabilmek için.  Sunucu aşağıdaki yaratılan URI kullanabilir.

http://www.example.org/transfers;t=e6e3c89d4dfe7f3a818734a6237ccfc5

Değiştirilmesi istenen iki kaynaktan; http://www.example.org/transfers  aksine bu URI bir işlev olarak bir belirteç içerir.  İstemci bir aktarım talebinde bulunmak için URI kullanabilir. Sunucu, URI deki belirtecin hala şuanki duruma karşılıl geldiğini doğrulayabilir. Bir hesap aktarımı oluşturmaya devam etmeden önce hesap kaynaklarını doğrulamak gerekir.

# Request

POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci geçerli veriyi temel alan bir URI ile koşullu bir POST isteği gönderir. Ancak bu gönderim sadece iki banka hesabı kaynağı olduğu sürece.

Host: example.org

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

<transfer>

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 201 Created > Sunucu, istemcinin isteğinin şuanki durumuna dayanıp dayanmadığının kontrolünü yapması ve hesap kaynaklarınında kontrolünün yapması sonrasında.

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

Location: http://www.example.org/transactions/1

Content-Location: http://www.example.org/transactions/1

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

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <atom:link href="http://www.example.org/transactions/1" rel="self"/>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

Sunucudaki, jetonun sunucunun işlem günlüğü.

# Request

POST /transfer;t=e6e3c89d4dfe7f3a818734a6237ccfc5 HTTP/1.1 > İstemci koşullu bir POST isteği gönderir.

Host: example.org

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

<transfer>

   <source>urn:example:org:account:1</source>

   <target>urn:example:org:account:2</target>

   <currency>USD</currency>

   <amount>100.00</amount>

   <note>Testing transfer</note>

</transfer>

# Response

HTTP/1.1 403 Forbidden > Sunucu bir çakışma algıdı.

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

Date: Sat, 17 Oct 2019 20:16:18 GMT

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

   <message xml:lang="en">Transfer already created.</message>

</error>

Bu sefer, sunucu, belirtecin önceden kaydedilmiş olup olmadığını görmek için işlem günlüğünü kontrol eder. Kullanılmış kopya oluşturmak yerine 403 döndürür. Bu teknikte POST tam olarak bir  kez çağrıldı.

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.

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. 

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.

İ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.

İ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.