关于离线使用的建议

[qwz873112851]

当特殊环境需要使用离线功能时，所引入的fullpage.js 还是通过第三方地址‘https://static.geetest.com/static/js/fullpage.0.0.0.js’来引入的，包括css和img也是如此， 当离线使用时，是否可以通过本地保存来进行，因为有时候需要内网使用，在不将geetest.com添加进白名单的时候，无法使用该插件功能

[RYefccd]

      你好. 验证码3.0的容灾模式受限于早期的设计, 在业务流程的初始化引导时对于静态文件的处理确实有一些弊端. 除此之外，加载fullpage.0.0.0.js时需要客户的服务端在使用服务端sdk发起register请求失败时, 往前端返回 success:0 才会 进入failback模式加载fullpage.0.0.0.js 很多时候，客户的这个请求一旦没有失败，failback模式便无法生效. 为了根除这种问题, 验证码4.0在设计时就考虑了这些情况. 将容灾的js做到了最开始的那个gt.js 中. 所以， 建议您部署我们的验证码 4.0, 在功能的扩展, 报表的展示, 全球服务支持都更符合当下的需求. 这里是4.0的文档:  https://docs.geetest.com/gt4/deploy/server/csharp 谢谢您的反馈. 

…

------------------ 原始邮件 ------------------ 发件人: "GeeTeam/gt-java-sdk" ***@***.***>; 发送时间: 2022年7月22日(星期五) 下午3:50 ***@***.***>; ***@***.***>; 主题: [GeeTeam/gt-java-sdk] 关于离线使用的建议 (Issue #8) 当特殊环境需要使用离线功能时，所引入的fullpage.js 还是通过第三方地址‘https://static.geetest.com/static/js/fullpage.0.0.0.js’来引入的，包括css和img也是如此， 当离线使用时，是否可以通过本地保存来进行，因为有时候需要内网使用，在不将geetest.com添加进白名单的时候，无法使用该插件功能 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[qwz873112851]

感谢您的回复，这种容灾方式无法仍然处理当前所遇到的开发环境，4.0版本容灾时仍然需要加载一个第三方域名的js（图一），当我们只能访问固定域名的网站时，还是无法正常运行。图二为通过浏览器屏蔽地址后的情况

[RYefccd]

你好, 在附件中有如何进行配置bypass.js本地化的方式. pdf 中原来的视频有9M, 我截了关键的一帧.  感谢您的反馈. 也想和您探讨一下容灾的设计. 为了避免容灾过程中的"鸡生蛋, 蛋生鸡"这种循环依赖, 未来会考虑gt4.js和bypass.js融合在一起的方案. 容灾的本质就是前端请求不阻塞业务流程, 客户服务端的验证请求也不阻塞客户服务端业务流程. 在正常的模式中, 验证成功会返回一个pass_token的签名串. 在容灾模式下(网络故障)前端会随机生成一个pass_token串, 这样的pass_token串肯定不能通过极验服务端校验, 因为正常情况下的 pass_token 是由客户的secret_key使用hmac算法生成的. 之所以这么设计, 也是避免在客户端曝露 pass_token 的生成逻辑; 某种意义上也无法区分真正的网络故障和黑客伪装的网络故障. 网络故障时, 客户端随机生成 pass_token 后, 不阻塞客户端业务流程. 在服务端二次校验时会失败, 如果是地区网络故障, 我们会提供运营去开启开关, 此刻不校验 pass_token 的签名有效性. 等故障处理后, 再次关闭此服务端请求容灾开关. 避免黑客可以伪装网络故障攻击. 上次回复您, 说到验证码v3的一些设计问题, 很大一部分就在容灾这里的设计, 很多循环依赖导致容灾模式生效时机苛刻, 难以稳定使用. 除此之外, 在验证码v4的设计中, 我们还做了很多结构上的改进, 验证流水号随参数序列化, 不存储在中央数据库中, 这样验证码的问,答, 二次校验请求 可以分别发送到离客户最近的极验服务节点进行处理, 提高响应速度, 降低网络故障风险. 验证码的资源图片和服务绑定在一起, 图片路径利用cdn加速, 回源至动态服务器, 把静态文件和动态请求都放在同一个服务中, 让服务和服务资源同时就绪, 这种standalone的设计使得更容易在全球节点去部署和恢复服务. 风吹草低 ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: "GeeTeam/gt-java-sdk" ***@***.***>; 发送时间: 2022年7月28日(星期四) 下午4:39 ***@***.***>; ***@***.******@***.***>; 主题: Re: [GeeTeam/gt-java-sdk] 关于离线使用的建议 (Issue #8) 感谢您的回复，这种容灾方式无法仍然处理当前所遇到的开发环境，4.0版本容灾时仍然需要加载一个第三方域名的js（图一），当我们只能访问固定域名的网站时，还是无法正常运行。图二为通过浏览器屏蔽地址后的情况 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>