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

27 Şubat 2022 Pazar

RestFull WebService - Kaynak Taşıma

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9 Aralık 2021 Perşembe

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

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

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

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

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

PUT /reviews/notes_from_underground HTTP/1.1

Host: www.example.org

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

If-Match: "3f4a74db207d0447d46710a64971e777"

...

# Response

HTTP/1.1 412 Precondition Failed

Content-Length: 0


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

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

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


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

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

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



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

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


3 Nisan 2021 Cumartesi

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



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

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

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

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

# Request

GET /user/smith/contacts HTTP/1.1

Host: contacts.example1.org


# Response

HTTP/1.1 200 OK

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


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

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

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

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

               t=bcb9169866c69410be37f68210a6986c"

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

   <contact>

      ...

   </contact>

   ...

</contact>

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

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

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


# Request

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

Host: messaging.example2.org

# Response

HTTP/1.1 303 See Other

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

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


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

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

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

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

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

20 Mart 2021 Cumartesi

Gizlilik ve Bütünlük Nasıl Korunur?

 

 TLS ve HTTPS kullanarak, kaynakları yalnızca isteklere hizmet edecek şekilde yapılandırılmış bir sunucu üzerinden erişilebilir hale getirin.  HTTP katmanlı bir protokoldür. Mesaj aktarım güvenliği TCP /IP aktarım protokolüne dayanır. TLS (RFC 5246) pro üzerinden HTTP katmanlayarak SSL'in halefi olan tocol gizliği ve bütünlüğü koruyabilinir.  Şifreleme ve dijital imza ile uğraşmadan istek ve yanıtlar mesajların istemci ve sunucu kodundaki türlerini kapsar.
 
TLS  her iki sunucuda da karşılıklı kimlik doğrulama için kullanılabilir.  Kullanıcıların kimlik doğrulaması için temel kimlik doğrulamasını TLS güvenerek kullanılabilir.  TLS gizlilik ve bütünlük için kullandığınızda, protokol oluşturmaktan kaçınabilirsiniz. Bu tür güvenlik önlemleri için doğrudan istek ve yanıt mesajları ve dahası TLS mesajdan bağımsızdır. Herhangi bir medya türü veya talebi için kullanılabilir.

SOAP tabanlı web hizmetlerinin WS-Security'ye güvenli göndermenin yollarını belirtir. SOAP başlıklı belirteçler, örneğin kurcalamayı önlemek için SOAP tabanlı web hizmetleri SOAP mesajlarının başlığına aşağıdaki örnekteki gibi imza ekler.

# A SOAP message containing a signature
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   <soapenv:Header>
      <wsse:Security
         soapenv:actor="http://www.example.org"
         soapenv:mustUnderstand="1"
         xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext">
         <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
               <CanonicalizationMethod
                  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
               <Reference URI="#abcd">
                  <Transforms>
                     <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                  </Transforms>
                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <DigestValue>... digest value</DigestValue>
               </Reference>
            </SignedInfo>
            <SignatureValue>...</SignatureValue>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
               ... key info ...
            </KeyInfo>
         </Signature>
      </wsse:Security>

   </soapenv:Header>
   <soapenv:Body>... application data ...</</soapenv:Body>
</soapenv:Envelope>

Bu mesaj Body öğesindeki uygulaa verilerini ve bunun imzasını içerir. Üstbilgi Bunun aksine RESTful web hizmetleri HTTPS kullanabilir. (TLS üzerinden  HTTP katmanlandırılmış) TLS in yöntemlerden bağımsız olarak dijital imzalar ve şifreleme ile ilgilenmesine izin vermek için kullanılan ortam türleri için.

HTTP nin katmanlı mimarisi uygulama düzeyindeki mesajları taşıma düzeyinde güvenlikten dolayı ayırır.

27 Şubat 2021 Cumartesi

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


7 Şubat 2021 Pazar

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

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

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

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

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


# Request

GET /photos HTTP/1.1

Host: www.example.org

# Response

401 Unauthorized

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

         qop="auth"

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

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

   <message>Unauthorized.</message>

</error>

# Request

GET /photos HTTP/1.1

Host: www.example.org

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

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

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

# Response

401 Unauthorized

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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