利用nginx完成iframe请求的身份认证
需求说明
在dify中搭建了一个chatflow,搭建完成后,将其以iframe的方式,嵌入到自己开发的一个网站中。
嵌入完成后,效果如下图所示:
此时存在一个安全问题,如果用户知道了这个iframe的URL地址,就可以直接跳过网站的登录,直接访问dify的应用(dify本身没有身份认证),这是不安全的,现在要解决这个问题。
解决思路
利用nginx的 auth_request 调用认证服务,认证通过的请求才能访问dify,否则不可访问。
认证操作可以通过访问系统首页的方式完成,首页是需要登录后才能正常访问的,如果没有登录,则会返回302,会重定向到登录页面(不需要另外再单独写认证的接口,而是利用登录成功后的系统首页URL完成认证)。
auth_request对应的路由返回2xx状态码时,不会拦截请求,而是构建一个subrequest请求再去请求真实受保护资源的接口,所以当系统未登录时,返回的302状态码,此时请求会被拦截。从而达到身份认证的目的。
实战操作
1.下载NGINX
从NGINX官网下载Windows版本:
https://nginx.org/en/download.html
我的是Windows系统,选择这个:
2启动NGINX
下载完成,解压,进入到这个目录下:
双击nginx.exe文件,启动nginx。
启动成功后,可以在任务管理器中看到:
验证是否启动成功:访问http://localhost
,若看到欢迎页面即成功,nginx默认80端口,如果有其他应用占用了80端口,调整nginx的配置(在下面有说到如何更改配置)。
3.配置代理(修改nginx配置文件)
编辑conf/nginx.conf
文件,将server中的内容修改为如下配置:
server {listen 8080;server_name localhost;#charset koi8-r;#access_log logs/host.access.log main;# 带有 /ai_wm/apps/dify 路径的请求,代表是dify的请求,要进行特殊处理location /ai_wm/apps/dify {# 该指令告诉Nginx,在处理用户请求前,先将请求发送到/auth进行认证。auth_request /auth;# 处理认证服务的响应结果error_page 401 = @error401;auth_request_set $user $upstream_http_x_forwarded_user;proxy_set_header X-Forwarded-User $user;# 鉴权通过后请求转发到该地址proxy_pass http://192.168.0.197/;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Prefix /ai_wm/apps/dify;proxy_set_header Cookie $http_cookie; # 确保转发 Cookie# 将请求路径从 /ai_wm/apps/dify/xxx 重写为 /xxx。用于简化请求路径或将请求路由到不同的后端路径。rewrite ^/ai_wm/apps/dify/(.*)$ /$1 break;}# 认证服务的代理设置location /auth {# 声明该location块仅限内部调用,不用于反向代理internal;proxy_set_header Host $host;# 不代理请求体到认证服务proxy_pass_request_body off;# 进行验证,返回状态码proxy_pass http://192.168.51.95:8080/ai_wm/Main.do;}# 认证失败处理location @error401 {add_header Set-Cookie "NSREDIRECT=$scheme://$http_host$request_uri;Path=/";return 302 http://192.168.51.95:8080/ai_wm/aidl.do;}location /api {proxy_pass http://192.168.0.197/api;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}location /console/api {proxy_pass http://192.168.0.197/console/api;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}location /_next {proxy_pass http://192.168.0.197/_next;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;}# 这表示对根路径的请求进行处理。所有未匹配到其他 location 块的请求都会被此块处理。location / {# 将请求代理到本地的 Tomcat服务器proxy_pass http://127.0.0.1:8082/;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header Cookie $http_cookie; # 确保转发 Cookie}error_page 500 502 503 504 /50x.html;location = /50x.html {root html;}}
配置内容解读:
基本设置:
listen 8080;: 服务器监听 8080 端口。
server_name localhost;: 服务器名称为 localhost。
路径 /ai_wm/apps/dify 的处理:
认证请求: 使用 auth_request /auth; 指令在处理用户请求前进行认证。
错误处理: 如果认证失败,返回 401 错误码,并重定向到 @error401 处理。
请求转发: 认证通过后,使用 proxy_pass http://192.168.0.197/; 将请求转发到指定的后端服务器。
请求头设置: 使用多个 proxy_set_header 指令设置请求头信息。
路径重写: 使用 rewrite ^/ai_wm/apps/dify/(.*)$ /$1 break; 将请求路径从 /ai_wm/apps/dify/xxx 重写为 /xxx。
认证服务 /auth 的设置:
内部调用: 使用 internal; 指令声明该路径仅限内部调用。
请求体处理: 使用 proxy_pass_request_body off; 不转发请求体到认证服务。
认证请求转发: 使用 proxy_pass http://192.168.51.95:8080/ai_wm/Main.do; 将认证请求转发到指定的认证服务。
认证失败处理:
重定向: 使用 location @error401 处理认证失败的请求,设置 Set-Cookie 头,并重定向到指定的 URL。
其他路径的代理设置:
/api, /console/api, /_next: 分别被代理到不同的后端服务,设置了请求头信息。
根路径 / 的处理:
请求代理: 将根路径的请求代理到本地的 Tomcat 服务器 http://127.0.0.1:8082/。
请求头设置: 设置了多个请求头信息。
错误页面处理:
错误页面: 使用 error_page 500 502 503 504 /50x.html; 指定错误页面。
错误页面路径: 使用 location = /50x.html 指定错误页面的路径。
其他说明:
nginx部署的服务器ip为92.168.51.95,dify所在的服务器ip为192.168.0.197
Tomcat的端口为8082
4.调整iframe的请求地址
一开始,iframe的地址如下图所示:
结合上一步中nginx配置的路径,只有请求地址中带有/ai_wm/apps/dify路径的请求,才会进行身份认证,所以要调整iframe的URL,把URL改成一个相对地址,如下图所示:
通过以上调整,结合nginx配置,最终,认证通过后,请求的地址还是原来的dify访问地址,也就是说dify不需要做任何调整,只需要配置好nginx即可。
以上操作完成后,把iframe的URL中地址,进行访问,在系统没有登录的情况下,nginx会进行拦截。
此时,完成系统登录操作,再次访问,就可以正常访问到dify了。
解决了身份认证的问题,没有登录的用户无法访问到dify。
5.nginx操作命令
以管理员身份打开cmd命令窗口,进入到nginx目录中,执行相关命令
修改了配置文件,重新加载nginx
nginx.exe -s reload
停止nginx
nginx.exe -s quit
6.常见问题排查
若代理失败,检查以下内容:
NGINX日志(logs/error.log)是否有错误。
防火墙是否允许相关的端口。