laozhoubuluo

两个不同的域名，肯定是不能直接读取 Cookie 的。
只能是在 domain-1.com 的前端上让 jQuery 去请求一个 domain-2.com 的接口，让他把 domain-2.com 上的 test Cookie 发过来，完了 domain-1.com 前端再根据返回值决定业务状态。
拿到返回值之后，不管是写到 domain-1.com 的 cookie，还是直接拼接到请求里面提交给后端都可以。

楼上说了 SSO 的思路，不过看楼主说领导不愿意上，那就只能想点讨巧的办法解决了。

首先如果不想所有的接口都做 loading 页面，可以考虑每个应用自行维持一个状态（比如请求其他业务的注册状态接口，前后端均可，这个楼主自行考量要不要解耦到这个层级，感觉楼主不愿做），如果不愿做只能是所有需要数据同步的链接上面挂上全量的基础信息（但不包括安全类信息，比如密码或者私钥）。

随后修改所有项目的前端入口点，支持以下流程。

1. 如果一个请求存在基础信息的主键（比如手机号 /身份证号 /集团项目 ID ），就判断当前用户是否是基础信息主键所涉及的 ID，是就走正常业务逻辑，反之就登出当前用户。

2. 请求应用自身的后端接口判断主键是否注册了，如果已经注册就渲染登录页面要求用户登录，登录成功之后走正常业务逻辑即可。

3. 如果没有注册，就渲染一个特殊的注册页面，基础信息自动带入跳转过来的基础信息，只需要用户完成安全类信息的填写（比如密码、私钥、短信验证码）。

4. 用户点击提交发起注册，注册成功之后走正常业务逻辑即可。

好像文档系列的都这个样子，腾讯文档在 Firefox 上也是各种卡顿。
不知道是基础框架类似还是细节太多导致大家不约而同砍了 FF 支持。

这种建议三步走:

1. CDN 上配置爬虫黑名单 IP 地址.
2. 源站基于 ngx_http_realip_module 配置规则, 只信任 CDN 提供的 XFF 头.
3. 源站在 2 生效的基础上, 配置爬虫黑名单 IP 地址, 或配置仅允许 CDN IP 访问.

@m4d3bug “不止 5 年” 来源请求，毕竟 https://centos.org/distro-faq/ 官方页面说的 5 年支持期。

另外 CloudLinux 也宣称自己要开发类 CentOS 的系统，会不会和 Rocky Linux 合流还有待观察，详情请见 https://blog.cloudlinux.com/announcing-open-sourced-community-driven-rhel-fork-by-cloudlinux

建议台式机做 Windows 或者 MacOS，取决于您的需求 ，毕竟虚拟化系统显示方面太受限了。
工作站的话取决于您了，如果怕折腾或者有不希望 SLA 太难看的服务就选 ESXi 保证稳定性，如果不怕折腾且不希望牺牲图形性能的话就考虑 Debian / Ubuntu + KVM / Docker 。

@Oucreate

1. 这个各地政策不同，比如北京联通就不存在不经过装维体系获得光猫的官方合法渠道。基本流程是根据局端设备兼容性以及业务需求将设备配送到属地（北京俗称电话局），通过属地直接下发给装维人员进行安装。
2. 如果怀疑塑料封膜的话，营业厅体系、终端采购入库体系甚至 ITMS/RMS 体系（三套体系都很大，经手人都很多）同样可以做手脚，毕竟能做手脚的地方太多了。

@KKLeon 不要白不要，填个表单五分钟，给了就赚了，不给也不亏。另外现在新网址是 https://yhssglxt.miit.gov.cn/

白嫖 RHEL 稳定版机会结束了。
当然推动存量系统升级的能力增强了。