Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Feature] 🌈 无后端, 完全 Cloudflare Worker 部署 #71

Closed
Harry-zklcdc opened this issue Aug 2, 2023 · 40 comments
Closed

[Feature] 🌈 无后端, 完全 Cloudflare Worker 部署 #71

Harry-zklcdc opened this issue Aug 2, 2023 · 40 comments
Labels
documentation Improvements or additions to documentation

Comments

@Harry-zklcdc
Copy link
Owner

Harry-zklcdc commented Aug 2, 2023 •
edited
Loading

经过一天研究，实现了完全 Cloudflare Worker 部署

Commit: 57d105d

部署方式

核心代码 worker.js

具体部署 Cloudflare Workers 教程自行查询，大概如下

  1. 注册 Cloudflare 账号；
  2. 创建 Worker 服务；
  3. 复制 worker.js 全部代码，粘贴至创建的服务中；
  4. 修改最上面的两个Cookie变量；
  5. 保存并部署；
  6. 触发器 中自定义访问域名。

已知问题

  • 无法获取历史聊天记录
@Harry-zklcdc
Copy link
Owner Author

Harry-zklcdc commented Aug 2, 2023 •
edited
Loading

测试地址：https://bingai-cfwk.xiao-gy.tk/web/#/ 轻虐，谢谢

注意：已删除共享Cookie代码，需要自行填入对应Cookie方可体验

@Harry-zklcdc Harry-zklcdc mentioned this issue Aug 2, 2023
Open
@standee2023
Copy link

太棒了，等待更新

@s181462537
Copy link

已尝试，这个部署厉害！建议能不能再加点代码，_u值也写进去啊，想给身边人用，写进去就可以不用在外面输入_u值了

@Harry-zklcdc
Copy link
Owner Author

已尝试，这个部署厉害！建议能不能再加点代码，_u值也写进去啊，想给身边人用，写进去就可以不用在外面输入_u值了

改点代码就行了，仿照 _RwBf 的那个Cookie的写法就行

go-proxy-bingai/cloudflare/worker.js

Line 3 in 57d105d

const _RwBf = 'xxx'

go-proxy-bingai/cloudflare/worker.js

Lines 150 to 152 in 57d105d

if (!cookie.includes('_RwBf=')) {
cookies += '; _RwBf=' + _RwBf
}

@s181462537
Copy link

改了代码，果然就可以了，真棒！

@SokWith
Copy link

SokWith commented Aug 2, 2023

我觉得思路还可以继续打开，NewBingGoGo的插件版采用的是整个cookie拷贝进cf服务器的路子，只有不触发服务器ip锁(PS，悄悄的说一下，把转发ip地址池缩小到微软云IDC范围内，能大幅度规避ip锁)，基本上就可以保证cookie策略随微软的变化自动变化。
（可惜他放暑假后就没有跟随官方的api进行同步更新了。也幸好官方的核心api没有什么大变化，还能一直使用。）

@Harry-zklcdc
Copy link
Owner Author

我觉得思路还可以继续打开，NewBingGoGo的插件版采用的是整个cookie拷贝进cf服务器的路子，只有不触发服务器ip锁(PS，悄悄的说一下，把转发ip地址池缩小到微软云IDC范围内，能大幅度规避ip锁)，基本上就可以保证cookie策略随微软的变化自动变化。 （可惜他放暑假后就没有跟随官方的api进行同步更新了。也幸好官方的核心api没有什么大变化，还能一直使用。）

插件版在做了，为了实现edge侧边栏可以搜索页面的，不过估计要下个礼拜了，这个礼拜有其他的事情，手上还有一个大模型的项目在开发

This was referenced Aug 3, 2023
Closed
Closed
Closed
@Harry-zklcdc Harry-zklcdc added the documentation Improvements or additions to documentation label Aug 3, 2023
@Xqh-Cxy
Copy link

Xqh-Cxy commented Aug 3, 2023

