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.

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.

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.

Tek Seferlik URI Nasıl Oluşturulur

 

  URI amaçı yeni bir kaynak oluşturmaksa aşağıdakilerden birine dayalı bir belirteç oluşturmamız gerekir. 

Bir sıra numarası veya bir zaman damgası ile rastgele bir sayının birleşimi ile. Bir veya birden fazla kaynağı değiştirmek amaç ise ayrıca varlık etiketlerini ve jetondaki bu kaynak tanımlayıcılar ile birlikte URI kodlamalıyız.

Banka hesabı transfer örneğinde; Transferde bulunmak için sunucunun iki bankanın hesaplarında mevcut durumunun bir işlevi olan URI sağlaması gerekir. Böyle bir URI oluşturabilen kaynak;

# Request

GET /transfer-token?from=urn:example:org:account:1&

   to=urn:example:org:account:2 HTTP/1.1 > Koşullu bir istekte bulunmak için bir URI alma isteği;

Host: www.example.org

# Response

HTTP/1.1 200 OK

Cache-Control: no-cache

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

      rel="http://www.example.org/rel/transfer" > Koşullu URI

<accounts>> Kaynakların mevcut durumu..

   <account>

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

      <balance>200.00</balance>

   </account>

   <account>

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

      <balance>100.00</balance>

   </account>

</accounts

İstekteki kaynaklar jeton dağıtma makinesi gibidir. Müşteri aktarıma dahil olan hesaplar ve sunucular, Transferi başlatmak için URI ile bir bağlantı döndürür. Sunucu ayrıca hesapların mevcut durumunuda içerir.

Müşteri bağlantıyı kullanma kararını geri gönderilen alana dayandırmalıdır. Bu bağlantı yanlızca hesabın mevcut durumu için geçerli  kaynaktır.

Böyle bir URI oluşturmanın bir kaç yolu vardır. Aşağıdaki URI jeton içerir değeri ise rastgele bir sayının birleştirilmesinin bir MD5 karması olan geçerli tarih- iki banka hesabının zaman değeri ve varlık etiketleri:

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

URI kurcalanmasının önlenmesi için URI dijital imzalarıda dahil etmeyin düşünebilirsiniz. Sunucunun daha sonra doğrulama için bu belirteci depolaması gerekmez. Çünkü kaynakların mevcut varlık etikletlerinden jetondan karmalar uyuşmuyorsa sunucu istemci tarafından kullanılan URI artık geçerli olmadığı sonucuna varabilir. Böyle biri zaman belirteçlerine nonce denir. Nonce bir kez kullanılan sayı anlamına gelir.

Yeniden oynatma saldırılarını tespit etmek için tek seferlik URI kullanabilirsiniz. Tekrar saldırıları kötü niyetli bir varlığın isteklerini yakalamak için gizlice dinlenmesi ve yeniden bir gerçek müşteri gibi görünen sponsorlar ve tekrar istekleridir.

Bu tür amaçlar için tek seferlik URI ler kullanırken belirtecin kötü niyetli varlığın tahmin edilmemesi için gelecekteki simge değerleri rastgele oluşturulur.

URI amacı POST kullanarak yeni bir kaynak oluşturmaksa, jetonu oluşturun tarih ve saat değerine ve rastgele bir sayıya dayandırın. Tek seferlik URI yeni bir adres kaynağı oluşturmak için verilebilir. Bu URI deki belirteç bir MD5 karmasıdır. Bu ise rastgele bir sayı ve geçerli saat içerir.

# Request

GET /user/smith/address-token HTTP/1.1 > Bir kaynak oluşturmak için koşullu istekte bulunmak üzere URI alma isteği

Host: www.example.org

# Response

HTTP/1.1 204 No Content

Cache-Control: no-cache

Link: <http://www.example.org/user/smith;t=360e22a55267f0a525b1d49ddc9eed71>;

rel="http://www.example.org/rel/transfer" > Koşullu URI

Bu durumda URI sağlamak için herhangi bir girdi sağlamaya gerek yoktur. Bunu doğrulamak için URI daha önceden kullanılmamışsa sunucunun bir işlem günlüğünde tutması gerekir. Ne zaman istemci POST kullanarak URI oluşturmak için gönderir, öncesinde belirteç sunucudaki bir işlem günlüğünde mevcuttur. Değilse, isteği işleyin.

Web Uygulamaları söz konusu olduğunda belirteci gizli olarak da kodlayabilirisiniz. HTML formlarındaki form alanlarında. 

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

