27 Şubat 2022 Pazar
RestFull WebService - Kaynak Taşıma
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
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
20 Mart 2021 Cumartesi
Gizlilik ve Bütünlük Nasıl Korunur?
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.
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
7 Şubat 2021 Pazar
İstemcilerin Kimlik Doğrulamasında Özet Kimlik Doğrulama
İ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",
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