经过一天研究，实现了完全 Cloudflare Worker 部署

Commit: 57d105d

部署方式

核心代码 worker.js

具体部署 Cloudflare Workers 教程自行查询，大概如下

  1. 注册 Cloudflare 账号；
  2. 创建 Worker 服务；
  3. 复制 worker.js 全部代码，粘贴至创建的服务中；
  4. 修改最上面的两个Cookie变量；
  5. 保存并部署；
  6. 触发器 中自定义访问域名。

已知问题

  • 无法获取历史聊天记录

什么原理啊，不是被ban IP了吗？

@SokWith
Copy link

SokWith commented Aug 3, 2023

经过一天研究，实现了完全 Cloudflare Worker 部署
Commit: 57d105d

部署方式

核心代码 worker.js
具体部署 Cloudflare Workers 教程自行查询，大概如下

  1. 注册 Cloudflare 账号；
  2. 创建 Worker 服务；
  3. 复制 worker.js 全部代码，粘贴至创建的服务中；
  4. 修改最上面的两个Cookie变量；
  5. 保存并部署；
  6. 触发器 中自定义访问域名。

已知问题

  • 无法获取历史聊天记录

什么原理啊，不是被ban IP了吗？

测试服务器的ip是不是被ban了有个简单的方法，就是使用NewBingGoGo的插件版，魔法链接填服务器的网址，采用魔法聊天。确保你的ID没锁的情况下，显示服务器异常，则为ip锁了。
用cf的好处是，锁了ip不可怕，只要重置，一般几次后就可以后台自动更换了另一个ip。cf的地址池足够大，总会没有被锁的。

@SokWith
Copy link

SokWith commented Aug 3, 2023

按此方法新建的一个站点，跟踪一下存活情况：

https://cfwk.nbing.eu.org/

作者的测试站点是被多人访问，还是比较容易ip锁的，今晚已经被锁了1次了。

@SokWith
Copy link

SokWith commented Aug 3, 2023

按此方法新建的一个站点，跟踪一下存活情况：

https://cfwk.nbing.eu.org/

作者的测试站点是被多人访问，还是比较容易ip锁的，今晚已经被锁了1次了。

我两个用cf做后端,前端分别在vercel和replit上的站点：
https://vercel.nbing.eu.org
https://replit.nbing.eu.org
今天一直正常。
但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

@Harry-zklcdc
Copy link
Owner Author

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端,前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。 但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

@SokWith
Copy link

SokWith commented Aug 3, 2023

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端,前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。 但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

谢谢。我不会编码，帮不上什么忙，你辛苦了。

@Harry-zklcdc
Copy link
Owner Author

谢谢。我不会编码，帮不上什么忙，你辛苦了。

还是Cookie的问题，NewbingGoGo我研究了一下，他是直接拿的完整Cookie，所以没有那么容易触发验证，但是这样不安全
我这边有能让人机验证通过的方法，不过会卡在一直验证那边，在想办法解决

@jyuxkw
Copy link

jyuxkw commented Aug 4, 2023

部署完后，聊天出现：正在尝试连接，请稍候。 请问这个是什么问题？怎么解决

@Harry-zklcdc
Copy link
Owner Author

还是Cookie的问题，NewbingGoGo我研究了一下，他是直接拿的完整Cookie，所以没有那么容易触发验证，但是这样不安全 我这边有能让人机验证通过的方法，不过会卡在一直验证那边，在想办法解决

有个验证之后才有的Cookie，不过有效期就一天，我看看能不能直接在界面上能解决验证

@willggy
Copy link

willggy commented Aug 4, 2023

CF把代码复制过去出现这种错误，绑定了域名
很抱歉，似乎出现错误。 让我们重新开始吧。

@SokWith
Copy link

SokWith commented Aug 4, 2023

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端,前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。 但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

