@zsh2517 #40 提到的 caddy-security 看起来能满足反向代理的要求。看具体需要吧

如果要把反向代理仅作为外网入口的鉴权，那么一台服务器跑反向代理，其他走内网访问就行。
不过我希望的是每个机器上的服务在内网也无法直接访问。这个时候可能需要每台设备跑一个反代了

@WashFreshFresh #35 看了一下，项目本身似乎挺不错的。可惜我不写 Java ，而且需求似乎对不上 😂

目前的思路大概是：选择一个可信的 OAuth2 （ OpenID Connect ） 三方平台。然后 golang （无运行时依赖）实现一个轻量、单文件（方便部署）的反向代理。未登录时强制 OIDC 登录。登录后在白名单的用户反向代理，不在白名单的用户 403 Forbidden 。这样就可以很简单地实现认证后访问。

目前已经跑通流程了，但是反代代码是 GPT 写的，能跑但是还没仔细读，不知道有没有 bug 。

后期可能（但不一定）会把 OAuth2 的提供者换成 keycloak 之类的专门的服务；以及解决配置文件分发的问题（几台虚拟机，十几个服务）

@hshe
@int80

本来我还在想，怎么我没看到广告。然后突然想起来开了 adguard 。
关掉之后刷新，确实 CSDN 都没这么多广告（至少人家不会在正文里面加三方广告）

@zsh2517 都是 web 服务（ http, https, ws, wss ）。对于 tcp/udp 类的我没太考虑过

目前公网统一的入口，走 nginx + Basic Auth 转发到内网里面的一个 Nginx Proxy Manager ，它再分发到具体服务上。
内网里面基本没有鉴权（有通常也是弱密码）。只有极个别服务是强密码验证（比如 pve 的 web UI ）

---
目前个别服务（支持 OAuth2/OpenID 登录的），接入了 GitLab 作为第三方登录。
后面计划改成每个服务均绑定 127.0.0.1 ，然后前面套一个轻量的鉴权网关（可能支持 oauth/passkey/password 三种验证）。但是懒得写又没找到合适的开源项目（ 天天在 V2EX 打广告的 casdoor 似乎可能满足需求，但是之前部署过一次文档质量有点差），就一直咕咕咕了

网络设备不太建议和别的东西放在一起。风险比较大（纯 NAS + 路由器还好，All-in-one 非常不建议）

比如，NAS 升级或者调整设置的时候，可能会导致 VM 中断，VM 中断又会导致网络问题。升级失败/网络不通无法远程管理/需要手机开热点搜解决方案等

@cheung
@lanthora #9

让我想起来，Debian 系（如 Debian, Ubuntu ）有一个叫做 docker 的包， 好像是和一些桌面的 dock 栏有关。

我不止一次 sudo apt install docker 安装完，发现装错了，卸载换 docker.io 了😂

@zeyexe
@l4ever

#1 的意思，我觉得是在说，如果在业务场景下，需要表示『这里应当是一个数组/列表，且目前数组里面，没有元素』，这个场景下，建议返回 [] 而不是 None 。

如果 None, [] 有不同的语义，那么还是要看实际情况

看错标题了😂点进来之前我以为是那个 web 服务器（ caddy ）的 web UI.

保存一下，后面有需求有时间了试试，目前我还是用的 wireguard （没过境还是挺稳定的）

@bug51 #5 前端考古 有链接吗，想去围观一下

@icaolei 之前有过一个想法，是否可以把各种镜像进行规范整理，开源一组可以配置的 nginx/caddy/其他 配置文件。总之尽量做到几分钟能建立起来一个基于反向代理 + 缓存的内网镜像服务，各项参数如缓存大小、索引文件缓存时间、数据文件缓存时间、子目录/域名，是否代理发布能力等。这样个人或者组织内随便找台闲置的机器都能快速建立起来一个内网镜像站。

我没深入了解过，不知道是否有现成的解决方案了（主要是简单、通用）。之前 xzutils 那次，proxmox 里面十几个 debian 12 镜像挨个升级的时候想到的

