最近接触到两个网站的重建，过程十分有趣，文字记录一下吧，虽然没有图片，但如果以后你也碰到类似的，应该能理解。

说明

• 两个网站是一起的，依赖的基本项目是一样的。
• java项目，采用docker，多服务器，主从。
• 有连接rds等
• 网站采用验证码登录
• 重构环境要求断网环境

网站一

记录所有服务器的内网IP，根据对应的网段，为所有服务器添加对应ip的虚拟网卡，确保在IP地址不变的基础上，大家可以互联互通。

还原rds备份，并修改各个服务器的hosts，将rds地址重定向到还原好的数据库中，确保可以正常连接。

redis同理，按照配置文件启动一个即可，有密码就配置密码，一样要修改hosts。

网站一启动主要是需要先启动几个基本项目，docker直接启动即可。

其中存在一个config项目，此项目会从git仓库中拉取对应项目的yml配置文件，config没有正常启动的话，其他项目都无法启动。

• 其余项目启动时会找config要配置文件，此时config会从git仓库拉取
• docker中虽有编译好的config，但它每次还是要从仓库中拉取文件，而不是返回自身jar包中的文件
• config的配置文件中已有仓库地址及账号密码

config正常启动方式

• 本地部署gitlab，配置好对应的域名、账号与密码
• 按照请求的项目路径分别创建组和项目
• 反编译config的jar包，将文件上传至gitlab的config项目
• 启动config的docker容器
• 通过调试/日志中请求的地址尝试请求一次yml配置文件，成功即可

启动前端，一般都是用的nginx，注意观察配置文件，以便修改本机的hosts。

后台登录只能验证码登录，但是看后台接口发现，有一个type值，值为1走密码登录，其余走验证码登录，这估计是从前可以使用不同的方式登录，后面就去掉了账号密码登录，但是服务端还没有改。

通过抓包发现前端发送请求，值固定为2。

bp拦截，修改type值为1后，可以正常触发账号密码登录， 而不是手机验证码登录。

浏览器查看源码，得知type值被写死为2，在服务端修改源码，将值写死为1，然后清除浏览器对这个文件的缓存，即可正常账号密码登录。

java网站的密码加密方式，有多种解决方法。

1. 直接抽出加密代码，本地运行，得到想要的密文。
2. 分析加密逻辑，模拟加密行为。
3. 通过项目日志或者mysql的general_log，有时会以目前输入的密码的密文为查询条件或者日志给出。

网站二

大致逻辑与网站一相同，不过在服务端有专供账号密码登录的接口，直接访问就可以绕过手机号验证码登录。

不同的是，在登录验证密码后，会向一个地址请求token，该地址不在掌握的资产当中，也没有固定下来。

通过分析代码， 知道其请求返回的内容大致如下

{
  "code":代码值,
  "user":{
    "token":token值
  }
}

解决方式：

1. 使用tcpdump进行抓包，分析出发送的请求的结构
2. 使用Django进行接口开发， 对上述请求进行接收，并返回一个合理的数据，使项目可以正常获取token，暂时不去关心token如何生成，有一个值即可
3. 在gitlab中修改这个项目的配置文件，将请求的地址改到django项目所在的地址
4. 本地模拟一下请求，能够正常返回后，再尝试登录