Özel HTTP Yetkilendirme Başlığı

124

Özel verileri bir HTTP yetkilendirme başlığına koymanın kabul edilebilir olup olmadığını merak ediyordum. Bir RESTful API tasarlıyoruz ve özel bir yetkilendirme yöntemi belirtmek için bir yönteme ihtiyacımız olabilir. Örnek olarak, buna FIRE-TOKENkimlik doğrulama diyelim .

Spesifikasyona göre böyle bir şey geçerli ve izin verilecek mi: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

İkinci dizenin ilk bölümü (':' öğesinden önce) API anahtarı, ikinci bölüm ise sorgu dizesinin bir karmasıdır.

— NRaf
kaynak

133

Tanımlanan biçim RFC2617 olup credentials = auth-scheme #auth-param. Yani, fumanchu ile aynı fikirdeyken, düzeltilmiş yetkilendirme şemasının şöyle görüneceğini düşünüyorum

Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKENŞema nerede ve iki anahtar-değer çifti kimlik doğrulama parametreleridir. Alıntıların isteğe bağlı olduğuna inanmama rağmen (p7-auth-19'un Ek B'sinden) ...

auth-param = token BWS "=" BWS ( token / quoted-string )

Bunun en son standartlara uygun olduğuna, halihazırda kullanımda olduğuna (aşağıya bakın) ve basit uzantı için bir anahtar / değer biçimi sağladığına inanıyorum (ek parametrelere ihtiyacınız varsa).

Bu auth-param sözdiziminin bazı örnekleri burada görülebilir ...

http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-19#section-4.4

https://developers.google.com/youtube/2.0/developers_guide_protocol_clientlogin

https://developers.google.com/accounts/docs/AuthSub#WorkingAuthSub

— StarTrekRedneck
kaynak

4

Amazon'un basit depolama API'si başka bir örnek sunar.

— bishop

18

Ayrı, özel bir başlığa koyun.

Standart HTTP üstbilgilerini aşırı yüklemek muhtemelen değerinden daha fazla kafa karışıklığına neden olacak ve en az sürpriz ilkesini ihlal edecektir . Ayrıca, yalnızca standart HTTP üstbilgilerinin (örneğin Authorization) standart biçimiyle başa çıkabilen kullanıma hazır araç kitlerini kullanmak isteyen API istemci programcılarınız için birlikte çalışabilirlik sorunlarına da yol açabilir .

— Brian Kelly
kaynak

3

Bunu düzeltmek göründüğünden daha zor olabilir. Fumanchu'nun sağladığı bağlantı (cevabına bir yorum olarak), özel bir başlığın eklenmesinin neden Cache-Control'ü manuel olarak doğru şekilde ayarlamak zorunda kalmanın ek yükünü neden eklediğini açıklıyor.

— Jon-Eric

4

Ayrıca, tarayıcı aracılığıyla çapraz menşe talebinde bulunuyorsanız, sırf başka türlü önleyebileceğiniz özel başlık nedeniyle artık uçuş öncesi bölgedesiniz. Bazı uygulamalar için bu istekler toplanır.

— Wil Moore III

31

Özel kimlik doğrulama başlıklarına büyük hayır. AuthorizationKendi özel düzeninize sahip spesifikasyon standardı başlığı fazlasıyla yeterli olmalıdır. Ayrıca @wilmoore'un belirttiği gibi uçuş öncesi Origin taleplerinden de kaçınırsınız. Özel düzenler, bildiğim makul derecede modern HTTP sunucusuna müdahale etmez, ayrıca kendi düzeninizi kullanırsanız, onu kendiniz ayrıştırmanız gerekir - hiçbir kitaplık çakışmaz (aksi takdirde kitaplık kötü yazılır).

— Les Hazlewood

7

Kimlik bilgilerini Authorizationözel bir başlık yerine başlıkta iletmenin iyi bir nedeni , proxy'lerin ve kaydedicilerin bilgileri hassas olarak ele almayı bilmesidir.

— Eron Wright

15

Hayır, bu RFC 2617'deki "kimlik bilgileri" tanımına göre geçerli bir üretim değildir . Geçerli bir kimlik doğrulama şeması veriyorsunuz, ancak auth-param değerleri biçiminde olmalı token "=" ( token | quoted-string )(bkz. Bölüm 1.2) ve örneğiniz bu şekilde "=" kullanmıyor.

— fumanchu
kaynak

1

Bu doğru değil. Örnek bir biçim için belgenin 5. sayfasına bakın: Yetkilendirme: Temel QWxhZGRpbjpvcGVuIHNlc2FtZQ ==

— NRaf

11

Bu doğru. Ancak tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16#section-2.3.1'in dediği gibi, "" b64token "gösterimi mevcut kimlik doğrulama şemalarıyla uyumluluk için tanıtıldı ve yalnızca bir kez kullanılabilir Bu nedenle, yeni şemalar bunun yerine "auth-param" sözdizimini kullanmalıdır, çünkü aksi takdirde gelecekteki uzantılar imkansız olacaktır. " Ayrıca, özel başlıklarda kimlik doğrulaması yapmaya ilişkin önbellek tartışmasına da bakın.

— fumanchu

9

Bildiğim eski soru, ama merak için:

İster inanın ister inanmayın, bu sorun yaklaşık 2 on yıl önce HTTP BASIC ile çözüldü ve bu değeri base64 olarak kodlanmış kullanıcı adı: şifre olarak geçirdi. (Bkz. Http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )

Aynısını yapabilirsiniz, böylece yukarıdaki örnek şöyle olur:

Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==

— Mike Marcacci
kaynak

4

Buradaki başka bir cevaba yapılan bir yoruma göre, burada kullanılan gösterim mevcut şemalarla uyumluluk içindir ve yeni uzantılar için tavsiye edilmediğinden , bu cevaba karşı tavsiyede bulunuyorum .

— Whymarrh