image
我似乎发现了我的replit可用而cfwk站点不可用的原因了。
网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为www.bing.com
解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

@Harry-zklcdc
Copy link
Owner Author

Harry-zklcdc commented Aug 4, 2023 •
edited
Loading

image 我似乎发现了我的replit可用而cfwk站点不可用的原因了。 网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为www.bing.com 解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

并不是，这个项目也有对应的模块

go-proxy-bingai/common/proxy.go

Lines 294 to 317 in 298bfd0

func replaceResBody(originalBody string, originalScheme string, originalHost string) string {
modifiedBodyStr := originalBody
if originalScheme == "https" {
if strings.Contains(modifiedBodyStr, BING_URL.Host) {
modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_URL.Host, originalHost)
}
} else {
originalDomain := fmt.Sprintf("%s://%s", originalScheme, originalHost)
if strings.Contains(modifiedBodyStr, BING_URL.String()) {
modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_URL.String(), originalDomain)
}
}
// 对话暂时支持国内网络，而且 Vercel 还不支持 Websocket ，先不用
// if strings.Contains(modifiedBodyStr, BING_CHAT_DOMAIN) {
// modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_CHAT_DOMAIN, originalDomain)
// }
// if strings.Contains(modifiedBodyStr, "https://www.bingapis.com") {
// modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, "https://www.bingapis.com", "https://bing.vcanbb.top")
// }
return modifiedBodyStr
}

主要问题还是在Cookie还有IP上

NewBingGoGo是直接获取你电脑上的所有Cookie给Bing发过去请求创建对话
对应 /turning/conversation/create 这个接口，然后会返回对应的 ConversationID 和 ConversationSign

我抓了官方的数据包，在对话的时候的没有发送Cookie的，那就可以判断Bing是通过 ConversationID 来确定是否需要人机验证

如果需要验证，/sydney/ChatHub 这个WebSocket接口会返回

"result": {
    "value": "CaptchaChallenge",
    "message": "User needs to solve CAPTCHA to continue.",
    "error": "User needs to solve CAPTCHA to continue.",
    "serviceVersion": "20230803.43"
}

然后就会触发验证

而且可预见的，获取的 ConversationID 如果包含 BingProdUnAuthenticatedUsers，那极大概率会触发人机验证

所以我现在的思路是直接触发验证的时候，直接过验证，但是目前不知道问题出在哪，一直验证通过，但是会重复验证

PS：NewBingGoGo的验证码解决方案还是旧版的，也就是Newbing自身的验证码，而不是Cloudflare的验证，但是那个接口现在已经404了，也就是说，饶过验证目前还没有人解决了

@SokWith
Copy link

SokWith commented Aug 4, 2023 •
edited
Loading

仅针对这个cf纯web版，与部署版2次get的方式是不同的。
image
image

2次get是由上面那个核心js直接发起的，所以失败了

@Harry-zklcdc
Copy link
Owner Author

仅针对这个cf纯web版，与部署版2次get的方式是不同的。 image image

2次get是由上面那个核心js直接发起的，所以失败了

嗯？你看看演示站？演示站没这个问题吧

@SokWith
Copy link

SokWith commented Aug 4, 2023

仅针对这个cf纯web版，与部署版2次get的方式是不同的。 image image
2次get是由上面那个核心js直接发起的，所以失败了

嗯？你看看演示站？演示站没这个问题吧

image
一样的baiox表现

@Harry-zklcdc
Copy link
Owner Author

image 一样的baiox表现

image

emm

@ohmyivan
Copy link

ohmyivan commented Aug 4, 2023

不能用，输入了那两个变量然后部署的，都是正在尝试连接，请稍候··

@Harry-zklcdc
Copy link
Owner Author

不能用，输入了那两个变量然后部署的，都是正在尝试连接，请稍候··

这个部署方式Bug还很多呢，只是一个新特性

@SokWith
Copy link

SokWith commented Aug 4, 2023 •
edited
Loading

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端,前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。 但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

