Eu queria saber se é aceitável colocar dados personalizados em um cabeçalho de autorização HTTP. Estamos projetando uma API RESTful e podemos precisar de uma maneira de especificar um método personalizado de autorização. Como exemplo, vamos chamá-loFIRE-TOKEN autenticação.
Algo assim seria válido e permitido de acordo com as especificações: Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=
A primeira parte da segunda sequência (antes de ':') é a chave da API, a segunda parte é um hash da sequência de consultas.
http
rest
header
authorization
NRaf
fonte
fonte
Coloque-o em um cabeçalho personalizado separado.
A sobrecarga dos cabeçalhos HTTP padrão provavelmente causará mais confusão do que vale a pena e violará o princípio da menor surpresa . Também pode levar a problemas de interoperabilidade para os programadores de clientes da API que desejam usar kits de ferramentas prontos para uso que só podem lidar com a forma padrão de cabeçalhos HTTP típicos (como
Authorization).fonte
Authorizationcabeçalho padrão de especificação com seu próprio esquema personalizado deve ser mais que suficiente. Além disso, você evita solicitações de origem antes do voo, como @wilmoore indica. Esquemas personalizados não interferem com nenhum servidor HTTP razoavelmente moderno que eu conheça, além disso, se você usar seu próprio esquema, terá que analisá-lo por conta própria - nenhuma biblioteca deve entrar em conflito (caso contrário, a biblioteca será mal escrita).Authorizationcabeçalho, e não em um cabeçalho personalizado, é que os proxies e os registradores sabem tratar as informações como confidenciais.Não, essa não é uma produção válida de acordo com a definição de "credenciais" na RFC 2617 . Você fornece um esquema de autenticação válido, mas os valores de auth-param devem estar no formato
token "=" ( token | quoted-string )(consulte a seção 1.2) e seu exemplo não usa "=" dessa maneira.fonte
Velha pergunta eu sei, mas para os curiosos:
Acredite ou não, esse problema foi resolvido ~ duas décadas atrás com o HTTP BASIC, que passa o valor como nome de usuário codificado em base64: senha. (Consulte http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side )
Você pode fazer o mesmo, para que o exemplo acima se torne:
fonte