besscroft
bug: 登录 Auth 的优化
目前的问题
- 实现太复杂
- 因为目前实现的关系，密码错误的时候，会直接在服务端返回 500，并且抛出无法理解的报错信息，这一点是非常不对的
我倾向于使用 https://lucia-auth.com/ ，实现更为简单，2FA 也有良好支持 https://github.com/lucia-auth/example-nextjs-email-password-2fa
直接把这个 issue assign 给我吧，我把这块重构下
我当初用 auth.js 是因为 Learn Next.js 里面用的就是这个，比较能很好的配合 middleware 来做各种功能，但是 auth.js 的实现确实是挺复杂的， 有些逻辑处理不好像后端语言那样做，是有点难受。
我大致看了下您发的 example 的 repo 的代码，也能够在 middleware 判断是否登录（auth.js 是用 req.auth 判断）。如果有更简单的方案的话，我觉得是可以的，麻烦您了！
如果重构这块功能，我看了下即使这部分数据库表全部换掉，也是不会影响业务表的。无非就是更新版本后，用户重新设置下密码和 2FA，是可以接受的。您在处理时可以注意规避下 edge 运行时的问题。
@slept-yogurt 免费的服务没法要求更多的，不稳定也没法说啥。不过建议您查看 supabase 的数据库所在 region，然后调整您 vercel 项目的 Function Region 至相应区域，可以适当缓解该问题。
例如 supabase 的 region 在 AWS | ap-northeast-1，代表服务器所在区域为 Asia Pacific (Tokyo)，那么 vercel 的 Function Region 可以选择 Tokyo, Japan (Northeast) – hnd1，来尽量消除因物理距离上太远导致的高延迟以及路由过多线路切换导致的丢包问题。
当然您也可以选择用
TraceRoute来测试最优路线，有的路线可能远了点，但是走的路由线路不错（比如走了 AWS 自家专线，那么肯定就比 NTT 线路好），也是可选的方案。
升级到最新的 2.1.3
还是会报错，而且域名访问也有问题 比如图片不显示等，可能是我的环境问题吧```
x-forwarded-hostheader with value113.45.1.202does not matchoriginheader with valuepic.grer.cn` from a forwarded Server Actions request. Aborting the action.
⨯ [Error: Invalid Server Actions request.] { digest: '3382743406' }
你这个应该是跨域配置的问题，你可以发一下你配置和你站点的域名我看看
不太理解您说的配置是哪儿个配置，项目使用docker部署的compose配置:
services:
psql_pic:
image: postgres:16
container_name: psql_pic
env_file:
- .env
restart: always
volumes:
- ./data/_db:/var/lib/postgresql/data
picimpact:
image: besscroft/picimpact
container_name: picimpact
depends_on:
psql_pic:
condition: service_healthy
ports:
- "9030:3000"
environment:
DATABASE_URL: postgresql://postgres:${POSTGRES_PASSWORD}@psql_pic:5432/${POSTGRES_DB}
AUTH_SECRET: "minamejialaguri"
restart: always
logging:
driver: json-file
options:
max-size: "5m"
max-file: "3"
nginx配置:
#PROXY-START/
location ^~ /
{
proxy_pass http://113.45.1.202:9030;
proxy_set_header Host 113.45.1.202;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header REMOTE-HOST $remote_addr;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_http_version 1.1;
# proxy_hide_header Upgrade;
#Persistent connection related configuration
add_header X-Cache $upstream_cache_status;
#Set Nginx Cache
set $static_filebfJwjyDE 0;
if ( $uri ~* "\.(gif|png|jpg|css|js|woff|woff2)$" )
{
set $static_filebfJwjyDE 1;
expires 1m;
}
if ( $static_filebfJwjyDE = 0 )
{
add_header Cache-Control no-cache;
}
}
#PROXY-END/
@iguri 我看了下您的配置，似乎是服务器 A 反代了服务器 B 上的容器这种形式？虽然我没这么用过，但是我有几个建议的地方，您可以尝试一下：
1、设置 proxy_set_header X-Forwarded-Host $host;，尝试保持域名一致。
2、这个跟上面同理，因为框架我们采用的是 next.js，所以需要配置 allowedOrigins 来确保相同来源，因为 next.js 要匹配来防止 CSRF 攻击，这个可能需要您自己配置后去打包（毕竟大部分项目，我想都不会默认加上这种配置吧，或者说不是很建议。详见：https://nextjs.org/docs/app/api-reference/config/next-config-js/serverActions#allowedorigins
参考代码如下：
/** @type {import('next').NextConfig} */
module.exports = {
experimental: {
serverActions: {
allowedOrigins: ['my-proxy.com', '*.my-proxy.com'],
},
},
}
当然，您可以测试“代理链路”，来判断到底是哪个环节出现了问题。
@iguri 我看了下您的配置，似乎是服务器 A 反代了服务器 B 上的容器这种形式？虽然我没这么用过，但是我有几个建议的地方，您可以尝试一下： 1、设置
proxy_set_header X-Forwarded-Host $host;，尝试保持域名一致。 2、这个跟上面同理，因为框架我们采用的是 next.js，所以需要配置allowedOrigins来确保相同来源，因为 next.js 要匹配来防止 CSRF 攻击，这个可能需要您自己配置后去打包（毕竟大部分项目，我想都不会默认加上这种配置吧，或者说不是很建议。详见：https://nextjs.org/docs/app/api-reference/config/next-config-js/serverActions#allowedorigins参考代码如下：
/** @type {import('next').NextConfig} */ module.exports = { experimental: { serverActions: { allowedOrigins: ['my-proxy.com', '*.my-proxy.com'], }, }, }当然，您可以测试“代理链路”，来判断到底是哪个环节出现了问题。
感谢指正，确实是我反代写乱了