Üç Aşamalı OAuth Kullanımı

 3 aşamalı denmesinin nedeni ise Servis sağlayıcı (sunucu), OAuth tüketicisi (müşteri), Kullanıcı bulunur.

Protokolün başlangıcında; Sunucu tarafında müşteri için bir tanımlayıcı olarak "tüketici anahtarı" ve paylaşılan gizli "tüketici sırrı" kullanılır. Bir kullanıcı istemciye kaynaklara erişim yetkisi verdiğinde, sunucu bir tanımlayıcı olarak erişim token yetkili olan istemciyle gizli olarak paylaşır.

OAuth sunucu tarafında istemciye verilen 3 token sırrına dayanır.

Tüketici anahtarı ve tüketici sırrı:

Tüketici anahtarı  müşteri için benzersiz bir tanımlayıcıdır. Müşteri gizli istek belirteçleri alma taleplerini imzalamak için tüketiciyi kullanır.

Token ve Token Sırrı:

Token isteği sunucu tarafında bir defa olarak geçici tanımlayıcıdır. Kullanıcıdan istemciye izin vermesini istemenin amacıdır.

Token Sırrı; erişim belirteci alma taleplerini imzalamak için kullanılır.

Giriş Tokeni ve Token Sırrı:

Giriş Tokeni: İstemcinin kullanıcının kaynaklarına erişmek için kullanacağı tanımlayıcıdır. Giriş tokenine sahip bir müşteri kullanıcının kaynaklarına erişir. Sunucu süresinin dolması nedeniyle istediği zaman  erişimi iptal edebilir.

Token Sırrı; erişim isteklerinin imzalanmasında kullanılır. Kullanıcının kaynaklarının korunması sebebi ile kullanılır.

OAuth yönetiminin kullanılması aşağıdaki adımları içerir. Bu akışın amacı; bir token ve token anahtarı elde edilmesi, Sunucu için bir giriş belirteci yaratılması, zaman dilimi ile belirli kullanıcı kaynaklarına erişim sınırlaması.

1- İstemci, sunucudan bir tüketici anahtarı ve token sırrı ister.

2- Müşteri bir talep belirteci ve token sırrı almak için tüketici anahtarını kullanır. 

3-İstemci, erişime izin verebilmek için kullanıcıyı sunucuya yönlendirir. Bu işlem kimliği doğrulanmış bir istek belirteci ile sonuçlanır.

4- İstmeci, sunucudan bir erişim belirteci ve sır vermesini ister, Müşterinin kaynaklara erişmek için kullanabileceği bir tanımlayıcı ve token sırrı olarak temsil edilir.

5- İstemci, korumalı bir kaynağa erişim talebinde bulunurken; bir yetkilendirme sorgulama parametreleri tüketici anahtarını, giriş belirteci , imza yöntemi, imza, zaman damgası, tek seferlik isteği bağlı olarak OAuth protokolü sürümü.

OAuth, HTTP üzerine yerleştirilmiş bir protokol olduğundan sunucuların istemcilere aşağıdaki URI;

* İstek belirteci almak için URI;

* Sunucu yetkilendirme için URI;

* Erişim belirteci almak için URI;

OAuth, istek ve erişim belirteçlerini almak için POST kullanması önerir.

Fotograf albümü veren bir web hizmetinde; Müşterinin ihtiyacı olan kullanıcı fotograf albümü kaynağının bir kopyasını oluşturabilmesi için yetkilendirme söz konusudur. İstemci bir oauth_consumer_key ve gizli anahtar almak için sunucuya gider. Örneğin sunucu istemciler için bir web sayfası sağlayabilir. Tüketici tarafından oluşan anahtar ve gizli token için.  Tüketici anahtarı : a1191fd420e0164c2f9aeac32ed35d23 ve gizli token : fd9b9d0f769c3bcc548496e4b5077da79c02d7be.

İstemcinin 3 adımlı protokolü başlatması için Sunucu; aşağıdaki URI;

* İstek belirteçlerini almak için https://www.example.org/oauth/request_token

* Kullanıcı yetkilendirmesi almak için https://www.example.org/oauth/authorize

* Erişim belirteci almak için https://www.example.org/oauth/access_token

Not: Yanıtlar paylaşılan dizi içerdiğinden TLS kullanın, kullanıcı yetkilendirmesi ve shared secret;

İstekler aşağıdaki parametleri içerir. 

oauth_consumer_key: Sunucu tarafından her istemciye verilen benzersiz bir tanımlayıcıdır.

