Apache默认过滤Authorization头，因安全考虑在CGI/FPM等模式下剥离该敏感头，导致%{HTTP_AUTHORIZATION}为空；需通过SetEnvIf或WSGIPassAuthorization显式透传，再由后端校验。
Apache 中 RewriteCond 本身不能直接“捕获”请求头中的授权凭证（比如 Authorization 头里的 Bearer Token 或 Basic 凭据）用于后续重定向逻辑，因为 %{HTTP_AUTHORIZATION} 变量在多数 Apache 配置中默认不可用——它常被 CGI 模式或某些 MPM（如 prefork）剥离，或需显式启用传递。
为什么 Authorization 头通常拿不到
Apache 默认会过滤掉 Authorization 请求头，尤其在使用 PHP-FPM、CGI 或反向代理时。即使头存在，%{HTTP_AUTHORIZATION} 也经常为空。常见原因包括：
- mod_rewrite 无法直接解析 Base64 编码的 Basic 凭据或 JWT 结构；
- 服务器未配置传递该头（如 FastCGI 环境需
PassEnv HTTP_AUTHORIZATION或显式设置）； - 正则匹配 Authorization 值属于高危操作，易引入绕过或误判，不推荐用于鉴权核心逻辑。
可行的替代方案：用环境变量 + RewriteCond 判断是否存在
若仅需检测请求是否携带有效 Authorization 头（不管具体内容），可先确保头被传递，再用 RewriteCond 判断非空：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 在虚拟主机或目录配置中添加（以启用传递）：
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 - 或对 PHP-FPM 用户，在
php-fpm.conf或 pool 配置中加：env[HTTP_AUTHORIZATION] = $HTTP_AUTHORIZATION - 然后写 RewriteCond 判断是否非空：
RewriteCond %{ENV:HTTP_AUTHORIZATION} !^$
接着执行重定向：RewriteRule ^/api/.*$ /auth-verified.php [E=AUTH_OK:1,L]
更安全的做法：交给后端处理，RewriteCond 只做轻量路由
真正验证 Token 或凭据应由应用层（如 PHP/Python/Node.js）完成，Apache 仅负责转发或简单分流。例如：
- 用 RewriteCond 匹配带 Authorization 的请求，打上标记：
RewriteCond %{HTTP:Authorization} ^(.+)$ [NC]RewriteRule ^/protected/(.*)$ /index.php?path=$1 [E=HAS_AUTH:1,QSA,L] - PHP 脚本中读取
$_SERVER['HTTP_AUTHORIZATION']或getallheaders()，校验后再决定跳转或返回 401。
注意点与限制
不要试图在 RewriteCond 中用正则提取 Token 内容做业务判断（如匹配某固定 Bearer 值），原因有三：
- Base64 编码含
+、/、=，RewriteRule 正则转义复杂且易出错； - JWT 本身含点号和长字符串，Apache 正则性能差，还可能被恶意构造触发回溯攻击；
- 重定向逻辑若依赖凭证明文，违反最小权限原则，也不符合 OAuth/Bearer 最佳实践。