image 我似乎发现了我的replit可用而cfwk站点不可用的原因了。 网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为www.bing.com 解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

按此思路救回了我的纯cf服务器
https://cfwk.nbing.eu.org
内置ID，开箱即用。

我另外两个测试站点 ：
https://vercel.nbing.eu.org/
https://replit.nbing.eu.org/
今天表现也很稳定。
只是，感谢各位参与测试的朋友，接下来一周我要离开一会儿，由于内置ID一般要每天科学验证1次，都没条件验证了，可能会停摆一阵了。

@cakexxx
Copy link

cakexxx commented Aug 5, 2023

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端,前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。 但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

image 我似乎发现了我的replit可用而cfwk站点不可用的原因了。 网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为www.bing.com 解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

按此思路救回了我的纯cf服务器 https://cfwk.nbing.eu.org 内置ID，开箱即用。

我另外两个测试站点 ： https://vercel.nbing.eu.org/ https://replit.nbing.eu.org/ 今天表现也很稳定。 只是，感谢各位参与测试的朋友，接下来一周我要离开一会儿，由于内置ID一般要每天科学验证1次，都没条件验证了，可能会停摆一阵了。

不能用，输入了那两个变量然后部署的，都是正在尝试连接，请稍候··

这个部署方式Bug还很多呢，只是一个新特性

怎么验证的呀，我总是不行，要么显示这个
image
要么显示这个
image

@SokWith
Copy link

SokWith commented Aug 6, 2023

按此方法新建的一个站点，跟踪一下存活情况：

我两个用cf做后端，前端分别在vercel和replit上的站点： https://vercel.nbing.eu.org https://replit.nbing.eu.org 今天一直正常。但用这个纯cf的站点目前确实一直出现重新开始吧，但作为NewBingGoGo插件的魔法接入点又是可用的。觉得问题还是出在header的处理上。

我明天在研究一下

image我似乎发现了我的replit可用而cfwk站点不可用的原因了。网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为 www.bing.com 解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

按此思路救回了我的纯cf服务器 https://cfwk.nbing.eu.org 内置ID，开箱即用。
我另外两个测试站点 ： https://vercel.nbing.eu.org/ https://replit.nbing.eu.org/ 今天表现也很稳定。只是，感谢各位参与测试的朋友，接下来一周我要离开一会儿，由于内置ID一般要每天科学验证1次，都没条件验证了，可能会停摆一阵了。

不能用，输入了那两个变量然后部署的，都是正在尝试连接，请稍候··

这个部署方式Bug还很多呢，只是一个新特性

怎么验证的呀，我总是不行，要么显示这个 要么显示这个 image image

vercel replit cfwk.nbing.eu.org 已更新内置ID，可以继续使用了。

@SokWith SokWith mentioned this issue Aug 7, 2023
Closed
@xuehaosheng
Copy link

修改最上面的两个Cookie变量
请问这个具体是怎么操作

@YuenSzeHong
Copy link

话说我NAS部署docker无法存取历史记录正常吗？

@xzy103 xzy103 mentioned this issue Aug 13, 2023
Closed
@SokWith
Copy link

SokWith commented Aug 17, 2023 •
edited
Loading

加上随机cookie后，可以实现无ID(K\U\R值)聊天。

const randcookie = randomString(99);
if (!cookie.includes('_U=')) {
cookies += '; _U=' + randcookie;
}

function randomChar() {
var chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
var index = Math.floor(Math.random() * chars.length);
return chars[index];
}

function randomString(n) {
var str = "";
for (var i = 0; i < n; i++) {
str += randomChar();
}
return str;
}

随机字符串函数是bingAI给我的。

测试站点： https://cfree.nbing.eu.org

已知问题，每次重置或者刷新页面后，不能直接聊天，需要先点击首页上的推荐聊天项目，得到输出后可以刷新新主题后就正常了。
image

