Closed sesanzb closed 3 years ago
Dis you test your fallback call? That api endpoint no longer works for user and gives captcha data object. This will only add unsuccessful request and add more bandwidth usage.
Please make latest pull and merge your getUserFeedByID with latest changes.
On Tue, 16 Feb 2021 at 19:09 Sergio Sanz Barrio notifications@github.com wrote:
You closed previously request without any comment, don't know if something is wrong. I've respected all current names and functionalities. I've extended getUserFeed creating getUserFeedByUserId in order to have a function that gets only video feed without user call, in case of need. I've made a first call to https://www.tiktok.com/node/share/user/@{$username} in getUser function and maintain the call https://www.tiktok.com/@{$username} as fallback if the first fail in order to reduce data consuption (proxy price reduction) Tell me if I need to make changes or something, please.
You can view, comment on, or merge this pull request online at:
https://github.com/ssovit/TikTok-API-PHP/pull/23 Commit Summary
- Merge pull request #1 from ssovit/master
- Merge pull request #2 from ssovit/master
- Create ICacheEngine.php
- Delete ICacheEngine.php
- Create ICacheEngine.php
- Update Api.php
- Release 1.3.0
- Update Api.php
- Merge branch 'master' into 1.3.1
- Merge pull request #3 from sesanzb/1.3.1
- Release 1.3.1
File Changes
- M lib/TikTok/Api.php https://github.com/ssovit/TikTok-API-PHP/pull/23/files#diff-5771b486356ac012a51218a7bf9ed72d9d7c0e13c0a9a842ae1520e684e6f5af (82)
- A lib/TikTok/ICacheEngine.php https://github.com/ssovit/TikTok-API-PHP/pull/23/files#diff-e1e0bcdfcd9b3ed5e20b46c5fbcc8f2282f0ea4b535799749c48d043945ba959 (11)
- M package.json https://github.com/ssovit/TikTok-API-PHP/pull/23/files#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519 (2)
Patch Links:
- https://github.com/ssovit/TikTok-API-PHP/pull/23.patch
- https://github.com/ssovit/TikTok-API-PHP/pull/23.diff
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ssovit/TikTok-API-PHP/pull/23, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYEACXZGTRQGPKOWD7KF3DS7JWYRANCNFSM4XWOKUGA .
-- Sent from my iPhone
Yes I did! I tested the https://www.tiktok.com/node/share/user/@username endpoint with multiple accounts It's working again without login or captcha. In the worst case if it fails, it's just about 1,2 KB added to bandwidth usage, but if it works is 65 KB less
In any case, I could remove it if you are not pleased
It doesn't work and give this on my end..
Maybe it's a problem with your cookie file. That's other topic... Your method is calling always with the last cookie file generated, and if it is a cookie with captcha needed, next calls always need the captcha. In my development, I delete the cookie file every time the service return false, and it works perfectly with and without proxy
Has you tried it on a web navigator? https://www.tiktok.com/node/share/user/@sesanz
This won't work as user need cookies for next request and the next.. your use case may be dependent on user and user feed but not all.. You can fork and make changes as per your requirements and use as you please...
True! I mean. If getUser returns false there is no more calls as this first call fails, so I remove the cookie file, that is generated with next call. You may not use the same cookie for another call, that's the mistake, and that's the cause you got the 10000 code response. It's failing with the https://www.tiktok.com/@{$username} endpoint also if you dont remove a bad cookie.
Example with fresh installation:
It's needed to clean the cookie file. That's the reason you get bad response from https://www.tiktok.com/node/share/user/@ endpoint but also the current endpoint fails
Anyway, you dont want the call to https://www.tiktok.com/node/share/user/@ even if it works, right? Do you want me to add any of the improvements?
Yes.. it doesn't work and have over-head requests which don't work with existing sessions...
OK! No worries, forgive me if I have disturbed you. But...
I have made lot of test, thousand of accounts, with multiple proxies and without... and only deleting from time to time the cookie file (when API returns false) is possible to continue without empty response
I just wanted to collaborat, do not hate me! ;P
I don't hate you, and would never. But your pull request is incomplete and undocumented (no readme updated).
Your changes with additional methods only affect user (getUserFeedById), but not challenge, and music.
The API endpoint you are using was used before in this library, but it's not working right now due to changes from TikTok and would not revert to that unless it's more stable.
I appreciate and makes me happy that you are making pull request and want to collaborate.
Ok, i'll try to collaborate when you need. I'm processing 7000 request per day right now and I'm pretty sure of my developments
The old endpoint (node/share/user/@) it's working even if you say no. The bandwidth with that call is just 2.2KB, it's lot less than the current call which is +300KB, and in case the first call fails it's just 2.2KB to add to the total banwidth, it's totally contemptible
So, with your library it's about 2Gb per day, with my forked it's 2.1GB in the worst case and 15Mb in the best case per day. And that just with the getUser call... Suppose a proxy that is 10$/GB....
Think about it! ;P
You closed previously request without any comment, don't know if something is wrong. I've respected all current names and functionalities. I've extended getUserFeed creating getUserFeedByUserId in order to have a function that gets only video feed without user call, in case of need. I've made a first call to https://www.tiktok.com/node/share/user/@{$username} in getUser function and maintain the call https://www.tiktok.com/@{$username} as fallback if the first fail in order to reduce data consuption (proxy price reduction) Tell me if I need to make changes or something, please.