@WenJimmy

知乎之前不也爆过嘛。

这种事，可大可小。

毕竟哪怕有 sourcemap 也大概率没办法轻易还原整体项目。

@FrankHB

估计是业务不考虑其他国家？

不然绝对要命，这个逻辑太鬼才了。

@OkabeRintaro

算不上大佬，不过确实踩了不少坑。

有 sourcemap 你要知足，没 sourcemap 我都搞过。

之前闲的没事接了个小的外包单子。

vue + php ，前任跑路了要加功能，连个 sourcemap 也没留下。幸好功能不算复杂(前端没多少代码，主要在后端)，照着打包后的 js 文件重写了一遍。

那感觉，生不如死，不过倒也接触到了不少新知识。

发了上面这些，就想告诉你一件事。

这玩意，如果你 souercemap 和打包后项目文件完整，是可以跑起来的。

但是你要做的事情非常多，时间精力消耗很大。

不是有 sourcemap 就能万事大吉，完整 sourcemap 只是给你个可能性。

对了，还有个问题。

你在 sourcemap 找到的 image 等文件，大概率不是直接可用的。

webpack 什么的会搞个花活，那里面并不直接是文件内容，而是一段 js ，js 里面才会写真实路径。

大文件会指向打包后项目代码的 url(如 images/some_source_name.random_id.ext_name)，你得手动下载下来替换。

小文件会直接 base64 编码成 data url ，提取出来替换就可以了。

以前测试过用 sourcemap 逆向 vue 项目。

得出的结论是，这玩意要能跑起来可完全不容易。

假设你拿到的 sourcemap 是完整可用的，那么你会遇到如下问题:

1. 独立的 css/less/sass/scss 文件大概率是不存在的，如果很不幸你遇到了 import 这些文件而不是直接写在 vue 的话，你需要去打包后的 css 里手动提取出来。稍微庆幸的是，除非全局引入，不然每个页面的样式基本都会是同一个 data-v-id 。

2. sourcemap 解包后可能会出现带后缀以及不带后缀的文件，你需要自行挑选出来原始文件，但在我个人经验上，基本都是无后缀的是原始文件。

3. vue.config.js ，起码我没见到过有的，大概率得手动写一下。

4. package.json 是不可能有的，这个你纯粹想多了，真正的难点也在这里，你需要去可能非常不全的 node_modules 目录里手动逐个查依赖，这个过程很费劲，因为有些时候你可能找的一头雾水，这个时候就得试着把项目跑起来按照报错找依赖。

各大打包工具对 sourcemap 都是抱着调试的用途去生成的，根本不可能把开箱即用的项目代码扔进去，找思路可以，原样跑起来非常费劲。

@sadfQED2 老哥啥时候离职的？现在也是这样吗？震惊。

这技术架构也忒老了，用的自研的 php 框架吗？

@minilei 你重装系统没备份 /etc/pve 目录吗？

没记错的话那里面好像也存放了虚拟机配置文件。。

那么问题来了，程序的调度方案是怎样的？

程序该怎么去选择存储地点以及该怎么去下载你的文件？

这个程序很难写，很多厂商都不给普通用户提供接口，全得自己抓包，但抓包出来的接口可用性以及稳定性又十分堪忧。

各大厂商功能实现的也不同，而且还要考虑到可能的限速 /限流问题。

如果你有临时修补方案，请谨慎公开漏洞细节和 POC ，因为某些用户可能无法及时了解到该信息并予以修补。

如果你没有临时修补方案，请永远不要公开漏洞细节和 POC ，厂商不负责任不代表用户需要承担因你而造成的风险。

一旦公开漏洞细节和 POC ，该漏洞的利用门槛将显著降低。

前几楼老哥已经发了相关地址了，建议向上级反馈推动厂商积极性。

感谢你做出的努力。

说真的，个人对 OP 有点疑惑。。

刚注册的新号。

第一贴和第一个回复都是在这个帖子。

帖子内容还是自媒体这种鱼龙混杂的行业。

感谢分享，但是个人认为这种场景下使用服务端渲染意义似乎不算特别大。

1. 生成会比原来多发一次请求，这样本地的用户信息缓存就用不太上了，还是需要等服务端生成后传过来数据，有一定延迟。

2. 不管再怎么高性能高并发，它也仍然需要单独部署占用资源，请求量比较大的时候还是会对整体有影响，不利于优化，能在客户端做的事情还是在客户端做比较好。

感谢，以后再也不发涩图了。

@LeeReamond

它主要面向的人群是非专业客户。

干开发的不都是自己配开发环境跑吗，用得到这个？

运维用这个的话不可控因素太多了，而且部署方式非常局限。

奇怪。。好像刚才发的不可见了？

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你假设的这种情况。

你不理解的原因，是因为你把 组织 的权限管理定位在了 开源爱好者组织。

实际上，组织 的权限管理设计主要照顾到的是企业 /独立团队等商业化客户，这种客户一般不会存在你所谓的因为得罪 org owner 被 delete 掉仓库的假想情况。