> 是否可搭建一个公开的、用户可监督的镜像站？需要加速什么资源，直接提 pr ，合并后开始加速？所有被加速的资源都是公开的，可被监督的。

用来对外提供服务的设施（服务器、CDN 、对象存储）的所有权是项目 owner 的，而且 owner 不可能给每个人登录和审查的能力。只要想做，他完全可以去存储缓存的地方进行修改。

昨天似乎就是有人曝光 51la, staticfile CDN 和 BootCDN 导致 V2EX 和作者博客被攻击（ V2EX 据说昨天挂掉是因为这个），帖子链接 /t/1057993 文章链接 /t/1056428

@yegar #28 姓名泄露基本上没有什么影响。举个栗子，国内的开发者，很多人的姓名都是泄漏了的。国内基本躲不开备案，能找到一个有备案网站的话（现在还有应用、小程序），个人备案直接是姓名；为了资质注册了公司，很大概率法人或者股东等能找到人。
再比如大一些的社交媒体账号（粉丝数量超过多少），现行政策要求前台能查到运营者的实际名称。

@zsh2517 我最近在学 php 就是这样的。
官方文档、poe.com ，以及 phpstorm 。写完运行看结果（目前阶段命令行运行就够），文档没看懂/逻辑有问题复制问 GPT

Golang 不熟，react 的话，装 node 20 或者 22 的环境，然后按照这里创建一个 react 项目（ https://cn.vitejs.dev/guide/#scaffolding-your-first-vite-project ），命令：npm create vite@latest my-vue-app -- --template react 。试着运行起来（应该不会出意外）

然后，打开 GPT ，再打开 react 文档，跟着写就可以。vite + react 项目是有热更新的，保存就能看到效果。不会随时问 GPT

@78786381 #3 补一张图


@me1onsoda #174 @brader #181

防止资源注入主要是 CSP （内容安全策略）吧。写插件或者 user script 的应该遇到过。简单说是网站可以声明自己页面内允许的外部资源域名，不在域名内的会上报或者拒绝加载。
至于跨域的安全体现在哪，这个还真没仔细考虑过。刚才找 GPT 问了一下，沿用 #181 的例子，前端 a.com ，后端 b.com ，恶意网站 xx.com 。拦截的是从外部前端发到自己后端的情况

异常情况：假如没有 CORS 策略，且 b.com 的 cookie 设置了 samesite: None 。那么在 xx.com 就可以构造一个 fetch('https://b.com/someapi', {credentials: 'include'})，进而请求到 b.com 的数据。
而如果有 CORS 策略，在 options 预检请求时，b.com 的后端检测到非同源可以返回拒绝；或者返回固定的同源策略，比如 Access-Control-Allow-Origin: https://a.com ，浏览器也会拒绝 xx.com 的请求。

如果 a.com 请求 b.com 的话，因为 b.com 的 CORS 头说明了允许 a.com 、使用 XXX, YYY 方式请求，允许的 headers 是哪些……，如果 a.com 按照规则来，浏览器就不会拦截。

---

另一种情况，假如 a.com 被恶意注入了发往 xx.com 的资源。这个时候 a.com 请求 xx.com 是靠 xx.com 的 CORS 判定的，拦不住。用到的应该是 CSP 。例如 Content-Security-Policy: connect-src 'self' https://b.com;

@raviscioniemeche #123 前段时间做一个东西因为 emoji 表现问题改了好几次实现。然后最近闲下来，深入了解了一下 unicode 、emoji 与 UTF-X ，发现这玩意是个大坑。

而且更坑的一点是，很多平台特性实现不完全，以至于本来我想在笔记里举个例子，结果举出来的展现不出来😂

@caomingjun +1 ，我一般只有在 ssh 的时候用（例如拉东西、装依赖等，能保证本地和远程有一条隧道），然后 -R7890:127.0.0.1:7890 把本地的 7890 转发到远程配个环境变量就行。没有在远程装过

如果硬性需要代理，要么扔境外服务器，要么扔本地 pve 跑