后端网络【免费下载链接】cpp-httplibA C header-only HTTP/HTTPS server and client library项目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib点击查看免费下载导读本文聚焦 cpp-httplib一个 C header-only 的 HTTP/HTTPS 服务器与客户端库的客户端认证能力围绕 docs-src/pages/en/cookbook/c05-basic-auth.md 这一配方展开如何用set_basic_auth()为整个 Client 实例配置 Basic 认证如何用make_basic_authentication_header()仅为单个请求注入凭据以及如何使用 OpenSSL 构建下的 Digest 认证。读完本文你将能在实际项目中安全、正确地完成 HTTP 接口的账号密码认证接入并理解凭据在发送链路中的注入时机与安全边界。Basic 认证基础用法set_basic_auth()对于需要 Basic 认证的接口只需把用户名和密码传给set_basic_auth()cpp-httplib 会自动为你构造Authorization: Basic ...请求头httplib::Client cli(https://api.example.com); cli.set_basic_auth(alice, s3cret); auto res cli.Get(/private); if (res res-status 200) { std::cout res-body std::endl; }配置一次之后该 Client 发出的每一个请求都会携带这份凭据无需在每次请求时手动拼接请求头。注意这里使用了https://前缀——Basic 凭据只能走 TLS 传输原因见下文“安全性”小节。源码视角凭据何时被注入请求头set_basic_auth()本身只做了存储工作。在 httplib.h 中ClientImpl::set_basic_auth将用户名与密码保存到成员变量httplib.h#L17252-L17256Client::set_basic_auth只是简单转发到内部的cli_httplib.h#L18012-L18014。真正的注入发生在请求发送阶段。在 httplib.h#L15817-L15825 可以看到发送前的统一装配逻辑if (!is_connect !req.has_header(Authorization)) { if (!basic_auth_password_.empty() || !basic_auth_username_.empty()) { req.headers.insert(make_basic_authentication_header( basic_auth_username_, basic_auth_password_, false)); } else if (!bearer_token_auth_token_.empty()) { req.headers.insert(make_bearer_token_authentication_header( bearer_token_auth_token_, false)); } }这段实现透露了两个值得注意的细节显式传入的请求头优先级更高判断条件是!req.has_header(Authorization)即只有请求本身尚未携带Authorization头时set_basic_auth()配置的凭据才会被写入。若你在某次调用中手动指定了该头则配置的 Basic 凭据不会覆盖它。Basic 与 Bearer 是互斥的兜底逻辑先检查 Basic 凭据再检查 Bearer Token且都要求用户名或密码非空才生效httplib.h#L17258-L17260 对应set_bearer_token_auth。两种方式同时配置时Basic 优先。此外凭据不会出现在CONNECT请求上!is_connect条件这是为了防止在 HTTPS 代理隧道建立阶段过早泄露认证信息。单次请求认证make_basic_authentication_header()如果只想让某一个特定请求携带凭据不必也不应在 Client 上全局配置直接通过请求头传递即可httplib::Headers headers { httplib::make_basic_authentication_header(alice, s3cret), }; auto res cli.Get(/private, headers);make_basic_authentication_header()是头文件级别的公共辅助函数其实现位于 httplib.h#L11461-L11467inline std::pairstd::string, std::string make_basic_authentication_header(const std::string username, const std::string password, bool is_proxy) { auto field Basic detail::base64_encode(username : password); auto key is_proxy ? Proxy-Authorization : Authorization; return std::make_pair(key, std::move(field)); }可以看到它做的是先把username:password拼接成user:pass形式再做 Base64 编码最后拼成Basic 编码结果字符串返回的键值对可直接插入httplib::Headers。is_proxy参数默认为false为true时生成的是Proxy-Authorization头用于代理认证。这种方式的典型使用场景是同一 Client 实例同时访问需要认证和无需认证的多个接口或不同接口使用不同账号。set_basic_auth()的全局配置与每次请求的显式头互不干扰——根据上一节源码中的has_header判断显式头会胜出。代理场景的 Basic 认证凭据各归各跳当客户端经由 HTTP 代理访问目标服务器时存在两套独立的认证体系代理认证Proxy-Authorization与源站认证Authorization。cpp-httplib 分别提供set_proxy_basic_auth()与之配合。在 httplib.h#L15830-L15842 可以看到代理凭据的注入条件只有当is_proxy_enabled_for_host(host_)且非 SSL 或处于 CONNECT 隧道建立阶段时Proxy-Authorization才会被添加并且同样遵循“请求中已存在同名头则不覆盖”的规则。这样设计保证了源站不会收到代理的凭据代理也不会收到源站的凭据。这一行为有专门的测试验证见 test/test.cc#L26417-L26424测试同时调用cli.set_proxy_basic_auth(proxy-user, proxy-pass)与cli.set_basic_auth(origin-user, origin-pass)断言 CONNECT 请求携带Proxy-Authorization而隧道内部发往源站的请求不携带它。安全性Base64 只是编码不是加密Warning:Basic 认证仅将凭据做 Base64编码encode并不进行加密encrypt。请务必在 HTTPS 上使用它——在明文 HTTP 上你的密码会以可解码的形式在网络中裸奔任何抓包者都能立即还原出账号密码。这是 c05-basic-auth.md 中特别强调的一条铁律。Base64 只是把二进制/文本变成 ASCII 字符集的编码规则alice:s3cret编码成Basic YWxpY2U6czNjcmV0后任何人都能解码。因此生产环境一律通过httplib::SSLClient或https://前缀发起 Basic 认证请求不要让set_basic_auth()的凭据在日志、异常信息或调试输出中被打印若服务端支持更强的方案如 Digest、Bearer Token 或 mTLS优先考虑。关于 SSLClient 的使用方式可参考 docs-src/pages/en/tour/06-https-client.mdTLS 后端的选择见 docs-src/pages/en/cookbook/t01-tls-backends.md。Digest 认证set_digest_auth()对于更安全的 Digest 认证方案使用set_digest_auth()cli.set_digest_auth(alice, s3cret);前提条件Digest 认证只在 cpp-httplib 以 OpenSSL或 mbedTLS、wolfSSL 等其他 TLS 后端构建时可用因为相关实现整体包在#ifdef CPPHTTPLIB_SSL_ENABLED之中该宏在 httplib.h#L559 定义。若你的编译环境没有启用 SSLset_digest_auth将不存在于 API 中。挑战-响应流程客户端如何自动完成认证与 Basic 一次性携带凭据不同Digest 认证是标准的**挑战-响应challenge-response**机制cpp-httplib 在客户端内部自动完成了整个往返客户端先以无凭据状态发送请求服务端返回401 Unauthorized或代理场景的407 Proxy Authentication Required并在WWW-Authenticate或Proxy-Authenticate头中给出realm、nonce、qop、algorithm、opaque等挑战参数客户端解析挑战参数用用户名、密码、nonce、请求方法与路径计算摘要重新构造Authorization: Digest ...头重发请求服务端校验通过后返回正常响应。这段自动重试逻辑在 httplib.h#L15537-L15573当收到401/407且req.authorization_count_ 5时调用detail::parse_www_authenticate解析挑战httplib.h#L10102然后通过detail::make_digest_authentication_headerhttplib.h#L10581构造摘要头并重发。重试上限为 5 次可有效防止无限循环。摘要计算的底层实现make_digest_authentication_header完整实现了 RFC 7616 的摘要计算httplib.h#L10581-L10639要点包括算法选择默认MD5若挑战声明algorithmSHA-256或SHA-512则自动切换detail::SHA_256/detail::SHA_512/detail::MD5qop 处理优先采用auth-int其次auth否则按无 qop 的老式计算cnonce 与 nc每次重试生成随机 cnoncedetail::random_string(10)并维护 8 位十六进制计数的nc字段opaque 回传挑战若带opaque参数会在响应头中原样带回URI 取用摘要中的uri使用req.path。另外解析端parse_www_authenticate遵循 RFC 9110 的 challenge 列表语法httplib.h#L10054-L10134一个服务端可以在同一WWW-Authenticate头中同时提供多个挑战例如 Digest 与 Basic 并列解析器会跳过引号内的逗号进行分段并只采纳第一个 Digest 挑战避免 nonce 与算法配对错乱。测试验证认证行为有据可查仓库自带的测试直接验证了以上全部行为是学习与排查认证问题的第一手材料test/test.cc#L3061-L3099 的BasicAuthTest无凭据请求得401make_basic_authentication_header(hello, world)后得200且响应体含authenticated:trueset_basic_auth(hello, world)同样得200密码或用户名错误则回落401test/test.cc#L3102-L3139 的DigestAuthTest对 httpbingo.org 的/digest-auth/auth/hello/world系列路径覆盖 MD5 与 SHA-256验证set_digest_auth的成功与失败路径test/test.cc#L3141-L3179 验证服务端同时下发 Basic 与 Digest 多个挑战时客户端重试携带的是格式正确的Digest头test/test.cc#L3638-L3641 验证重定向到不同主机时凭据不会被转发符合 RFC 9110 的安全要求。延伸阅读使用 Bearer Token 调用 APIC06. Call an API with a Bearer token为所有请求统一设置默认请求头可与认证头叠加使用C03. Set default headers通过代理发送请求C16. Send requests through a proxyTLS 后端的选型OpenSSL / mbedTLS / wolfSSLT01. Choosing between OpenSSL, mbedTLS, and wolfSSL服务端侧如何在路由前统一校验认证S11. Authenticate per route with a pre-request handler赞分享后端网络【免费下载链接】cpp-httplibA C header-only HTTP/HTTPS server and client library项目地址https://gitcode.com/GitHub_Trending/cp/cpp-httplib点击查看免费下载相关推荐cpp-httplib 客户端 Basic 认证实战set_basic_auth 与 make_basic_authentication_header 详解cpp httplib 客户端 Basic 认证实战set_basic_auth 与 make_basic_authentication_header 详解后端网络actions-runner-controller 中 minRunners 语义变更从保底运行数到保底空闲数actions runner controller 中 minRunners 语义变更从保底运行数到保底空闲数 本文基于 actions runner后端网络Floccus WebDAV认证机制Basic与Digest认证实现Floccus WebDAV认证机制Basic与Digest认证实现 WebDAVWeb based Distributed Authoring and V前端移动开发数据同步创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考