Open weaigc opened 10 months ago
@weaigc 大佬,你更新的muid()采用随机数现在基本上不可行的,官方已经用muid全面取代终端机器验证了,对muid的生成有自己的规则,一般生成的都会出错。 目前我测试出来的是可以用已知可行的muid,随便更换最后2位字符,大概率是可用的。所以,让ai生成的一段代码:
const MUID_ADDRESSES: string[] = [
"074AD7F106536BC6392FC4C907CA6AEA",
// 添加更多的IP地址
];
function getRandomMUID(): string {
const timestamp = Date.now();
const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp);
const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length];
const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2);
const randomString = generateRandomString(2);
const USER_MUID = trimmedIPStr + randomString;
return USER_MUID;
}
export function muid() {
// return md5(new imei().random()).toUpperCase()
return getRandomMUID()
}
@weaigc 大佬,你更新的muid()采用随机数现在基本上不可行的,官方已经用muid全面取代终端机器验证了,对muid的生成有自己的规则,一般生成的都会出错。 目前我测试出来的是可以用已知可行的muid,随便更换最后2位字符,大概率是可用的。所以,让ai生成的一段代码:
const MUID_ADDRESSES: string[] = [ "074AD7F106536BC6392FC4C907CA6AEA", // 添加更多的IP地址 ]; function getRandomMUID(): string { const timestamp = Date.now(); const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp); const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length]; const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2); const randomString = generateRandomString(2); const USER_MUID = trimmedIPStr + randomString; return USER_MUID; } export function muid() { // return md5(new imei().random()).toUpperCase() return getRandomMUID() }
@SokWith MUID 我不想硬编码,按照标准的 MUID 生成规则又很容易跟真实的用户冲突,所以故意写了一个错误的。不过确实更容易被封禁。我有办法生成真实的 MUID ,只不过速度还不太快,如果你这个可行,我后面专门做一个服务来生成 MUID。谢谢反馈!
vercel上面部署的1.0.0,无I内置ID,可以说很简单的几个字符,比如 “hi”,但也足以说明vercel没有被官方封禁。
官方10月更新API后,似乎原来的许多限制都解除了,几乎没有IP锁和MUID锁了(随便32个16进制字符串都可以),目前还剩下的只有根据连接网络属性来是否进行账户验证,我的部署测试表明,目前云服务器中抱脸、render、vercel都不需要验证匿名账户,replit、cf需要验证账户。
官方10月更新API后,似乎原来的许多限制都解除了,几乎没有IP锁和MUID锁了(随便32个16进制字符串都可以),目前还剩下的只有根据连接网络属性来是否进行账户验证,我的部署测试表明,目前云服务器中抱脸、render、vercel都不需要验证匿名账户,replit、cf需要验证账户。
@SokWith 你说的那种方案试过了,流量一大了就不行,自用确实没啥问题。
netlify也复活了
netlify也复活了 netlify 一般只能复活一天,不能持续,https://effulgent-bubblegum-e2f5df.netlify.app/ 你可以用用看
netlify也复活了 netlify 一般只能复活一天,不能持续,https://effulgent-bubblegum-e2f5df.netlify.app/ 你可以用用看
试了下,确实不稳定,今天我这一条都不能用了。。。
@weaigc 大佬,你更新的muid()采用随机数现在基本上不可行的,官方已经用muid全面取代终端机器验证了,对muid的生成有自己的规则,一般生成的都会出错。 目前我测试出来的是可以用已知可行的muid,随便更换最后2位字符,大概率是可用的。所以,让ai生成的一段代码:
const MUID_ADDRESSES: string[] = [ "074AD7F106536BC6392FC4C907CA6AEA", // 添加更多的IP地址 ]; function getRandomMUID(): string { const timestamp = Date.now(); const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp); const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length]; const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2); const randomString = generateRandomString(2); const USER_MUID = trimmedIPStr + randomString; return USER_MUID; } export function muid() { // return md5(new imei().random()).toUpperCase() return getRandomMUID() }
这段代码在部署的时候应该放在哪里?
@weaigc 大佬,你更新的muid()采用随机数现在基本上不可行的,官方已经用muid全面取代终端机器验证了,对muid的生成有自己的规则,一般生成的都会出错。 目前我测试出来的是可以用已知可行的muid,随便更换最后2位字符,大概率是可用的。所以,让ai生成的一段代码:
const MUID_ADDRESSES: string[] = [ "074AD7F106536BC6392FC4C907CA6AEA", // 添加更多的IP地址 ]; function getRandomMUID(): string { const timestamp = Date.now(); const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp); const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length]; const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2); const randomString = generateRandomString(2); const USER_MUID = trimmedIPStr + randomString; return USER_MUID; } export function muid() { // return md5(new imei().random()).toUpperCase() return getRandomMUID() }
这段代码在部署的时候应该放在哪里?
现在几乎没有MUID锁了,这段代码基本不需要了,有了由于MUID被频繁使用,反而容易上锁。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
确实,render会封账号,特别是部署隔壁go-proxy时,秒封,但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间,只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss,所以没有时长限制。但是因为实质是cf,而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id,是能够匿名的,就不知道可否与cf结合起来,使用cf来连接wss。只是,你那个cf-proxy的代码似乎不能直接路由,会跳转cn。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
我今天申请render新账号部署bingo,结果被告知在进行suspicious actions,然后账号被suspended...
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
我今天申请render新账号部署bingo,结果被告知在进行suspicious actions,然后账号被suspended...
不好意思哈。也幸好你用的新号。看来我也得把我的部署停了换新号了。
ps: 果然,新部署直接秒封。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
确实,render会封账号,特别是部署隔壁go-proxy时,秒封,但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间,只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss,所以没有时长限制。但是因为实质是cf,而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id,是能够匿名的,就不知道可否与cf结合起来,使用cf来连接wss。只是,你那个cf-proxy的代码似乎不能直接路由,会跳转cn。
cf没可能了,它的流量自带特征,只要访问过去就会被 new bing 检测到
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
确实,render会封账号,特别是部署隔壁go-proxy时,秒封,但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间,只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss,所以没有时长限制。但是因为实质是cf,而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id,是能够匿名的,就不知道可否与cf结合起来,使用cf来连接wss。只是,你那个cf-proxy的代码似乎不能直接路由,会跳转cn。
cf没可能了,它的流量自带特征,只要访问过去就会被 new bing 检测到
不是吧,隔壁go-proxy就可以纯js部署在cf上,只是不能匿名访问bing而已。只是不清楚决定是否要进行账户验证是在create时决定的还是在wss握手时决定的。如果是在create时决定的,就可以使用vercel来获取无需验证的连接id,如果是在wss握手时那就没办法了。目前看上去是在create时决定的,因为go-proxy部署在vercel上时,是使用的vercel的代理网络获得的连接id,然后路由的cf的wss,刚才测试表明也可以匿名访问。
确实跟muid没什么关系了,但是目前这些免费平台每次解禁都活不过一天。
不是吧,vercel、render都一直活起的哟。
![]()
![]()
render能用是因为很多人会被封账号,我也被封了。vercel目前有10秒限制,也不支持websocket,所以没法正常使用,你试试让它写诗,就能看出问题
确实,render会封账号,特别是部署隔壁go-proxy时,秒封,但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间,只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss,所以没有时长限制。但是因为实质是cf,而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id,是能够匿名的,就不知道可否与cf结合起来,使用cf来连接wss。只是,你那个cf-proxy的代码似乎不能直接路由,会跳转cn。
cf没可能了,它的流量自带特征,只要访问过去就会被 new bing 检测到
不是吧,隔壁go-proxy就可以纯js部署在cf上,只是不能匿名访问bing而已。只是不清楚决定是否要进行账户验证是在create时决定的还是在wss握手时决定的。如果是在create时决定的,就可以使用vercel来获取无需验证的连接id,如果是在wss握手时那就没办法了。目前看上去是在create时决定的,因为go-proxy部署在vercel上时,是使用的vercel的代理网络获得的连接id,然后路由的cf的wss,刚才测试表明也可以匿名访问。
不匿名部署cf bingo一直可以的呀,不过不能匿名就不能不限量使用了
解决方案里不是说了吗,要么账号没被封,要么vps没被封
你那个cf不是部署,包括replit里面的,都只是反代。这个项目本来就是纯js,是可以直接部署的,只是需要把next编译一下吧?。
你那个cf不是部署,包括replit里面的,都只是反代。这个项目本来就是纯js,是可以直接部署的,只是需要把next编译一下吧?。 @SokWith cf部署的代码没有开放了(因为没有解决根本问题),实际上bingo可以把 ENDPOING 设置为其他项目的代理,包括 cf,你可以试试
你那个cf不是部署,包括replit里面的,都只是反代。这个项目本来就是纯js,是可以直接部署的,只是需要把next编译一下吧?。 @SokWith cf部署的代码没有开放了(因为没有解决根本问题),实际上bingo可以把 ENDPOING 设置为其他项目的代理,包括 cf,你可以试试
ENDPOINT是指的WS_ENDPOINT的环境变量吗?这个变量是wss服务器的地址吧,换成cf的代理服务器并没有改善vercel的连接时长限制,主要还是vercel与wss服务器之间的数据交换时间。 所以,有没有可能,将create获取连接id的实现放在vercel上,就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id,而客户端界面实现在cf worlers上? 这样折腾的意义主要是抱脸的反应实在太慢了,给项目部署留一条后路。
你那个cf不是部署,包括replit里面的,都只是反代。这个项目本来就是纯js,是可以直接部署的,只是需要把next编译一下吧?。 @SokWith cf部署的代码没有开放了(因为没有解决根本问题),实际上bingo可以把 ENDPOING 设置为其他项目的代理,包括 cf,你可以试试
ENDPOINT是指的WS_ENDPOINT的环境变量吗?这个变量是wss服务器的地址吧,换成cf的代理服务器并没有改善vercel的连接时长限制,主要还是vercel与wss服务器之间的数据交换时间。 所以,有没有可能,将create获取连接id的实现放在vercel上,就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id,而客户端界面实现在cf worlers上? 这样折腾的意义主要是抱脸的反应实在太慢了,给项目部署留一条后路。
ENDPOINT和WS_ENDPOINT是两个,WS封杀力度不大,不用管
@SokWith v1不推荐用hf了呀,文档都改了,v2在用是因为v2版本对配置要求比较高,只有hf能给这么好的配置
@SokWith v1不推荐用hf了呀,文档都改了,v2在用是因为v2版本对配置要求比较高,只有hf能给这么好的配置
v2版给出的部署都是反代,和直接用你的部署是一样的,属于单点配置。
刚才我按上面的思路,对go-proxy项目对replit部署路由vercel的create,是可以匿名了。 但对这个项目采用类似处理,总是用户无效。
@SokWith v1不推荐用hf了呀,文档都改了,v2在用是因为v2版本对配置要求比较高,只有hf能给这么好的配置
v2版给出的部署都是反代,和直接用你的部署是一样的,属于单点配置。
刚才我按上面的思路,对go-proxy项目对replit部署路由vercel的create,是可以匿名了。 但对这个项目采用类似处理,总是用户无效。
v2不是反代,反代是v1的
你那个cf不是部署,包括replit里面的,都只是反代。这个项目本来就是纯js,是可以直接部署的,只是需要把next编译一下吧?。 @SokWith cf部署的代码没有开放了(因为没有解决根本问题),实际上bingo可以把 ENDPOING 设置为其他项目的代理,包括 cf,你可以试试
ENDPOINT是指的WS_ENDPOINT的环境变量吗?这个变量是wss服务器的地址吧,换成cf的代理服务器并没有改善vercel的连接时长限制,主要还是vercel与wss服务器之间的数据交换时间。 所以,有没有可能,将create获取连接id的实现放在vercel上,就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id,而客户端界面实现在cf worlers上? 这样折腾的意义主要是抱脸的反应实在太慢了,给项目部署留一条后路。
ENDPOINT和WS_ENDPOINT是两个,WS封杀力度不大,不用管
与WS连接的网络(ip)很重要,所以,薅了一下render的羊毛:replit的前端+render的ws: https://rpbingo.nbing.eu.org
唉,帅不过3秒,测试5次后似乎ip上锁了
目前封锁升级了: 1、对ENDPOINT,大面积的ip锁,目前只有少数几个云商还能够阵发性连接官网ENDPOINT,大多数的VLESS机场都受到限制了; 2、对WS_ENDPOINT,目前是行为封控,能够匿名访问的云商就更少了,迫切需要单独建立WSS代理服务器。 @weaigc 大佬,能抽空出一个单独建立WSS代理服务器的代码吗? ps:我在cf上大致按proxy.js建的服务器,是可以工作的(WS_ENDPOINT = "https://prosydney.nbing.eu.org“ ,限于登录用户可连接),但采用CLI部署到render、replit和huggingface都不可以,完全就是本地网络上一样。
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
因为很多人的账号只能用来画图,并不能聊天
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
因为很多人的账号只能用来画图,并不能聊天
主要麻烦是,无论后端服务器有没有内置cookie,前端网页如果不填写curl内容,那个尝试修复选项就一直被选定,无法清除。如果不清除这个选项,就不能在聊天中输出绘图。
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
因为很多人的账号只能用来画图,并不能聊天
主要麻烦是,无论后端服务器有没有内置cookie,前端网页如果不填写curl内容,那个尝试修复选项就一直被选定,无法清除。如果不清除这个选项,就不能在聊天中输出绘图。
尝试修复选项被选定是可以画图的,你把网站的cookie清理一下试试
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
因为很多人的账号只能用来画图,并不能聊天
主要麻烦是,无论后端服务器有没有内置cookie,前端网页如果不填写curl内容,那个尝试修复选项就一直被选定,无法清除。如果不清除这个选项,就不能在聊天中输出绘图。
尝试修复选项被选定是可以画图的,你把网站的cookie清理一下试试
https://bingo11.sokwith.repl.co/
在replit上编译部署的1.1版本,内置了BING_HEADER,采用无痕浏览,结果获得的id是匿名的,也就不能绘图了。
(PS:在replit上编译现在的版本真辛苦,得在周末中午国外人用的少的时候启动编译,否则一过载就终止编译)
@weaigc 另外,大佬,现在的登录逻辑是什么样的? 1、在前端网页界面,填写了url后,要去掉尝试选项才能登录;不去掉选项就一直是匿名? 2、在后端环境变量中,是设置一个BING_HEADER变量还是必须docker命令行?我在replit上设置这个环境变量没有作用;在后端环境变量设置后,前端网页该如何配置? 3、BING_COOKIE这个参数只是用于cf worker部署吗?
因为很多人的账号只能用来画图,并不能聊天
主要麻烦是,无论后端服务器有没有内置cookie,前端网页如果不填写curl内容,那个尝试修复选项就一直被选定,无法清除。如果不清除这个选项,就不能在聊天中输出绘图。
尝试修复选项被选定是可以画图的,你把网站的cookie清理一下试试
![]()
https://bingo11.sokwith.repl.co/ 在replit上编译部署的1.1版本,内置了BING_HEADER,采用无痕浏览,结果获得的id是匿名的,也就不能绘图了。
(PS:在replit上编译现在的版本真辛苦,得在周末中午国外人用的少的时候启动编译,否则一过载就终止编译)
1.1版本是存在一些问题的,你试试1.2或者1.3版本
(PS:在replit上编译现在的版本真辛苦,得在周末中午国外人用的少的时候启动编译,否则一过载就终止编译)
1.1版本是存在一些问题的,你试试1.2或者1.3版本
@weaigc 奇怪了,同一个仓库,同一个BING_HEADER,同是部署在huggingface上,采用仓库里面的docker.yml先打包后再使用镜像部署,可以绘图;直接使用dockerfile文件编译的部署,就不能绘图。这个dockerfile文件的编译指令不全吗?
FROM node:18
ARG DEBIAN_FRONTEND=noninteractive
ENV BING_HEADER = "Y3VybCAnaHR0cHM6Ly93d3cuYmluZy5jb20vdHVyaW5nL2NhcHRjaGEvY2hhbGxlbmdlJyBcICAgLUggJ2F1dGhvcml0eTogd3d3LmJpbmcuY29tJyBcICAgLUggJ2FjY2VwdDogdGV4dC9odG1sLGFwcGxpY2F0aW9uL3hodG1sK3htbCxhcHBsaWNhdGlvbi94bWw7cT0wLjksaW1hZ2UvYXZpZixpbWFnZS93ZWJwLGltYWdlL2FwbmcsKi8qO3E9MC44LGFwcGxpY2F0aW9uL3NpZ25lZC1leGNoYW5nZTt2PWIzO3E9MC45JyBcICAgLUggJ2FjY2VwdC1sYW5ndWFnZTogemgtQ04semg7cT0wLjknIFwgICAtSCAnY2FjaGUtY29udHJvbDogbWF4LWFnZT0wJyBcICAgLUggJCdjb29raWU6IF9nYV9NTTVKNVg4UVFDPUdTMS4xLjE2OTgyMjQwMTYuMS4xLjE2OTgyMjU2MzguMC4wLjA7IFNSQ0hEPUFGPU5PRk9STTsgU1JDSFVJRD1WPTImR1VJRD0wNTY0NUI2QUEzMDg0NDQ4QTQ1QTQ2NUREQjkyN0M5OSZkbW5jaGc9MTsgTVVJRD0xRUZGMUNDNDUzNEE2RjRDMTdCNjBFODQ1MjEwNkUxOTsgX1VSPVFTPTAmVFFTPTA7IE1VSURCPTFFRkYxQ0M0NTM0QTZGNEMxN0I2MEU4NDUyMTA2RTE5OyBNTUNBU009SUQ9REYwMUU5RTFBMDIzNEQ3OUEwNzIxODM3OUYzQzUxNUU7IEJDUD1BRD0xJkFMPTEmU009MTsgTWljcm9zb2Z0QXBwbGljYXRpb25zVGVsZW1ldHJ5RGV2aWNlSWQ9MzlkMDNjMjQtYTYxZS00MDA4LTlkOTktYmIwNTRlZTI2MTA3OyBfRURHRV9DRD11PWVuLXVzOyBVU1JMT0M9SFM9MSZFTE9DPUxBVD0yOS4zODU3MTE2Njk5MjE4NzV8TE9OPTEwNi40OTkxNjgzOTU5OTYxfE49QmFcJ25hbiUyMERpc3RyaWN0JTJDJTIwQ2hvbmdxaW5nfEVMVD00fDsgU1JDSFVTUj1ET0I9MjAyMzEwMjYmVD0xNzAwNDU2OTIyMDAwJlRQQz0xNzAwNDQ1MjI3MDAwJlBPRVg9VzsgX1U9MWh1MFBzNkQ4YWxIVmZkSWp5aTJ4UXVPV08xbkJabm1qYzBvbUQ3Yko5cnpCU002NzFjVmFMeEdJcElGVXczUWVLaGtDYWg0elhiS1N1QVNEbm1lYXdwdllPODRWUFZBckZPa3hoOFFOcl93TzE3b19ranRRYzQtNE50NFY1c1V3YUs5TnhNZVU2a2tlU0hLd0oyVnM2enlQR1JkeXhVY2s2c0hhTml0UlVXUGZ0M29id2VBeXpmZ1VxdGNtY2diRDJYcm1aQXpMR0pjdElMRWtsU0ZmVlE7IFBQTFN0YXRlPTE7IE5BUD1WPTEuOSZFPTFjYjkmQz12VVAybzVtMmhZal9GTDN4STlEZFY1QXR3cTVDTjJya0IteTBEQTRWTUIwbGRmMXlIVjhQb3cmVz0xMDsgS2lldlJQU1NlY0F1dGg9RkFCYUJCUmFUT0pJTHRGc01rcExWV1NHNkFONkMvc3ZSd05tQUFBRWdBQUFDQnhyQnFCdTlHNmxHQVRrd1lDSWV5enEvblVRZjJQVENTUmMzQ2dNNVhsTUx4Y3phdzl0ekx1Z25QT3IxNlRjWW9TdGg2SytCekI0ZCtQSllZSjFZeE1udWIrSHdlTEdqWkUxOGNKNVJHZVhPb05kZ0pWWSs2S3A0NDAwVmpranQ5TWJDTUFUV1ExMjZpV3hxTHAwUDdCRlRZaWhURUFwcC90ZkxuNkViTUo0dnNFK3dQUWRMK3RZQmQrWXdETm9ITnJFL1FocXZwQmxtNVkzMVdvc3Yrd3piSVpKa0oyejFjZXR0VlpUcVNISHE3TkRpRTVWa2E0c2VHdzVoanlJUXpMcUorWFpXdVRMaVg4djFibUt6VEZkaWE2Q2JzdkRjTVo4bHJoTmNpUm1MamRHelZad3VlOVZNNkNqSE95SldyQjA5Y29JWGYvL2tUTGNnVTg4ckE3OE80TmZoaHB4SmxoQ3diVDI5U0dIOHpZby91dWlRK0hFNXBwNEk2b3hacnBtaG8vQ3lYZndWZnF5VEhYcGNFUUdwRE03L202TzhMZXJFMVdqeFVpYUV5ZXdRUERtUlc3WUJSUXF5UFN5ZWxZZmRQOGNGNnhON3FWRDJBOFJQN0JMTDRQay9uTE15NFN6eU5TcTFLVVRiZ2Y0ZW5iTk5GM0pja3VGU1Z4b1U4MUc0U04rL0lZeUF0N3ZoQkpyMFkwc0JNaFZUT1VzUTdtR0JoSDdweVJ2ODdaNGVzVkR6VWREcFVEVk5xUGNoMzRKOGJ5Wk95UDVMVUh3Y1c4QldPQURmc2dQNTJSSE41RlMza2JVQkZkZURpckVFK0hiLzB5OTQzaTgzaDBEanpqaFZ4MW01VmZGNzI5dlNkczhDU2NFVjhZa1dFY3pyNmFYb2tVdEJEejUwUkJpR2JSeVFnZk1BTlB6bXFncys0UWpxL2NpSUtPMG5NNjJsalljSm0rS21KSTZKc0syTDlhWmVvNXlsaWpFRFg4dzI4VDVmWnFydzV0Um96RGlnZzFSQVZINjVmSDk4bUdVUEtnOFRaTzZDZklnSWx4WmJoL2JIbFQ5aWxzN3l5VnU3cXVTTFRqMGYxN3V6UGllUXFqbEdjT2RBbDE1dFBQOVlXY05mRVFIbzUySkhDeVZ1NzltdnVLZEIyU1lodmU1U2NHS2pYVVVsR01mbWZrMnpxbEdFSzg2UGRhM0grN2JJczdnNGQzVGZLRnFUSlFVeFBqdnFTUFVtWG9La3VXeEw5ckxzTFZMajkrRE1OdVBNUzk4Sng5M0ltazFpQ2lzN1Y4T0dtQUZ2Y0pQLzdvaWZCRnNyRXhvRmNnbWg3UUJpQ0o3Z21ETmIyb2dBWVNGYmZON2ZDbDJieU5PNTBXVWdueXBrTlRTL3MyZjZSNm92NEdiZjlmVi92OHV5VURIdDBKay9FSUNJT29ZdHpmRVM5V3liaXhMYnpJZHk3YjJtVWF3RzJDQnhOVGR4UmlhNW1kNzZjZlViK1pHcnFGYTV1WDZLcmRXQkkzbGtISnhwVU93anIvdlNmaGo3aWM4TzdoNGg2VHNPcEViMlJCQ01UR1BDdTlLWGh4YzB0ejA2YVYySzVaeWNLS0NkUnM0c0Y2MHNkMXcwcE1udldiU3JjVndmcGhYeU5oZ3hhakU1U0Y4NDM2V2ZrZHdaOTgxeEZYRHI2bGxLNXhMTmVRSDNmSUt1K21DSzEzVVFBLzdhdnpuYVJ4U3RtdWFYV2hoNU5TdC9tTDJocmFYdzNNTm1aSHg0VDIyeU0rUG1aU0FGOVB4cGhGUDdJWTByQWRFUUFkS0VhSFJ4YWJxZlU5MDhZS1RlNXh4Vkt1Ulo2K3FXVEZtNml5NVNKUTBqdGVoVC9oZEZBQURNZyt3WWZEQ3JJOTg2eXY0RlFoR2tnbXhKQT09OyBBTk9OPUE9OUEyNDcwQjc4MzI2NEIyMzMwNzAyOEFGRkZGRkZGRkYmRT0xZDEzJlc9MTE7IFdMSUQ9Q2JOVU96bnU1UHgyNy9scXpvVU1wRXQ0d2VkVHhkMnNCWGkrbFd5WlBTNndDdGk5ZDZQczFVMDhYeWZYK2FvbWFoQS80Mzh0M3RqbzZKVWMxcm13OFRoalBQYVhUZDRLeWhURVBGdG9KTVU9OyBfSFBWTj1DUz1leUpRYmlJNmV5SkRiaUk2T0N3aVUzUWlPakFzSWxGeklqb3dMQ0pRY205a0lqb2lVQ0o5TENKVFl5STZleUpEYmlJNk9Dd2lVM1FpT2pBc0lsRnpJam93TENKUWNtOWtJam9pU0NKOUxDSlJlaUk2ZXlKRGJpSTZPQ3dpVTNRaU9qQXNJbEZ6SWpvd0xDSlFjbTlrSWpvaVZDSjlMQ0pCY0NJNmRISjFaU3dpVFhWMFpTSTZkSEoxWlN3aVRHRmtJam9pTWpBeU15MHhNUzB5TUZRd01Eb3dNRG93TUZvaUxDSkpiM1JrSWpvd0xDSkhkMklpT2pBc0lsUnVjeUk2TUN3aVJHWjBJanB1ZFd4c0xDSk5kbk1pT2pBc0lrWnNkQ0k2TUN3aVNXMXdJam8xTml3aVZHOWlZbk1pT2pCOTsgU25yT3ZyPVg9cmViYXRlc29uOyBfUndCZj1yPTEmaWx0PTImaWhwZD0yJmlzcGQ9MCZyYz00NiZyYj00NiZnYj0wJnJnPTAmcGM9MCZtdHU9MCZyYmI9MC4wJmc9MCZjaWQ9JmNsbz0wJnY9MyZsPTIwMjMtMTEtMTlUMDg6MDA6MDAuMDAwMDAwMFombGZ0PTAwMDEtMDEtMDFUMDA6MDA6MDAuMDAwMDAwMCZhb2Y9MCZvPTAmcD1CSU5HQ09QSUxPVFdBSVRMSVNUJmM9TVIwMDBUJnQ9NTI0NyZzPTIwMjMtMDgtMjJUMTE6MTU6NDguNjMxMjE2MSswMDowMCZ0cz0yMDIzLTExLTIwVDA1OjEwOjQ4LjU2ODg2NjYrMDA6MDAmcndyZWQ9MCZ3bHM9MiZ3bGI9MCZsa2E9MCZsa3Q9MCZhYWQ9MCZUSD0mbXRhPTAmZT1MaEFMSWJmMVV1elJYNS1FRENoTWFwUVBjMGtoTGc5STF3aHNheW5ScWVHbXRfWUdUOHJwU3c1RXdkZG1RNnRhNlFwOGxnX2w4S1EyS1VBaXdTRGxvUSZBPTlBMjQ3MEI3ODMyNjRCMjMzMDcwMjhBRkZGRkZGRkZGOyBTUkNISFBHVVNSPVNSQ0hMQU5HPWVuJkJaQT0wJkJSVz1OT1RQJkJSSD1TJkNXPTQyMiZDSD02MTEmU0NXPTQwNiZTQ0g9NjExJkRQUj0xLjMmVVRDPTQ4MCZETT0wJlBWPTAuMS4wJkhWPTE3MDA0NTcwNDgmV1RTPTYzODM2MDUzNzM3JklHPUQyOTZGNURBMTkzRjQ3Mzg5OTlGOTI0ODc0RUYxNTkyJlBSVkNXPTExNTImUFJWQ0g9NjExJkNJQlY9MS4xMzU5LjYmY2R4dG9uZT1DcmVhdGl2ZSZjZHh0b25lb3B0cz1oM2ltYWdpbmF0aXZlLGNsZ2FsaWxlbyxnZW5jb250ZW50djMsZmx1eHYxNDsgY2N0PVVrOXJqRFNWQXVlbUQ1aUU0NEJrMG8zYkJ6emRZTmIwSmsxbHpxb25EbzRBVExsRmxENXRUcnE5MmxEUW9CY09SNzhYNUVwT0Z5WmE4dTRiY01PY3JBOyBfRURHRV9TPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MDsgV0xTPUM9NjM2YWI2YWNiODU4YzBkMCZOPWpva3lvMjsgX1NTPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MCcgXCAgIC1IICdzZWMtY2gtdWE6ICJOb3RfQSBCcmFuZCI7dj0iOTkiLCAiR29vZ2xlIENocm9tZSI7dj0iMTA5IiwgIkNocm9taXVtIjt2PSIxMDkiJyBcICAgLUggJ3NlYy1jaC11YS1hcmNoOiAieDg2IicgXCAgIC1IICdzZWMtY2gtdWEtYml0bmVzczogIjY0IicgXCAgIC1IICdzZWMtY2gtdWEtZnVsbC12ZXJzaW9uOiAiMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1mdWxsLXZlcnNpb24tbGlzdDogIk5vdF9BIEJyYW5kIjt2PSI5OS4wLjAuMCIsICJHb29nbGUgQ2hyb21lIjt2PSIxMDkuMC41NDE0LjEyMCIsICJDaHJvbWl1bSI7dj0iMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1tb2JpbGU6ID8wJyBcICAgLUggJ3NlYy1jaC11YS1tb2RlbDogIiInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtOiAiV2luZG93cyInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtLXZlcnNpb246ICIwLjEuMCInIFwgICAtSCAnc2VjLWZldGNoLWRlc3Q6IGRvY3VtZW50JyBcICAgLUggJ3NlYy1mZXRjaC1tb2RlOiBuYXZpZ2F0ZScgXCAgIC1IICdzZWMtZmV0Y2gtc2l0ZTogY3Jvc3Mtc2l0ZScgXCAgIC1IICdzZWMtZmV0Y2gtdXNlcjogPzEnIFwgICAtSCAndXBncmFkZS1pbnNlY3VyZS1yZXF1ZXN0czogMScgXCAgIC1IICd1c2VyLWFnZW50OiBNb3ppbGxhLzUuMCAoV2luZG93cyBOVCAxMC4wOyBXaW42NDsgeDY0KSBBcHBsZVdlYktpdC81MzcuMzYgKEtIVE1MLCBsaWtlIEdlY2tvKSBDaHJvbWUvMTA5LjAuMC4wIFNhZmFyaS81MzcuMzYnIFwgICAtLWNvbXByZXNzZWQ="
RUN apt-get update && apt-get install -y git
# Set home to the user's home directory
ENV HOME=/home/user \
PATH=/home/user/.local/bin:$PATH
# Set up a new user named "user" with user ID 1000
RUN useradd -o -u 1000 user && mkdir -p $HOME/app && chown -R user $HOME
# Switch to the "user" user
USER user
# Set the working directory to the user's home directory
WORKDIR $HOME/app
# 从 GitHub 克隆 weaigc/bingo 项目到 /workspace/app 目录下
RUN git clone https://github.com/SokWith/bingo.git ./
# Copy the current directory contents into the container at $HOME/app setting the owner to the user
COPY --chown=user . $HOME/app/
RUN npm install && npm run build
RUN rm -rf src
ENV PORT 7860
EXPOSE 7860
CMD npm start
(PS:在replit上编译现在的版本真辛苦,得在周末中午国外人用的少的时候启动编译,否则一过载就终止编译)
1.1版本是存在一些问题的,你试试1.2或者1.3版本
@weaigc 奇怪了,同一个仓库,同一个BING_HEADER,同是部署在huggingface上,采用仓库里面的docker.yml先打包后再使用镜像部署,可以绘图;直接使用dockerfile文件编译的部署,就不能绘图。这个dockerfile文件的编译指令不全吗?
FROM node:18 ARG DEBIAN_FRONTEND=noninteractive ENV BING_HEADER = "Y3VybCAnaHR0cHM6Ly93d3cuYmluZy5jb20vdHVyaW5nL2NhcHRjaGEvY2hhbGxlbmdlJyBcICAgLUggJ2F1dGhvcml0eTogd3d3LmJpbmcuY29tJyBcICAgLUggJ2FjY2VwdDogdGV4dC9odG1sLGFwcGxpY2F0aW9uL3hodG1sK3htbCxhcHBsaWNhdGlvbi94bWw7cT0wLjksaW1hZ2UvYXZpZixpbWFnZS93ZWJwLGltYWdlL2FwbmcsKi8qO3E9MC44LGFwcGxpY2F0aW9uL3NpZ25lZC1leGNoYW5nZTt2PWIzO3E9MC45JyBcICAgLUggJ2FjY2VwdC1sYW5ndWFnZTogemgtQ04semg7cT0wLjknIFwgICAtSCAnY2FjaGUtY29udHJvbDogbWF4LWFnZT0wJyBcICAgLUggJCdjb29raWU6IF9nYV9NTTVKNVg4UVFDPUdTMS4xLjE2OTgyMjQwMTYuMS4xLjE2OTgyMjU2MzguMC4wLjA7IFNSQ0hEPUFGPU5PRk9STTsgU1JDSFVJRD1WPTImR1VJRD0wNTY0NUI2QUEzMDg0NDQ4QTQ1QTQ2NUREQjkyN0M5OSZkbW5jaGc9MTsgTVVJRD0xRUZGMUNDNDUzNEE2RjRDMTdCNjBFODQ1MjEwNkUxOTsgX1VSPVFTPTAmVFFTPTA7IE1VSURCPTFFRkYxQ0M0NTM0QTZGNEMxN0I2MEU4NDUyMTA2RTE5OyBNTUNBU009SUQ9REYwMUU5RTFBMDIzNEQ3OUEwNzIxODM3OUYzQzUxNUU7IEJDUD1BRD0xJkFMPTEmU009MTsgTWljcm9zb2Z0QXBwbGljYXRpb25zVGVsZW1ldHJ5RGV2aWNlSWQ9MzlkMDNjMjQtYTYxZS00MDA4LTlkOTktYmIwNTRlZTI2MTA3OyBfRURHRV9DRD11PWVuLXVzOyBVU1JMT0M9SFM9MSZFTE9DPUxBVD0yOS4zODU3MTE2Njk5MjE4NzV8TE9OPTEwNi40OTkxNjgzOTU5OTYxfE49QmFcJ25hbiUyMERpc3RyaWN0JTJDJTIwQ2hvbmdxaW5nfEVMVD00fDsgU1JDSFVTUj1ET0I9MjAyMzEwMjYmVD0xNzAwNDU2OTIyMDAwJlRQQz0xNzAwNDQ1MjI3MDAwJlBPRVg9VzsgX1U9MWh1MFBzNkQ4YWxIVmZkSWp5aTJ4UXVPV08xbkJabm1qYzBvbUQ3Yko5cnpCU002NzFjVmFMeEdJcElGVXczUWVLaGtDYWg0elhiS1N1QVNEbm1lYXdwdllPODRWUFZBckZPa3hoOFFOcl93TzE3b19ranRRYzQtNE50NFY1c1V3YUs5TnhNZVU2a2tlU0hLd0oyVnM2enlQR1JkeXhVY2s2c0hhTml0UlVXUGZ0M29id2VBeXpmZ1VxdGNtY2diRDJYcm1aQXpMR0pjdElMRWtsU0ZmVlE7IFBQTFN0YXRlPTE7IE5BUD1WPTEuOSZFPTFjYjkmQz12VVAybzVtMmhZal9GTDN4STlEZFY1QXR3cTVDTjJya0IteTBEQTRWTUIwbGRmMXlIVjhQb3cmVz0xMDsgS2lldlJQU1NlY0F1dGg9RkFCYUJCUmFUT0pJTHRGc01rcExWV1NHNkFONkMvc3ZSd05tQUFBRWdBQUFDQnhyQnFCdTlHNmxHQVRrd1lDSWV5enEvblVRZjJQVENTUmMzQ2dNNVhsTUx4Y3phdzl0ekx1Z25QT3IxNlRjWW9TdGg2SytCekI0ZCtQSllZSjFZeE1udWIrSHdlTEdqWkUxOGNKNVJHZVhPb05kZ0pWWSs2S3A0NDAwVmpranQ5TWJDTUFUV1ExMjZpV3hxTHAwUDdCRlRZaWhURUFwcC90ZkxuNkViTUo0dnNFK3dQUWRMK3RZQmQrWXdETm9ITnJFL1FocXZwQmxtNVkzMVdvc3Yrd3piSVpKa0oyejFjZXR0VlpUcVNISHE3TkRpRTVWa2E0c2VHdzVoanlJUXpMcUorWFpXdVRMaVg4djFibUt6VEZkaWE2Q2JzdkRjTVo4bHJoTmNpUm1MamRHelZad3VlOVZNNkNqSE95SldyQjA5Y29JWGYvL2tUTGNnVTg4ckE3OE80TmZoaHB4SmxoQ3diVDI5U0dIOHpZby91dWlRK0hFNXBwNEk2b3hacnBtaG8vQ3lYZndWZnF5VEhYcGNFUUdwRE03L202TzhMZXJFMVdqeFVpYUV5ZXdRUERtUlc3WUJSUXF5UFN5ZWxZZmRQOGNGNnhON3FWRDJBOFJQN0JMTDRQay9uTE15NFN6eU5TcTFLVVRiZ2Y0ZW5iTk5GM0pja3VGU1Z4b1U4MUc0U04rL0lZeUF0N3ZoQkpyMFkwc0JNaFZUT1VzUTdtR0JoSDdweVJ2ODdaNGVzVkR6VWREcFVEVk5xUGNoMzRKOGJ5Wk95UDVMVUh3Y1c4QldPQURmc2dQNTJSSE41RlMza2JVQkZkZURpckVFK0hiLzB5OTQzaTgzaDBEanpqaFZ4MW01VmZGNzI5dlNkczhDU2NFVjhZa1dFY3pyNmFYb2tVdEJEejUwUkJpR2JSeVFnZk1BTlB6bXFncys0UWpxL2NpSUtPMG5NNjJsalljSm0rS21KSTZKc0syTDlhWmVvNXlsaWpFRFg4dzI4VDVmWnFydzV0Um96RGlnZzFSQVZINjVmSDk4bUdVUEtnOFRaTzZDZklnSWx4WmJoL2JIbFQ5aWxzN3l5VnU3cXVTTFRqMGYxN3V6UGllUXFqbEdjT2RBbDE1dFBQOVlXY05mRVFIbzUySkhDeVZ1NzltdnVLZEIyU1lodmU1U2NHS2pYVVVsR01mbWZrMnpxbEdFSzg2UGRhM0grN2JJczdnNGQzVGZLRnFUSlFVeFBqdnFTUFVtWG9La3VXeEw5ckxzTFZMajkrRE1OdVBNUzk4Sng5M0ltazFpQ2lzN1Y4T0dtQUZ2Y0pQLzdvaWZCRnNyRXhvRmNnbWg3UUJpQ0o3Z21ETmIyb2dBWVNGYmZON2ZDbDJieU5PNTBXVWdueXBrTlRTL3MyZjZSNm92NEdiZjlmVi92OHV5VURIdDBKay9FSUNJT29ZdHpmRVM5V3liaXhMYnpJZHk3YjJtVWF3RzJDQnhOVGR4UmlhNW1kNzZjZlViK1pHcnFGYTV1WDZLcmRXQkkzbGtISnhwVU93anIvdlNmaGo3aWM4TzdoNGg2VHNPcEViMlJCQ01UR1BDdTlLWGh4YzB0ejA2YVYySzVaeWNLS0NkUnM0c0Y2MHNkMXcwcE1udldiU3JjVndmcGhYeU5oZ3hhakU1U0Y4NDM2V2ZrZHdaOTgxeEZYRHI2bGxLNXhMTmVRSDNmSUt1K21DSzEzVVFBLzdhdnpuYVJ4U3RtdWFYV2hoNU5TdC9tTDJocmFYdzNNTm1aSHg0VDIyeU0rUG1aU0FGOVB4cGhGUDdJWTByQWRFUUFkS0VhSFJ4YWJxZlU5MDhZS1RlNXh4Vkt1Ulo2K3FXVEZtNml5NVNKUTBqdGVoVC9oZEZBQURNZyt3WWZEQ3JJOTg2eXY0RlFoR2tnbXhKQT09OyBBTk9OPUE9OUEyNDcwQjc4MzI2NEIyMzMwNzAyOEFGRkZGRkZGRkYmRT0xZDEzJlc9MTE7IFdMSUQ9Q2JOVU96bnU1UHgyNy9scXpvVU1wRXQ0d2VkVHhkMnNCWGkrbFd5WlBTNndDdGk5ZDZQczFVMDhYeWZYK2FvbWFoQS80Mzh0M3RqbzZKVWMxcm13OFRoalBQYVhUZDRLeWhURVBGdG9KTVU9OyBfSFBWTj1DUz1leUpRYmlJNmV5SkRiaUk2T0N3aVUzUWlPakFzSWxGeklqb3dMQ0pRY205a0lqb2lVQ0o5TENKVFl5STZleUpEYmlJNk9Dd2lVM1FpT2pBc0lsRnpJam93TENKUWNtOWtJam9pU0NKOUxDSlJlaUk2ZXlKRGJpSTZPQ3dpVTNRaU9qQXNJbEZ6SWpvd0xDSlFjbTlrSWpvaVZDSjlMQ0pCY0NJNmRISjFaU3dpVFhWMFpTSTZkSEoxWlN3aVRHRmtJam9pTWpBeU15MHhNUzB5TUZRd01Eb3dNRG93TUZvaUxDSkpiM1JrSWpvd0xDSkhkMklpT2pBc0lsUnVjeUk2TUN3aVJHWjBJanB1ZFd4c0xDSk5kbk1pT2pBc0lrWnNkQ0k2TUN3aVNXMXdJam8xTml3aVZHOWlZbk1pT2pCOTsgU25yT3ZyPVg9cmViYXRlc29uOyBfUndCZj1yPTEmaWx0PTImaWhwZD0yJmlzcGQ9MCZyYz00NiZyYj00NiZnYj0wJnJnPTAmcGM9MCZtdHU9MCZyYmI9MC4wJmc9MCZjaWQ9JmNsbz0wJnY9MyZsPTIwMjMtMTEtMTlUMDg6MDA6MDAuMDAwMDAwMFombGZ0PTAwMDEtMDEtMDFUMDA6MDA6MDAuMDAwMDAwMCZhb2Y9MCZvPTAmcD1CSU5HQ09QSUxPVFdBSVRMSVNUJmM9TVIwMDBUJnQ9NTI0NyZzPTIwMjMtMDgtMjJUMTE6MTU6NDguNjMxMjE2MSswMDowMCZ0cz0yMDIzLTExLTIwVDA1OjEwOjQ4LjU2ODg2NjYrMDA6MDAmcndyZWQ9MCZ3bHM9MiZ3bGI9MCZsa2E9MCZsa3Q9MCZhYWQ9MCZUSD0mbXRhPTAmZT1MaEFMSWJmMVV1elJYNS1FRENoTWFwUVBjMGtoTGc5STF3aHNheW5ScWVHbXRfWUdUOHJwU3c1RXdkZG1RNnRhNlFwOGxnX2w4S1EyS1VBaXdTRGxvUSZBPTlBMjQ3MEI3ODMyNjRCMjMzMDcwMjhBRkZGRkZGRkZGOyBTUkNISFBHVVNSPVNSQ0hMQU5HPWVuJkJaQT0wJkJSVz1OT1RQJkJSSD1TJkNXPTQyMiZDSD02MTEmU0NXPTQwNiZTQ0g9NjExJkRQUj0xLjMmVVRDPTQ4MCZETT0wJlBWPTAuMS4wJkhWPTE3MDA0NTcwNDgmV1RTPTYzODM2MDUzNzM3JklHPUQyOTZGNURBMTkzRjQ3Mzg5OTlGOTI0ODc0RUYxNTkyJlBSVkNXPTExNTImUFJWQ0g9NjExJkNJQlY9MS4xMzU5LjYmY2R4dG9uZT1DcmVhdGl2ZSZjZHh0b25lb3B0cz1oM2ltYWdpbmF0aXZlLGNsZ2FsaWxlbyxnZW5jb250ZW50djMsZmx1eHYxNDsgY2N0PVVrOXJqRFNWQXVlbUQ1aUU0NEJrMG8zYkJ6emRZTmIwSmsxbHpxb25EbzRBVExsRmxENXRUcnE5MmxEUW9CY09SNzhYNUVwT0Z5WmE4dTRiY01PY3JBOyBfRURHRV9TPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MDsgV0xTPUM9NjM2YWI2YWNiODU4YzBkMCZOPWpva3lvMjsgX1NTPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MCcgXCAgIC1IICdzZWMtY2gtdWE6ICJOb3RfQSBCcmFuZCI7dj0iOTkiLCAiR29vZ2xlIENocm9tZSI7dj0iMTA5IiwgIkNocm9taXVtIjt2PSIxMDkiJyBcICAgLUggJ3NlYy1jaC11YS1hcmNoOiAieDg2IicgXCAgIC1IICdzZWMtY2gtdWEtYml0bmVzczogIjY0IicgXCAgIC1IICdzZWMtY2gtdWEtZnVsbC12ZXJzaW9uOiAiMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1mdWxsLXZlcnNpb24tbGlzdDogIk5vdF9BIEJyYW5kIjt2PSI5OS4wLjAuMCIsICJHb29nbGUgQ2hyb21lIjt2PSIxMDkuMC41NDE0LjEyMCIsICJDaHJvbWl1bSI7dj0iMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1tb2JpbGU6ID8wJyBcICAgLUggJ3NlYy1jaC11YS1tb2RlbDogIiInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtOiAiV2luZG93cyInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtLXZlcnNpb246ICIwLjEuMCInIFwgICAtSCAnc2VjLWZldGNoLWRlc3Q6IGRvY3VtZW50JyBcICAgLUggJ3NlYy1mZXRjaC1tb2RlOiBuYXZpZ2F0ZScgXCAgIC1IICdzZWMtZmV0Y2gtc2l0ZTogY3Jvc3Mtc2l0ZScgXCAgIC1IICdzZWMtZmV0Y2gtdXNlcjogPzEnIFwgICAtSCAndXBncmFkZS1pbnNlY3VyZS1yZXF1ZXN0czogMScgXCAgIC1IICd1c2VyLWFnZW50OiBNb3ppbGxhLzUuMCAoV2luZG93cyBOVCAxMC4wOyBXaW42NDsgeDY0KSBBcHBsZVdlYktpdC81MzcuMzYgKEtIVE1MLCBsaWtlIEdlY2tvKSBDaHJvbWUvMTA5LjAuMC4wIFNhZmFyaS81MzcuMzYnIFwgICAtLWNvbXByZXNzZWQ=" RUN apt-get update && apt-get install -y git # Set home to the user's home directory ENV HOME=/home/user \ PATH=/home/user/.local/bin:$PATH # Set up a new user named "user" with user ID 1000 RUN useradd -o -u 1000 user && mkdir -p $HOME/app && chown -R user $HOME # Switch to the "user" user USER user # Set the working directory to the user's home directory WORKDIR $HOME/app # 从 GitHub 克隆 weaigc/bingo 项目到 /workspace/app 目录下 RUN git clone https://github.com/SokWith/bingo.git ./ # Copy the current directory contents into the container at $HOME/app setting the owner to the user COPY --chown=user . $HOME/app/ RUN npm install && npm run build RUN rm -rf src ENV PORT 7860 EXPOSE 7860 CMD npm start
能不能绘图跟dockerfile没关系,应该是BING_HRADER设置问题
https://github.com/Harry-zklcdc/go-proxy-bingai/issues/251#issuecomment-1826460533 我在隔壁goproxybingai项目公开了一个自动过验证的接入点服务器地址:
ENDPOINT="cfree.nbing.eu.org"
能避免创建失败请重试故障,目前针对大多数云商(已测试replit,huggingface,zeabur)都是有效的。
goproxybingai
好的,感谢
https://github.com/Harry-zklcdc/go-proxy-bingai/issues/273#issue-2040854616 @weaigc 评估一下这个方案 bingo项目没有过验证的api,主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害,要想服务不中断,还得靠有效的ID。
大佬,检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接?
https://github.com/Harry-zklcdc/go-proxy-bingai/issues/273#issue-2040854616 @weaigc 评估一下这个方案 bingo项目没有过验证的api,主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害,要想服务不中断,还得靠有效的ID。
大佬,检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接?
经测试,人机验证依旧反复出现,首页的最新cookies仍然需要认证,此方案无效。
反倒是尝试了一下挂机自动过验证。。
https://github.com/Harry-zklcdc/go-proxy-bingai/issues/273#issuecomment-1857478341
Harry-zklcdc/go-proxy-bingai#273 (comment) @weaigc 评估一下这个方案 bingo项目没有过验证的api,主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害,要想服务不中断,还得靠有效的ID。 大佬,检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接?
经测试,人机验证依旧反复出现,首页的最新cookies仍然需要认证,此方案无效。
反倒是尝试了一下挂机自动过验证。。
我似乎又找到了一条bingo利用推送cookie的道路:
1、注释掉这行代码
2、ENDPOINT指向隔壁go-proxy-bingai项目部署在cf上的服务器
3、当然,cf服务器需要加载推送的cookie
效果如图:
再也不用担心服务不可用了,bingo做GPT的API也稳定了。
@weaigc 大佬,看看怎么优化?
Harry-zklcdc/go-proxy-bingai#273 (comment) @weaigc 评估一下这个方案 bingo项目没有过验证的api,主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害,要想服务不中断,还得靠有效的ID。
大佬,检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接?
发现简单的方法,在cf上的部署就可以直接调用KV存储的cookie。
自动登录帐号解决了,但是: @weaigc 大佬,这个登录的帐号不能画图,为什么要做两套账户逻辑?直接合并了吧。
注:我两个项目调用同一个cookie,隔壁能画图,本项目不能直接画图。
Harry-zklcdc/go-proxy-bingai#273 (comment) @weaigc 评估一下这个方案 bingo项目没有过验证的api,主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害,要想服务不中断,还得靠有效的ID。 大佬,检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接?
经测试,人机验证依旧反复出现,首页的最新cookies仍然需要认证,此方案无效。 反倒是尝试了一下挂机自动过验证。。 Harry-zklcdc/go-proxy-bingai#273 (comment)
我似乎又找到了一条bingo利用推送cookie的道路: 1、注释掉这行代码
2、ENDPOINT指向隔壁go-proxy-bingai项目部署在cf上的服务器 3、当然,cf服务器需要加载推送的cookie
效果如图:
再也不用担心服务不可用了,bingo做GPT的API也稳定了。
@weaigc 大佬,看看怎么优化?
@SokWith 大佬,我是代码小白。想用bingo做GPT4的API。请问你是如何部署并让它稳定的?能出一个教程吗?另外,关于如何使用openai格式调用我也没有看懂,方便也出一个教程吗?
想用bingo做GPT4的API。请问你是如何部署并让它稳定的?能出一个教程吗?另外,关于如何使用openai格式调用我也没有看懂,方便也出一个教程吗?
也是小白,都是按大佬的教程部署的,只是使用了登录帐号来使用。 运行下来发现做API有显著缺陷,每一个问话就消耗一个对话资格,1个对话问上7、8次就消耗7、8个对话资格,登录帐号一天也就100个左右的对话资格,很快就被用完达到数量限制了。
想用bingo做GPT4的API。请问你是如何部署并让它稳定的?能出一个教程吗?另外,关于如何使用openai格式调用我也没有看懂,方便也出一个教程吗?
也是小白,都是按大佬的教程部署的,只是使用了登录帐号来使用。 运行下来发现做API有显著缺陷,每一个问话就消耗一个对话资格,1个对话问上7、8次就消耗7、8个对话资格,登录帐号一天也就100个左右的对话资格,很快就被用完达到数量限制了。
@SokWith 请问大佬的教程在哪里,方便给个链接吗? 请问这个对话资格的消耗问题有没有解决方法?还是只能换个账号?
想用bingo做GPT4的API。请问你是如何部署并让它稳定的?能出一个教程吗?另外,关于如何使用openai格式调用我也没有看懂,方便也出一个教程吗?
也是小白,都是按大佬的教程部署的,只是使用了登录帐号来使用。 运行下来发现做API有显著缺陷,每一个问话就消耗一个对话资格,1个对话问上7、8次就消耗7、8个对话资格,登录帐号一天也就100个左右的对话资格,很快就被用完达到数量限制了。
@SokWith 请问大佬的教程在哪里,方便给个链接吗? 请问这个对话资格的消耗问题有没有解决方法?还是只能换个账号?
你都不看readme吗? https://github.com/weaigc/bingo/blob/main/OPENAI.md
运行下来发现做API有显著缺陷,每一个问话就消耗一个对话资格,1个对话问上7、8次就消耗7、8个对话资格,登录帐号一天也就100个左右的对话资格,很快就被用完达到数量限制了。
@SokWith 事实上可以用数据缓存和匹配的方式来复用之前 create 好的 session,以减少对话额度的消耗。
比如,用户传入数据格式为:
{
"model": "bingo",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Hello!"
}
],
"temperature": "0.1",
...
}
那么 Bing 回复一次之后,用户再次传入的数据为:
{
"model": "bingo",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Hello!"
},
{
"role": "assistant",
"content": "Hi! How can I help you today?"
}
],
"temperature": "0.1",
...
}
也即其他参数和 message 相同,仅多了一条 role
为 assistant
的 message。
故而可将此特征视为用户在同一 session 的下一轮对话行为,因此可复用之前的 session。
在工程实现中需要考虑如下问题:
我主页的 bing-chat-api 就在考虑实现这个机制。
以上讨论脱离了此 issue 的主题,可以新建一个 issue 讨论。
我主页的 bing-chat-api 就在考虑实现这个机制
@Hansimov 爬过去看了一下,小白没明白怎么用?要自己写前端吗?不能像这个项目一样直接使用现有的前端(比如Nextchat)吗?
我主页的 bing-chat-api 就在考虑实现这个机制
@Hansimov 爬过去看了一下,小白没明白怎么用?要自己写前端吗?不能像这个项目一样直接使用现有的前端(比如Nextchat)吗?
话说你nbing.eu.org上面那个自带ID的站为什么长期处于不可用状态,我自己没有搭建带ID的站点(基于推送),偶尔点击你的站点使用。
最近发现进入站点之后,会有云服务商的错误❌提示。
而且有时候会这样:
nbing.eu.org上面那个自带ID的站为什么长期处于不可用状态,我自己没有搭建带ID的站点(基于推送),偶尔点击你的站点使用。
最近发现进入站点之后,会有云服务商的错误❌提示。
而且有时候会这样:
1、目前CSB的部署需要保活,测试性质没有管他。
PS:我自己有另外在huggingface上的推送站点就不存在保活的问题(使用同一个推送服务器);
2、应该是我测试关闭了U值的推送(后来忘记打开了),造成不能画图。
推送确实很好用,即使不搭建自动推送服务器。由于CF的站点可以直接调用KV存储,所以站点上的部署最好都加上推送调用。想匿名使用就在非bing站点推送一下非法cookie,想登录使用就在bing站点推送一下,切换太方便了。
经过一段时间的观察及网友们的探索,目前已知 New Bing 的封锁等级为以下几种,程度依次递增,不同强度的解决办法也不一样:
除第5级封锁外,其它级别的过段时间会自动解除,但是很容易再次出现,所以比较好的办法是直接换机器