oauth_signature_method : İmza hesaplanırken kullanılan imzalama yöntemidir. OAuth, HMAC tanımlar. İmzalana yöntemleri olarak; SHA1 ve RSA-SHA1. İstemci ve sunucular arasından TLS kullanıldığından imzalardan kaçınabilirsiniz ve bu parametrenin değierini PLAINTEXT kullanabilirsiniz.

oauth_timestamp : January 1, 1970, 00:00:00 GMT. itibaren geçen saniye sayısına eşittir.

oauth_nonce : Belirli bir zamanda gönderilen tüm istekler için benzersiz rastgele dizedir.

oauth_timestamp: Sunucuların yeniden ataklara karşı korunmasında yardımcı olur. Benzersiz özet kimlik doğrulaması gibi. OAuth istemcikerin nonce değeri oluşturması gerekir.

oauth_version: OAuth sürümüdür.

İstemci ilk adım olarak istek belirteci ve bir secret key almak için bir istek gönderir. Sunucu bu talepde yer alan imza , tüketici gizli anahtarına dayanmaktadır. Müşteri tüketici anahtarı ile birlikte elde edilir. İmza aşağıdakilerini içerir.

oauth_consumer_key, oauth_signature_method, oauth_timestamp, oauth_nonce, ve oauth_version

1- Parametreleri Toplayın;

oauth_consumer_key,

oauth_timestamp, oauth_nonce, and oauth_version.

2-Parametleri yüzde olarak kodlayın önce adlarına göre sonra değerlerine göre;

3-Hazırlanan parametreleri bir dizeye yerleştirin. Örnek;

oauth_con

sumer_key=a1191fd420e0164c2f9aeac32ed35d23&oauth_nonce=109843dea839120a&oa

uth_signature_method=HMAC-SHA1&oauth_timestamp=1258308730&oauth_ver

sion=1.0.

4- Paylaşılan token anahtarı kullanarak bir imza hesaplama: Örnek;

d8e19bb988110380a72f6ca33b2ba5903272fe1.

5-İmzayı Base64 olarak kodlayın ve ardından elde edilen metni yüzde olarak kodlayın.

 İmzayı kullanan tüketici bir talep belirteci almak için bir talep gönderir.

Örnek;

# Request to obtain a request token

POST /request_token HTTP/1.1

Host: www.example.org

Authorization: OAuth realm="http://www.example.com/photos",

oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

oauth_nonce=109843dea839120a,

oauth_signature=d8e19bb988110380a72f6ca33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308730,

oauth_version=1.0

# Response containing a request token and a secret

HTTP/1.1 200 OK

Content-Type: application/x-www-form-urlencoded

oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c

&oauth_token_secret=394bc633d4c93f79aa0539fd554937760f05987c

POST /request_token HTTP/1.1 > İstek belirteci ve sırrı alma talebi

oauth_nonce=109843dea839120a,

oauth_signature=d8e19bb988110380a72f6ca33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308730,

oauth_version=1.0 > istemcinin kimliğini doğrulamak için yetkilendirme başlığı

oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c

&oauth_token_secret=394bc633d4c93f79aa0539fd554937760f05987c 

> Bir istek belirteci ve sırrı içeren yanıt.

oauth_token yanıt istemcinin bunu yapmak için kullanması gereken bir istek belirtecidir. İstemci kullanıcıyı sunucudaki bir kaynağı ziyaret etmeye ve yetki vermeye yönlendirir.

Yetki Alma Talebi:

# Request to obtain authorization

GET /oauth/authorize?oauth_token=0e713d524f290676de8aff4073b1bb52e37f065c HTTP/1.1

Host: www.example.org

Bu kaynağın uygulanması sunucuya bağlıdır. Bu noktada sunucu kullanıcının sunucuya kimlik doğrulama yapıp yapmadığını kontrol etmemiz gerekir. 

İstemci bir erişim belirteci almak için doğrulama kodu kullanır. Bunun içerisindeki imza isteği; 

oauth_signature_method, oauth_timestamp, oauth_nonce, and oauth_version

# Request to obtain an access token

POST /access_token HTTP/1.1

Host: www.example.org

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

                               oauth_token="ad0d1c7a765c9e6e8b14e639c763177312d18e7e",

                               oauth_verifier="988786765423",

                               oauth_signature_method="RSA-SHA1",

                              oauth_signature="698d58fd3316304181e11c6eb8127ffea7e2df46",

                               oauth_timestamp="1258328458",

                               oauth_nonce="109843dea839120a",

