Closed danni-cool closed 3 months ago
我没有写v1接口的逻辑,只让v2接口支持了
我没有写v1接口的逻辑,只让v2接口支持了
看了下v1 v2都加了,v1 和 v2 底层用的服务是一样的
@Cassius0924 考虑优化方案:
使用 https://download.samplelib.com/jpeg/sample-clouds-400x300.jpg?_alias=cloud.jpg
参数格式化另存的文件名。
理由:
?_alias=cloud.jpg
可以最大限度不破坏原始逻辑,改动的地方少。curl --location 'http://localhost:3001/webhook/msg/v2?token=[YOUR_PERSONAL_TOKEN]' \
--header 'Content-Type: application/json' \
--data '{
"to": "testGroup",
"isRoom": true,
"data": { "type": "fileUrl" ,
"content": "https://download.samplelib.com/jpeg/sample-clouds-400x300.jpg?
_alias=123.jpg,https://download.samplelib.com/jpeg/sample-clouds-400x300.jpg?_alias=321.jpg"
},
}'
大佬,话说可不可以先post一张图片到你的服务端,然后你返回一个uuid,我再用这个uuid去发送图片消息,post可以把文件的详细信息都包含了
这样也只要加一个api和接口多加一个功能罢了
大佬,话说可不可以先post一张图片到你的服务端,然后你返回一个uuid,我再用这个uuid去发送图片消息,post可以把文件的详细信息都包含了
为什么不作为前置处理流程,让发送这个过程更加单一,比如你下载图片到服务器,判断信息啥的,这个单独是一个服务,然后你同一台服务器再去读这个文件去发送,或者提供服务器内部的相对路径地址去发送
我怎么没懂
使用 _alias 命名避免和服务提供商 alias 参数重名
不能保证服务提供商不会使用_alias
作为参数名,我认为更安全的做法可以使用??
作为分隔符。
https://download.samplelib.com/jpeg/sample-clouds-400x300.jpg??alias=123.jpg
我怎么没懂
加上以上逻辑确实可用,但我推荐你fork加自己开发,wechatbot-webhook 是一个工具,但是增加图片服务器逻辑,会让这个服务更加像业务而不是一个通用的工具。另外发送的过程也复杂了,可能对于你来说是一个刚需,但是对于其他人来说可能是冗余。
我说的做法是图片服务就是图片服务,负责管理图片上传返回uuid or url之类, 消息服务就是消息服务,负责解析和下载图片并且发送, 服务之间通过api链接,各司其职。
不是不是,其实就是先把带有名字的图片缓存一下而已
不是不是,其实就是先把带有名字的图片缓存一下而已
大图避免二次下载是吗
并且我也不会js
不是不是,其实就是先把带有名字的图片缓存一下而已
大图避免二次下载是吗
是这样的,我详细的说一下 我先post一个提前备好的图片数据并在json里包含文件类型等信息,然后我可以拿一个方式比如uuid这样的去把这个图片发送出去
不是不是,其实就是先把带有名字的图片缓存一下而已
大图避免二次下载是吗
是这样的,我详细的说一下 我先post一个提前备好的图片数据并在json里包含文件类型等信息,然后我可以拿一个方式比如uuid这样的去把这个图片发送出去
文件什么的都可以这么写
@hhhhhge 该pr不再讨论这个事情,请移步 https://github.com/danni-cool/wechatbot-webhook/issues/190
使用 _alias 命名避免和服务提供商 alias 参数重名
不能保证服务提供商不会使用
_alias
作为参数名,我认为更安全的做法可以使用??
作为分隔符。https://download.samplelib.com/jpeg/sample-clouds-400x300.jpg??alias=123.jpg
??
不符合url规范。。无论咋命名都有重名风险,只能说找一个不那么容易重名的命名空间,比如_alias, $alias 等等..
?? 不符合url规范
就是要找一个不符合 URL 规范的分隔符呀,然后将使用.spilt("??")
,将前面的作为真实URL,后面作为别名。
?? 不符合url规范
就是要找一个不符合 URL 规范的分隔符呀,然后将使用
.spilt("??")
,将前面的作为真实URL,后面作为别名。
这样解析url 就有些问题,举个例子,阿里oss的图床支持边缘计算,https://oss.aliyun.com/img.png?_width=100&_height=100&_quality=70, 用了?? 破坏了url规范,直接导致原链接不可用。解析一个url,使用规范解析,比字符串分割更加格式化,这里不是只是单纯作为字符串考虑
话说这种链接是要在图片下载并发送的接口里用的吗
话说这种链接是要在图片下载并发送的接口里用的吗
如果写进请求头里怎么样呢
话说这种链接是要在图片下载并发送的接口里用的吗
如果写进请求头里怎么样呢
是一种解题思路,相比较于目前已经实现的方案,会增加复杂度。
话说这种链接是要在图片下载并发送的接口里用的吗
如果写进请求头里怎么样呢
是一种解题思路,相比较于目前已经实现的方案,会增加复杂度。
但是非常符合http和url的协议
但是非常符合http和url的协议
但是一般不会在http请求头里带业务数据吧,我还是建议将数据都放在请求体里
但是非常符合http和url的协议
但是一般不会在http请求有里带业务数据吧,我还是建议将数据都放在请求体里
写请求头怎么就不行了,反正数据不是给其他人看的,并且也是正常操作啊
但是非常符合http和url的协议
但是一般不会在http请求有里带业务数据吧,我还是建议将数据都放在请求体里
写请求头怎么就不行了,反正数据不是给其他人看的,并且也是正常操作啊
有的网站也会在请求头里夹带私货
但是非常符合http和url的协议
但是一般不会在http请求有里带业务数据吧,我还是建议将数据都放在请求体里
写请求头怎么就不行了,反正数据不是给其他人看的,并且也是正常操作啊
不是不行,每一种技术都可以解决问题,只是在实现的过程中,需要结合现有代码,维护成本,实现成本,易用性等给出最优解,实现其实是最简单的
❤️ contributor: @Cassius0924
todo @danni-cool
接口参数校验检查推消息v1 接口参数检查推消息 v2 接口参数检查