@Harry-zklcdc
Copy link
Owner Author

加上随机cookie后，可以实现无ID(K\U\R值)聊天。

const randcookie = randomString(99); if (!cookie.includes('_U=')) { cookies += '; _U=' + randcookie; }

function randomChar() { var chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; var index = Math.floor(Math.random() * chars.length); return chars[index]; }

function randomString(n) { var str = ""; for (var i = 0; i < n; i++) { str += randomChar(); } return str; }

随机字符串函数是bingAI给我的。

测试站点： https://cfree.nbing.eu.org

已知问题，每次重置或者刷新页面后，不能直接聊天，需要先点击首页上的推荐聊天项目，得到输出后可以刷新新主题后就正常了。 image

我测试一下

@SokWith
Copy link

SokWith commented Aug 18, 2023

加上随机cookie后，可以实现无ID(K\U\R值)聊天。
const randcookie = randomString(99); if (!cookie.includes('_U=')) { cookies += '; _U=' + randcookie; }
function randomChar() { var chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; var index = Math.floor(Math.random() * chars.length); return chars[index]; }
function randomString(n) { var str = ""; for (var i = 0; i < n; i++) { str += randomChar(); } return str; }
随机字符串函数是bingAI给我的。
测试站点： https://cfree.nbing.eu.org
已知问题，每次重置或者刷新页面后，不能直接聊天，需要先点击首页上的推荐聊天项目，得到输出后可以刷新新主题后就正常了。 image

我测试一下

这个微软的漏洞居然没有存活过24小时，今天上午两个无cookie测试站点 hfwk cfree都一直无效域了，也就是假cookie拿到的create无效了。

@Harry-zklcdc
Copy link
Owner Author

这个微软的漏洞居然没有存活过24小时，今天上午两个无cookie测试站点 hfwk cfree都一直无效域了，也就是假cookie拿到的create无效了。

你去看看那个Github Action 部署的项目吧，目前来说 Github Action + Cloudflare Tunnel 是最优解，不过就是存活时间的问题了。只有6搁小时，还有就是容易被封号

@YuenSzeHong
Copy link

image
worker部署，转圈圈

@SokWith
Copy link

SokWith commented Aug 18, 2023

image 我似乎发现了我的replit可用而cfwk站点不可用的原因了。 网站1次打开时，在GET /turing/conversaton/create时是用的本机域名，而发起聊天时，却会再次GET这个会话，使用的是个体下来的官方的核心api，但是这个核心api的js文件里面，是写死了GET路径为www.bing.com 解决的办法可以是替换官方核心API，这也是NewBingGoGo因为是重写的核心api，所以一直可用的原因之一吧

并不是，这个项目也有对应的模块

go-proxy-bingai/common/proxy.go

Lines 294 to 317 in 298bfd0

func replaceResBody(originalBody string, originalScheme string, originalHost string) string {
modifiedBodyStr := originalBody
if originalScheme == "https" {
if strings.Contains(modifiedBodyStr, BING_URL.Host) {
modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_URL.Host, originalHost)
}
} else {
originalDomain := fmt.Sprintf("%s://%s", originalScheme, originalHost)
if strings.Contains(modifiedBodyStr, BING_URL.String()) {
modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_URL.String(), originalDomain)
}
}
// 对话暂时支持国内网络，而且 Vercel 还不支持 Websocket ，先不用
// if strings.Contains(modifiedBodyStr, BING_CHAT_DOMAIN) {
// modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, BING_CHAT_DOMAIN, originalDomain)
// }
// if strings.Contains(modifiedBodyStr, "https://www.bingapis.com") {
// modifiedBodyStr = strings.ReplaceAll(modifiedBodyStr, "https://www.bingapis.com", "https://bing.vcanbb.top")
// }
return modifiedBodyStr
}

主要问题还是在Cookie还有IP上