oauth_version="1.0"

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: application/x-www-form-urlencoded

oauth_token=8d743f1165c7030177040ec70f16df8bc6f415c7

&oauth_token_secret=95aec3132c167ec2df818770dfbdbd0a8b2e105e

POST /access_token HTTP/1.1 > Erişim belirteci ve secret key alma isteği

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

oauth_token="ad0d1c7a765c9e6e8b14e639c763177312d18e7e",

oauth_verifier="988786765423",

oauth_signature_method="RSA-SHA1",

oauth_signature="698d58fd3316304181e11c6eb8127ffea7e2df46",

oauth_timestamp="1258328458",

oauth_nonce="109843dea839120a",

oauth_version="1.0"

> İstemcinin kimliğini doğrulamak için yetkilendirme başlığı

oauth_token=8d743f1165c7030177040ec70f16df8bc6f415c7

&oauth_token_secret=95aec3132c167ec2df818770dfbdbd0a8b2e105e

 > Erişim token ve secret key içeriği

Bu yanıt erişim belirteci  ve secret token anahtarı içerir. Sunucunun istek belirteci için bir erişim belirteci vermeden önce tüketici anahtarı ile eşleşmesini sağlar.

İstemci isteklerle bir Yetkilendirme başlığı oluşturmak için kullanıcı için korumalı kaynaklara erişim için; 

oauth_consumer_key, access token, oauth_signature_method, oauth_timestamp,

oauth_nonce, and oauth_version değerlerini kullanır. İstek ortam türü olduğunda istek  gövdesine application/x-www-form-urlencoded kullanır.

# Request

POST /albums/2009/08/1011/duplicate;t=a5d0e32ddff373df1b3351e53fc6ffb1 HTTP/1.1

Host: www.example.org

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

                               oauth_token="827fa00c6f15db4063378bb988e1563e0c318dbc",

                               oauth_signature_method="RSA-SHA1",

                               oauth_signature="f863cceebb4f1fe60739b125128e7355dcbf14ea",

                               oauth_timestamp="1258328889",

                               oauth_nonce="3c93e7fdd1101e515997abf84116ef579dccce1a",

oauth_version="1.0"

POST /albums/2009/08/1011/duplicate;t=a5d0e32ddff373df1b3351e53fc6ffb1 HTTP/1.1

> Korumalı bir kaynağa erişim isteği;

Authorization: OAuth oauth_consumer_key="a1191fd420e0164c2f9aeac32ed35d23",

oauth_token="827fa00c6f15db4063378bb988e1563e0c318dbc",

oauth_signature_method="RSA-SHA1",

oauth_signature="f863cceebb4f1fe60739b125128e7355dcbf14ea",

oauth_timestamp="1258328889",

oauth_nonce="3c93e7fdd1101e515997abf84116ef579dccce1a",

oauth_version="1.0"

 > Erişim token ve erişim secret key içeren bir Yetkilendirme başlığı içeren istek;

Akış karmaşık gibi görünse de istemcilerin kullanıcının verilerine erişmesine izin verecek şekilde tasarlanmıştır. Kullanıcı adı ve şifre bilgisini sormadan, kullanıcı sunucudan herhangi bir istemcinin iznini iptal etmesini isteyebilir.

İki Aşamalı OAuth

  İki aşamalı OAuth kimlik bilgilerini sunucuya şu yollarla sağlanan istemciye benzer. Yetkilendirme dahil olmadan temel veya özet kimlik doğrulamasını kullanan yetkilendirme başlığı ile.

OAuth spesifikasyonu bu kimlik doğrulama stilini belirtmediğini ancak sunucuya bir istemcinin kimlik doğrulamak için yaygın olarak kullanılır.

iki aşamalı OAuth aşağıdaki adımları içerir.

1-İstemci sunucudan bir anahtar ve  dışarıdan bir gizli anahtar ister. Anahtar müşteri için bir tanımlayıcıdır. Gizli anahtar ise; istemci ve sunucu arasında paylaşılan bir gizli anahtardır.

2-İstemci korunan bir kaynağa erişim talebinde bulunurken anahtar ve imzalama yönetimi ve işareti içeren yetkilendirme başlığına nature, timestamp, nonce isteğe bağlı olarak OAuth protokol sürümünü ekler.

