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.

Sunuculardaki Koşullu PUT İstekleri

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

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

* İstemci If-Unmodified-Since ve/veya If-Match üstbilgilerini içermiyorsa döndür, 403  cevap gövdesinde nedenini açıklayın.

* Sağlanan If-Unmodified-Since veya If-Match başlıkları gerçek sunucudaki gösterimin değiştirilmiş tarih-saat ve ETAG değerleri hata döndürürse. Kod 412 (Ön koşul başarısız)

*İstemci koşullu bir PUT isteği gönerirse ve sağlanan koşullar eşleşir kaynağı günceller ve 200 (OK) veya 204 (İçerik Yok) geri dönüş sağlanır.

İsteğe bağlı olarak, sağlanan güncellenmiş Son Değiştirilmiş ve/veya ETAG başlıklarını eklenebilir. Kaynak yanıt aynı zamanda güncellenen URI ile bir Content-Location başlığı içerir.

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

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

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

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

# Process this request if and only if the included conditional tags match

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

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

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

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

# Request from client A

GET /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

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

...

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

# Request from client B

GET /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 200 OK

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

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

# Request from client B

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

HTTP/1.1 200 OK

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

İLK GÜNCELLEME:

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

# Request from client A

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

# Response

HTTP/1.1 204 OK

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

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

Bu sıranın bir sonucu olarak, A müşterisi, B müşterisi tarafından yapılan değişikliklerin üzerine yazar. İstemci B'nin güncellemesi kaybolur.! ne müşteri A nede müşteri B de kayıp güncellemeden haberi yoktur.

Her iki PUT işlemi sonuçta başarılı oldu. Ancak daha sonra B'nin kullanıcısı güncellemelerinin kaybolduğunu görecektir. Her değişikliği kaydetmek için sunucuda uygulamazsanız bu kayıp güncelleştirmeyi algılamak için sunucuda hatayı ayıklayamazsınız.

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

# Request from client B

PUT /reviews/notes_from_underground HTTP/1.1 >> İlk koşullu güncelleme başarılı

Host: www.example.org

If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

# Response

HTTP/1.1 204 No Content

Content-Location: http://www.example.org/reviews/notes_from_underground

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

Last-Modified: Sun, 09 Aug 2020 01:10:14 GMT

If-Match: "5dcb920acfd4f3943dbc1672756d7f43"

İlk koşullu güncelleme başarılı ;

Yanıt bir Content-Location başlığı ve güncellenmiş Last-Modified ve istemcinin gelecekteki isteklerde kullanabileceği ETAG değerleri.

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

# Request from client A

PUT /reviews/notes_from_underground HTTP/1.1 > 2 nci güncelleme Failed etti. 

Host: www.example.org

If-Unmodified-Since: Sun, 09 Aug 2020 00:56:14 GMT

If-Match: "3f4a74db207d0447d46710a64971e777"

# Response

HTTP/1.1 412 Precondition Failed

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

<error>

   <message>The review you are trying to update has changed.</message>

   <description>You are trying to update a resource based on stale information.

   Get a new copy of this review, resolve any differences, and retry.</description>

</error>

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.

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)

Üç 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.

SQL Server Deadlock #1

 

Deadlock birincil nedenlerinden biri performans düşüklüğü gelir. iki veya daha fazla işlem arasında bir kilitlenme meydana geldiğinde SQL Server sadece bir işleme izin verir. Daha sonra diğer işlem(ler) için tamamlamak , sonlandırmak yada geri almak için bir hata döndürür. Kullanıcıya bu konuda yeniden denemesini sağlatmak yada işlemi sonlandırmak.

Kilitlenme, iki işlemin birbiri tarafından engellendiği özel bir engelleme senaryosudur. Her süreç kendi kaynaklarını elinde tutarak diğer işlem tarafında kilitlenen bir kaynağa erişmeye çalışır.

SQL Server işlemin geri alınması maliyetini değerlendirerek oturumu kilitleme kurbanı olarak belirler. Oturumdaki en düşük olanı seçer.  Bu alanda bir kontrol uygulanabilir. Bağlantı düşük olarak seçilerek bu işlemi yönetebiliriz.

SET DEADLOCK_PRIORITY LOW;

SET komutu yürüterek bağlantının kilitlenme önceliğini normal değere atayabiliriz.

SET DEADLOCK_PRIORITY NORMAL;

Deadlock tespiti için Error Handling Kullanmak 

SQL Server kurban olarak bir oturumu seçtiğinde hata numarası ile bir hata oluşturur. Bu hata numarasını ve hatayı bulabilmek için TRY - CATCH yapısını kullanabiliriz.

Hata işleyicisinde kilitlenme durumda hatayı uygulamaya döndürmeden önce T-SQL içerisinde birkaç kez yeniden başlatmayı deneyelim. 

DECLARE @retry AS TINYINT = 1,

      @retrymax AS TINYINT = 2,

      @retrycount AS TINYINT = 0;

WHILE @retry = 1

      AND @retrycount <= @retrymax

      BEGIN

            SET @retry = 0;

                   

            BEGIN TRY

                  UPDATE HumanResources.Employee

                  SET LoginID = '54321'

                  WHERE BusinessEntityID = 100;

            END TRY

            BEGIN CATCH

                  IF (ERROR_NUMBER() = 1205)

                        BEGIN

                              SET @retrycount = @retrycount + 1;

                              SET @retry = 1;

                        END

            END CATCH

END

Try, Catch blogu içerisinde hata numrasını bulabiliriz. Kilitlenme olup olmadığını kontrol edebilmek içinse, ERROR_NUMBER()  fonksiyonunu kullanabiliriz Kilitlenme ile karşılaşıldığında belirli bir sayıda işlemi yeniden başlatırız. Arasıra ortaya çıkan kilitlenmelerde kısa çözüm sağlayacaktır.  En iyi yaklaşım ise kilitlenmenin ana nedenini bulmaktır.