NewBingGoGo是直接获取你电脑上的所有Cookie给Bing发过去请求创建对话 对应 /turning/conversation/create 这个接口，然后会返回对应的 ConversationID 和 ConversationSign

我抓了官方的数据包，在对话的时候的没有发送Cookie的，那就可以判断Bing是通过 ConversationID 来确定是否需要人机验证

如果需要验证，/sydney/ChatHub 这个WebSocket接口会返回

"result": {
    "value": "CaptchaChallenge",
    "message": "User needs to solve CAPTCHA to continue.",
    "error": "User needs to solve CAPTCHA to continue.",
    "serviceVersion": "20230803.43"
}

然后就会触发验证

而且可预见的，获取的 ConversationID 如果包含 BingProdUnAuthenticatedUsers，那极大概率会触发人机验证

所以我现在的思路是直接触发验证的时候，直接过验证，但是目前不知道问题出在哪，一直验证通过，但是会重复验证

PS：NewBingGoGo的验证码解决方案还是旧版的，也就是Newbing自身的验证码，而不是Cloudflare的验证，但是那个接口现在已经404了，也就是说，饶过验证目前还没有人解决了

拜托检查一下，纯cf部署的时候，这个proxy.go的代理代码似乎并没有被加载运行，造成加载的核心API始终是走www.bing.com路径从而create失败

@SokWith
Copy link

SokWith commented Aug 19, 2023

#71 (comment)
发现伪bug的原因了，原来是自己人为制造的。
由于纯cf部署的核心api没有运行proxu.go的域名转发，我直接把核心api里面的域名替换了，造成所有的纯cf部署都采用了替换的域名进行二次create句柄。由于这个替换的域名也是cf里面的，所以没有出现跨域错误（如果换成其他非cf域名，也会跨域错误的）。但是，cf的ip目前是不能直接无cookie聊天的，我那个替换的域名里面内置了ID，所以，内置ID生效其他站点就可以使用，内置ID无效域其他站点就跟着无效域了。
目前看来随机cookie的唯一作用是能让create不会返回空了，如何利用好返回的conversationId又是一个问题。还是得分析为什么真实的微软云的无账户conversationId可以使用，而转发ip出来的conversationId则需要验证？

@Harry-zklcdc
Copy link
Owner Author

Harry-zklcdc commented Aug 19, 2023 •
edited
Loading

#71 (comment) 发现伪bug的原因了，原来是自己人为制造的。 由于纯cf部署的核心api没有运行proxu.go的域名转发，我直接把核心api里面的域名替换了，造成所有的纯cf部署都采用了替换的域名进行二次create句柄。由于这个替换的域名也是cf里面的，所以没有出现跨域错误（如果换成其他非cf域名，也会跨域错误的）。但是，cf的ip目前是不能直接无cookie聊天的，我那个替换的域名里面内置了ID，所以，内置ID生效其他站点就可以使用，内置ID无效域其他站点就跟着无效域了。

在想新方法了，现在打算把这几个文件直接保存在本地，然后实时替换，这样的话会更方便修改，但是这样的话，通过whistle过人机验证的方法就会失效，盲猜巨硬针对JS完整新有检查，用于检查是否能通过人机验证

目前看来随机cookie的唯一作用是能让create不会返回空了，如何利用好返回的conversationId又是一个问题。还是得分析为什么真实的微软云的无账户conversationId可以使用，而转发ip出来的conversationId则需要验证？

IP高风险，还是IP问题，我Azure的IP一个礼拜才验证了一次

@SokWith SokWith mentioned this issue Aug 19, 2023
Closed
@Harry-zklcdc
Copy link
Owner Author

Harry-zklcdc commented Oct 24, 2023 •
edited
Loading

已完整实现
Commit: be01292
感谢 @goss1p 的贡献

@hqzh
Copy link

hqzh commented Jan 31, 2024

_RwBf

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation Improvements or additions to documentation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests