meting-api
meting-api copied to clipboard
injahow
QQ音乐需要VIP的歌曲无法播放
这个歌单（歌单id：8416946164 ）中需要VIP的歌曲全部都无法播放，访问解析出来的json中需要VIP的歌曲的url字段的链接一片空白
测试用的接口没有提供QQ音乐的VIP权限，类似需求请自建API服务并设置cookie后使用
这个歌单（歌单id：8416946164 ）中需要VIP的歌曲全部都无法播放，访问解析出来的json中需要VIP的歌曲的url字段的链接一片空白
测试用的接口没有提供QQ音乐的VIP权限，类似需求请自建API服务并设置cookie后使用
我有自建的，不过不知道如何抓取QQ音乐的cookie并设置，能否给个文档或者教程？
这个歌单（歌单id：8416946164 ）中需要VIP的歌曲全部都无法播放，访问解析出来的json中需要VIP的歌曲的url字段的链接一片空白
测试用的接口没有提供QQ音乐的VIP权限，类似需求请自建API服务并设置cookie后使用
我有自建的，不过不知道如何抓取QQ音乐的cookie并设置，能否给个文档或者教程？
一般登陆后在浏览器的对应网页获取Cookie即可，例如谷歌浏览器地址栏左侧可查看所有Cookie，你也可以使用浏览器插件"EditThisCookie"获取页面的所有Cookie，设置Cookie就按照 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L54-L58 并增加网站判断设置即可
问题QQ音乐登录之后一大堆网络请求，不知道哪一个请求的cookie才是需要的……
我的意思是，把所有Cookie全加上，无脑式操作
26对cookie，全部怼上去吗，我刚刚清除过这个网站的cookie，输完账号密码点登录按钮前又点了一次清空按钮之后再登录的结果
问题QQ音乐登录之后一大堆网络请求，不知道哪一个请求的cookie才是需要的……
我的意思是，把所有Cookie全加上，无脑式操作
如果你能确定这些Cookie里面有身份验证的就行了，请求使用的Cookie可能只是一部分
问题QQ音乐登录之后一大堆网络请求，不知道哪一个请求的cookie才是需要的……
我的意思是，把所有Cookie全加上，无脑式操作
如果你能确定这些Cookie里面有身份验证的就行了，请求使用的Cookie可能只是一部分
我在网页上登录账号之后访问歌单分享页面，把请求头中的cookie字段的值全部填上去了，目前VIP歌曲是能播了，但有一首歌登陆前显示下架、登录后在网页中能播放的歌曲（歌曲id：001woau90t4SQZ）仍然无法播放，另外不知道cookie有效期是多久，有没有啥能自动抓取cookie提交的工具
顺带问问“AUTH密钥”是咋用的如果设置了的话，还有就是api通过有VIP的账号输出的json的url字段302后的链接能一直有效吗
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
cookie我看浏览器里面显示的过期时间长短不一，有十几年后过期的字段，也有几个月后过期的字段，也有几个小时过期的，正常的QQ音乐客户端通过正常手段登录的，掉登录的时间我都摸不准，有时候几个月都不会掉登录，有时候前几天刚登录完就又掉了，网页端抓的cookie让我更摸不着头脑了
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET~~连接的字符串~~计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET~~连接的字符串~~计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
这个你看看那个auth函数和获取歌单的代码就知道了 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L79-L85 需要注意的是，如果你希望只有自己能够请求自己的api，需要自己修改代码，处理歌单请求
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见
https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
看到了，我正在看PHP官方文档对这个函数的解释 https://www.php.net/manual/zh/function.hash-hmac.php 之前写PHP弄不可逆加密一直用的MD5和password_hash，不过我设置了auth的参数后我才明白过来“开启后只有歌单类型可以获取数据”指的是啥了，开启之后只有歌单还能继续不传auth这项参数是能继续正常获取的，另外我还发现了这个（ https://github.com/1015770492/autoLoginQQWithAnyWeb ），我也在研究怎么在服务器端把它对接起来
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
看到了，我正在看PHP官方文档对这个函数的解释 https://www.php.net/manual/zh/function.hash-hmac.php 之前写PHP弄不可逆加密一直用的MD5和password_hash，不过我设置了auth的参数后我才明白过来“开启后只有歌单类型可以获取数据”指的是啥了，开启之后只有歌单还能继续不传auth这项参数是能继续正常获取的，另外我还发现了这个（ https://github.com/1015770492/autoLoginQQWithAnyWeb ），我也在研究怎么在服务器端把它对接起来
ok, good luck for you !
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
看到了，我正在看PHP官方文档对这个函数的解释 https://www.php.net/manual/zh/function.hash-hmac.php 之前写PHP弄不可逆加密一直用的MD5和password_hash，不过我设置了auth的参数后我才明白过来“开启后只有歌单类型可以获取数据”指的是啥了，开启之后只有歌单还能继续不传auth这项参数是能继续正常获取的，另外我还发现了这个（ https://github.com/1015770492/autoLoginQQWithAnyWeb ），我也在研究怎么在服务器端把它对接起来
ok, good luck for you !
不过看了下那个仓库的issue（https://github.com/1015770492/autoLoginQQWithAnyWeb/issues/1#issuecomment-786961534 ），感觉可能性不大，一个是新IP登录的人机验证，那个仓库的作者还没解决，再一个是它要chrome，服务器不见得吃得消，不过我还在研究中
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
看到了，我正在看PHP官方文档对这个函数的解释 https://www.php.net/manual/zh/function.hash-hmac.php 之前写PHP弄不可逆加密一直用的MD5和password_hash，不过我设置了auth的参数后我才明白过来“开启后只有歌单类型可以获取数据”指的是啥了，开启之后只有歌单还能继续不传auth这项参数是能继续正常获取的，另外我还发现了这个（ https://github.com/1015770492/autoLoginQQWithAnyWeb ），我也在研究怎么在服务器端把它对接起来
ok, good luck for you !
目前我是在服务器端搭了一个这玩意（https://github.com/jsososo/QQMusicApi ），然后靠vscode端口转发到本地，把cookie post上去之后关掉端口转发，然后参考https://blog.csdn.net/zhangfeng1133/article/details/47374649 在index.php加上
$url = 'http://localhost:3300/user/getcookie?id=在前者的配置文件中设置好的QQ号';
$ch = curl_init($url);
//将头文件的信息作为数据流输出
curl_setopt($ch,CURLOPT_HEADER,1);
//返回获取的输出文本流
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
$content = curl_exec($ch);
//正则匹配
preg_match_all('/Set-Cookie:(.*);/iU',$content,$str[]);
//获得COOKIE（SESSIONID）
$cookie = $str[0][1];
curl_close($ch);
// 将cookie数组拼凑成从浏览器里面复制出来的样子
$cookie_value = implode(";",$cookie);
用来读取cookie，原来的设置cookie语句改为了
if ($server == 'tencent') {
$api->cookie($cookie_value);
}
回头再考虑开放qqmusicapi端口的事情，然后再看看把这个（ https://github.com/lonsty/qqmusic-cookie-setter ）或者这个（https://github.com/jsososo/qqmusic-cookie-porter ）改一改，从本地post新的cookie上去，也只能先这样应付一下了，另外弱弱问句你之前说的“写一个定时脚本请求VIP判断返回值”拿啥判断，这个接口请求VIP歌曲如果cookie失效的话也是返回200ok但白屏的
如果cookie填写没问题有效时间一般会比较长，你如果不放心写一个定时脚本请求VIP判断返回值就行了，我一般没怎么管，除非访问量比较大，被网站取消了登陆状态就得重新填了，我也没用过什么自动获取cookie的工具；另外这个“AUTH密钥”是参照Meting-API项目添加的，可以对你网站的API请求进行访问限制，开启后只有歌单类型可以获取数据，其他请求如果没有正确密钥（用AUTH_SECRET参数来进行混淆加密）就会返回403错误；至于302后的链接，因为使用了CDN，所以一般是会设置有效期的
“开启后只有歌单类型能正确返回数据”，我看歌单输出的json里面的值也是请求自己这个api的，有影响吗，另外auth密钥填的是加密前的值还是加密后的值
歌单输出的json在设置auth开启下（注意清除缓存）列出的地址会携带auth密钥，也就是只能通过歌单输出json来获取所有的数据，这样在一定程度上避免了爬虫的问题，那个AUTH_SECRET填一个只有自己知道的字符串就行了，地址携带的auth其实就是根据请求关键字与AUTH_SECRET连接的字符串计算出的hash，也就是知道了AUTH_SECRET就能使用算法计算auth了，当然你也可以尝试魔改代码
那我请求的时候带的auth呢，是带什么，带歌单id与auth_secret拼接的字符串用sha1计算出来的值吗
sorry，记错了，没有拼接AUTH_SECRET，是直接用其作为hash_hmac参数进行加密的，见 https://github.com/injahow/meting-api/blob/2b7b96c9b55e5dfdd99ff7a0a8adeb7560bb07aa/index.php#L143-L147
看到了，我正在看PHP官方文档对这个函数的解释 https://www.php.net/manual/zh/function.hash-hmac.php 之前写PHP弄不可逆加密一直用的MD5和password_hash，不过我设置了auth的参数后我才明白过来“开启后只有歌单类型可以获取数据”指的是啥了，开启之后只有歌单还能继续不传auth这项参数是能继续正常获取的，另外我还发现了这个（ https://github.com/1015770492/autoLoginQQWithAnyWeb ），我也在研究怎么在服务器端把它对接起来
ok, good luck for you !
目前我是在服务器端搭了一个这玩意（https://github.com/jsososo/QQMusicApi ），然后靠vscode端口转发到本地，把cookie post上去之后关掉端口转发，然后参考https://blog.csdn.net/zhangfeng1133/article/details/47374649 在
index.php加上$url = 'http://localhost:3300/user/getcookie?id=在前者的配置文件中设置好的QQ号'; //cookie临时文件 $cookie = tempnam('./','cookie'); $ch = curl_init($url); //将头文件的信息作为数据流输出 curl_setopt($ch,CURLOPT_HEADER,1); //返回获取的输出文本流 curl_setopt($ch,CURLOPT_RETURNTRANSFER,1); $content = curl_exec($ch); //正则匹配 preg_match_all('/Set-Cookie:(.*);/iU',$content,$str[]); //获得COOKIE（SESSIONID） $cookie = $str[0][1]; curl_close($ch); // 将cookie数组拼凑成从浏览器里面复制出来的样子 $cookie_value = implode(";",$cookie);用来读取cookie，原来的设置cookie语句改为了
if ($server == 'tencent') { $api->cookie($cookie_value); }回头再考虑开放qqmusicapi端口的事情，然后再看看把这个（ https://github.com/lonsty/qqmusic-cookie-setter ）或者这个（https://github.com/jsososo/qqmusic-cookie-porter ）改一改，从本地post新的cookie上去，也只能先这样应付一下了，另外弱弱问句你之前说的“写一个定时脚本请求VIP判断返回值”拿啥判断，这个接口请求VIP歌曲如果cookie失效的话也是返回200ok但白屏的
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来
我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
meting仓库我看了，最后一次的动静是两三年前……
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Android）上面都能正常播放
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同或者是客户端存在缓存，具体情况需要抓包测试，所以说比较麻烦
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同，具体情况需要抓包测试，所以说比较麻烦
确实，一开始我本来想抓客户端的cookie，结果开了burp之后一堆请求我点forward点的手腕疼，而且根本不知道哪个有用哪个没用，然后就放弃对客户端下手，转去抓网页的请求头
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同或者是客户端存在缓存，具体情况需要抓包测试，所以说比较麻烦
对了，我刚刚试着给接口传server=tencent&type=artist&id=0043wAMw0XrGgp，接口返回{"error":"unknown song id"}，歌手id换成001QY1cc2SIqpB也不行，是啥情况，bug？https://y.qq.com/n/ryqq/singer/后面跟这两个歌手id都是正常的
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同或者是客户端存在缓存，具体情况需要抓包测试，所以说比较麻烦
我改了下这个（ https://github.com/jsososo/QQMusicApi ），让它能跑在反向代理后的子目录中，然后改了下这个（ https://github.com/jsososo/qqmusic-cookie-porter ），把里面提交cookie的地方换成我自己服务器上跑的qqmusicapi的/user/setcookie的地方，接着再改了下meting-api，每次使用都去请求qqmusicapi（走localhost去请求）获取cookie，算是能跑了，然后我把那首不能播放的歌下载到本地，解析json也保存到本地，一起丢上又拍云给的储存里面，把json里面那首歌的url改成又拍云储存里面的路径，现在算是能跑起来了
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同或者是客户端存在缓存，具体情况需要抓包测试，所以说比较麻烦
对了，我刚刚试着给接口传
server=tencent&type=artist&id=0043wAMw0XrGgp，接口返回{"error":"unknown song id"}，歌手id换成001QY1cc2SIqpB也不行，是啥情况，bug？https://y.qq.com/n/ryqq/singer/后面跟这两个歌手id都是正常的
提示已经写清楚了，unknown song id 表示那个id是音乐的id，你仔细看看代码就能明白，name、artist 、url、pic都是song的内容，只是为了方便获取而设置的
我的意思是，你可以根据你的API能不能获取到用户数据（比如私有歌单，VIP歌曲地址亦可）来判断你的cookie是否失效
刚刚试了一下，设置为隐私歌单之后注释掉cookie相关的几行代码会返回
{"error":"unknown playlist id"}，现象比获取VIP歌曲明显多了，是个用来判断的好方法，不过这首歌（id：001woau90t4SQZ）我登录之后在网页中是能够播放的，不知道为啥设置cookie之后仍然无法解析出来我看了一下，页面提示"很抱歉，您查看的歌曲已下架"，音乐网站版权等问题比较多，有些请求被限制了，想深挖就要费点功夫，说不准哪天又能播放了，如果你VIP账号可以访问，那可能需要修改源代码，建议查看Meting的最新版本或到其仓库提交issues
这首歌我登录之后在网页版上面我的歌单里面显示能播放，但点进去实际上也是不能播放，直接打开歌曲详情也是不能播放，但奇怪的是这首歌在客户端（win&Linux&Android）上面都能正常播放
可能是客户端请求的接口和网页端不同或者是客户端存在缓存，具体情况需要抓包测试，所以说比较麻烦
我改了下这个（ https://github.com/jsososo/QQMusicApi ），让它能跑在反向代理后的子目录中，然后改了下这个（ https://github.com/jsososo/qqmusic-cookie-porter ），把里面提交cookie的地方换成我自己服务器上跑的qqmusicapi的
/user/setcookie的地方，接着再改了下meting-api，每次使用都去请求qqmusicapi（走localhost去请求）获取cookie，算是能跑了，然后我把那首不能播放的歌下载到本地，解析json也保存到本地，一起丢上又拍云给的储存里面，把json里面那首歌的url改成又拍云储存里面的路径，现在算是能跑起来了
你这样也行，不过cookie没必要每次都修改吧