Sunucu kaynağa erişim izni vermeden önce imzayı doğrular. Bu yaklaşım kimlik doğrulama akışında yalnızca iki taraf olduğu için iki ayaklı olarak adlandırılır. Sunucu istemcinin kimliğini doğrulaması gerektiğinde iki aşamalı OAuth kullanır. ( Erişim kontrolü, Günlük kaydı, ölçüm, hız sınırlama v.b )

İki aşamalı OAuth korumalı erişim sağlayan bir kaç istemcinin bulunduğu durumlar için uygundur. Sunucu her istemciye bir anahtar ve gizli anahtar verebilir. Müşteriyi bir imza com-OAuth göre  yerleştirilir. İki aşamalı OAuth aynı zamanda üç aşamalı OAuth destekler.

Örneğin; Bir müşterinin bir çalışanı işe alma sürecini uygulamak için sunucuyla etkileşime girer. İstemci son kullanıcılarının kimliğini doğrulamak için kendi kimlik doğrulama mekanizmasına sahiptir. Müşteri  kimlik doğrulamak için tanımlama bilgilerini web tabanlı bir uygulamaya girebilir. Sunucu istemcinin kimlik doğrulaması için iki aşamalı OAuth kullanması gerektiğinden her istekte bir sunucuya  Sunucunun atadığı varsayılan a1191fd420e0164c2f9aeac32ed35d23 oauth_consumer_key ve müşteri gizli anahtarı fd9b9d0f769c3bcc548496e4b5077da79c02d7be imza gönderir.  

Müşterinin yeni bir kaynak oluşturmak için aday bilgilerinin gönderdiğini varsayalım ve kimliği doğrulanmış bir istekte bulunmak için istemcinin bir yetkilendirme başlığı eklemesi gerekir.

oauth_signature parametresinin değeri sonuç olarak müşterinin daha sonra yetkilendirme başlığını takip eder ve istekte bulunur.

# Request to enter candidate info

POST /hires HTTP/1.1

Host: www.example.org

Authorization: OAuth realm="http://www.example.com/hires",

                               oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

                               oauth_nonce=85a55859fde262ba,

                               oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1,

                               oauth_signature_method=HMAC-SHA1,

                               oauth_timestamp=1258308689,

                               oauth_version=1.0

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

# Response

HTTP/1.1 201 Created

Location: http://www.example.org/hires/099

Content-Location: http://www.example.org/hires/099

Content-Type: application/json

{

   "name": "Joe Prospect",

   "id": "urn:example:hr:hiring:099",

   ...

   "link" : {

      "rel" : "http://www.example.org/rels/hiring/post-ref-result",

      "href" : "http://www.example.org/hires/099/refs"

   }

}

POST /hires HTTP/1.1 > korumalı bir kaynağa erişim isteği;

Authorization: OAuth realm="http://www.example.com/hires",

oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23,

oauth_nonce=85a55859fde262ba,

oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1,

oauth_signature_method=HMAC-SHA1,

oauth_timestamp=1258308689,

oauth_version=1.0

> Tüketici anahtarı ve tüketici gizli anahtarı (imza) kullanılarak hesaplanan yetkilendirme başlığı;

 

OAuth; istemcilerin kimlik bilgilerini sorgu parametreleri aracılığıyla sağlanmasına da izin verdiğini unutmayalım.  

# Request to enter candidate info

POST /hires?oauth_consumer_key=a1191fd420e0164c2f9aeac32ed35d23&

                  oauth_nonce=85a55859fde262ba&

                  oauth_signature=d8e19bb988110380a72f6dba33b2ba5903272fe1&

                  oauth_signature_method=HMAC-SHA1&

                  oauth_timestamp=1258308689&oauth_version=1.0 HTTP/1.1

Host: www.example.org

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

Ancak; Yetkilendirme üstbilgisinin kullanılması URI çoğalmasını azaltır.

İstemci geçerli bir Yetkilendirme üstbilgisini ekleyemezse; sunucu WWW-Authenticate başlığı ve 401 (Yetkisiz) yanıt başlığı cevabı döner.

# Request to enter candidate info

POST /hires HTTP/1.1

Host: www.example.org

Content-Type: application/json

{

   "name": "Joe Prospect",

   ...

}

# Response

401 Unauthorized

WWW-Authenticate: OAuth realm="http://www.example.com/hires"

Content-Type: text/html;charset=UTF-8

<html>

   ...

   <body>

      <p>Unauthorized.</p>

   </body>

</html>

Bu işlem sunucunun kimlik doğrulama için OAuth kullandığını gösterir.

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