自定义授权HTTP标头
当他向API发送请求时，我需要对客户端进行身份validation。 客户端有一个API令牌，我正在考虑使用标准Authorization标头将令牌发送到服务器。
通常这个头被用于Basic和Digestauthentication。 但我不知道是否允许自定义此标头的值并使用自定义authenticationscheme，例如：
Authorization: Token 1af538baa9045a84c0e889f672baf83ff24
你会推荐这个吗？ 还是有更好的方法来发送令牌？
您可以创build使用Authorization:标头的自定义auth模式 – 例如，这就是OAuth的工作原理。
一般来说，如果服务器或代理服务器不理解标准头文件的值 ，他们将不理会它们。 这是创build自己的标题密钥 ，往往可以产生意想不到的结果 – 许多代理将剥离标头，他们不认识的名字。
话虽如此，使用cookie来传输令牌可能是一个比较好的主意，而不是Authorization:头部，这是因为cookie被明确devise为携带自定义值，而HTTP内置auth方法的规范并不真的要说 – 如果你想看看到底是什么话， 看看这里 。
关于这点的另外一点是，许多HTTP客户端库都内置了对摘要和基本身份validation的支持，但是当试图在标题字段中设置一个原始值时可能会使生活更加困难，而它们都将提供对cookie的简单支持，允许他们内部有或多或less的任何价值。
在CROSS ORIGIN请求的情况下，请阅读以下内容：
我面对这种情况，起初我select使用Authorization Header，之后在面对以下问题后将其删除。
Authorization标题被视为自定义标题。 因此，如果使用“ Autorization Header”设置了跨域请求，浏览器首先会发送预检请求。 预检请求是OPTIONS方法的HTTP请求，这将剥去所有参数。 您的服务器需要使用具有自定义标题（ Authorization标头）值的Access-Control-Allow-Headers标题进行响应。
因此，对于客户端（浏览器）发送的每个请求，浏览器正在发送额外的HTTP请求（OPTIONS）。 这恶化了我的API的性能。 你应该检查是否join这会降低你的performance。 作为一个解决方法，我在http参数中发送令牌，我知道这不是做这件事的最好方法，但我不能妥协的performance。
这有点过时，但可能有其他人在寻找相同问题的答案。 您应该考虑一下保护空间对您的API有意义。 例如，您可能需要识别和validation客户端应用程序对您的API的访问，以将其用于已知的已注册客户端应用程序。 在这种情况下，您可以使用带有客户端标识符的Basic身份validationscheme作为用户标识和客户端共享密钥作为密码。 您不需要专有的身份validationscheme，只需清楚地标识客户端在每个保护空间使用的身份validationscheme即可。 我更喜欢每个保护空间的一个，但是HTTP标准允许在每个响应中的每个WWW-Authenticate报头响应和多个WWW-Authenticate报头上有多个authenticationscheme; 这会让使用选项的API客户感到困惑。 保持一致和清晰，那么你的API将被使用。
我会build议不要使用自定义scheme名称的HTTP身份validation。 如果你觉得你有一些通用的东西，你可以定义一个新的scheme。 有关详细信息，请参阅http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 。
请尝试下面的邮递员：
在标题部分为我工作的例子..
授权：智威汤逊
