在 nginx 中，`rewrite` 无法直接配合 `auth_basic` 实现登录重定向，因为 `auth_basic` 是 http 认证协议，由浏览器弹出系统对话框，而 `rewrite` 用于 url 重写。要实现登录重定向，应使用 `if` 指令结合 `$http_authorization` 变量判断认证状态，并通过 `return 302` 跳转到登录页面。
如何判断用户未认证并跳转
通过检查请求头中的 `Authorization` 字段是否为空，可以判断用户是否已进行 Basic Auth 认证。如果为空，说明用户尚未登录，此时应返回 302 重定向到登录页。
server {
listen 80;
server_name example.com;
location / {
# 检查 Authorization 头是否存在
if ($http_authorization = "") {
return 302 http://example.com/login;
}
# 如果存在，则继续处理 auth_basic
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
# 其他配置...
}
}
上述配置中，首先检查 `$http_authorization` 是否为空。如果为空，直接返回 302 重定向到 `/login` 页面。如果非空，则继续执行 `auth_basic` 认证流程。这样，未认证的用户会被重定向到登录页，而已认证的用户则会看到正常的受保护内容。
如何处理认证失败后的重定向
当用户输入错误的用户名或密码时，Nginx 会返回 401 Unauthorized 状态码。可以通过 `error_page` 指令将 401 错误重定向到登录页，从而实现认证失败后的重定向。
server {
listen 80;
server_name example.com;
error_page 401 /login;
location / {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
# 其他配置...
}
location = /login {
# 登录页面逻辑
root /var/www/html;
index login.html;
}
}
在上述配置中，`error_page 401 /login;` 指令将 401 错误重定向到 `/login` 路径。当用户输入错误的凭据时，Nginx 会返回 401 状态码，并自动重定向到 `/login` 页面。这样，用户可以重新输入正确的凭据进行认证。
基于 $http_authorization 变量的具体应用
在实际应用中，`$http_authorization` 变量可以用于更复杂的逻辑判断。例如，可以根据不同的用户角色重定向到不同的页面。
server {
listen 80;
server_name example.com;
location / {
# 检查 Authorization 头是否存在
if ($http_authorization = "") {
return 302 http://example.com/login;
}
# 解码 Base64 的 Authorization 头
set $auth_decoded $http_authorization;
rewrite ^.*: (.*)$ $1 break;
set $username $1;
# 根据用户名重定向
if ($username = "admin") {
return 302 http://example.com/admin;
}
if ($username = "user") {
return 302 http://example.com/user;
}
# 默认重定向到普通页面
return 302 http://example.com/default;
}
}
在上述配置中，首先检查 `$http_authorization` 是否为空。如果为空，直接返回 302 重定向到 `/login` 页面。如果非空，则解码 `Authorization` 头，提取用户名，并根据用户名重定向到不同的页面。例如，管理员用户会被重定向到 `/admin` 页面，普通用户会被重定向到 `/user` 页面，其他用户会被重定向到 `/default` 页面。这种灵活的逻辑判断可以实现更精细的访问控制。
