Question

我正在尝试向需要Authentication标头的路由发出GET请求，该标头带有base64编码的用户名和密码bruce：1234。当我尝试时：

curl -v http://localhost:3000/api/users \
     -H "Authorization:Basic `echo -n bruce:1234 | base64`" \
     -H "Accept:application/json"

...我从CURL命令获得以下输出：

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3000 (#0)
> GET /api/users HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.61.0
> Authorization:Basic YnJ1Y2U6MTIzNA==
> Accept:application/json
>
< HTTP/1.1 400 Bad Request
* no chunk, no close, no size. Assume close to signal end
<
* Closing connection 0

但是，当我直接用base64编码的值替换时，它会起作用：

curl -v http://localhost:3000/api/users \
     -H "Authorization:Basic YnJ1Y2U6MTIzNA==" \
     -H "Accept:application/json"

*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3000 (#0)
> GET /api/users HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.61.0
> Authorization:Basic YnJ1Y2U6MTIzNA==
> Accept:application/json
>
< HTTP/1.1 200 OK
... [data returned, etc.].

对我来说奇怪的是，这两种方法的CURL命令的初始输出（由于详细标记-v）完全相同，那么为什么第一种方法会失败？

Answer 1

好的，我最终了解了这里发生的事情。我使用的是Mac，Mac的本地base64不会在其输出中添加任何空格。因此，从理论上讲，原始语法会起作用。但是，我还使用自制软件安装了base64，that version处于优先地位，并且确实添加了新行。

另一个陷阱如下。基于this response，我假设要添加的字符是换行符'\ n'，所以我花了很长时间来摆弄... | base64 | tr -d \\n管道，但没有成功。最终，我意识到酿造安装的版本不是在添加'\ n'而是在添加'\ r'，所以我终于使它起作用：

curl -v http://localhost:3000/api/users \
     -H "Authorization:Basic $(echo -n bruce:1234 | base64 | tr -d \\r)" \
     -H 'Accept:application/json'

总而言之，您需要了解不同的base64构建的不同行为：

Mac原生：默认情况下，base64不添加任何内容-不需要进一步的管道处理。
自制软件：base64添加了'\ r'-您需要通过tr -d \\r将其传递给管道。
Linux：base64（通常）添加了'\ n'-您需要通过tr -d \\n将其传递。

如何在CURL中回显base64？

1 个答案: