ssovit / TikTok-API-PHP

Unofficial TikTok API for PHP. Join our Discord server
https://discord.gg/rSQd2QAXA8
MIT License
145 stars 42 forks source link

Release 1.3.1 #23

Closed sesanzb closed 3 years ago

sesanzb commented 3 years ago

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.

ssovit commented 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

Patch Links:

— 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

sesanzb commented 3 years ago

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

ssovit commented 3 years ago

It doesn't work and give this on my end.. image

sesanzb commented 3 years ago

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

ssovit commented 3 years ago

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...

sesanzb commented 3 years ago

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:

  1. want to get userA feed
  2. getUser call returns the info ok and cookie is saved next getUserFeed call uses cookie returns info ok and cookie is saved
  3. want to get userB feed
  4. getUser call uses cookie generated for userA and returns false (because of captcha) and cookie is saved
  5. want to get userC likes
  6. getUser call uses cookie generated for userB and returns false (because is saved previously with captcha need) and cookie is saved again
  7. Every other call returns false until cookie file is removed

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

sesanzb commented 3 years ago

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?

ssovit commented 3 years ago

Yes.. it doesn't work and have over-head requests which don't work with existing sessions...

sesanzb commented 3 years ago

OK! No worries, forgive me if I have disturbed you. But...

  1. The old endpoint is working, it's a fact.
  2. The way your CURL method works, makes the use of a proxy ineffective because the same cookie is always sent, and if it is an incorrect cookie or has the captcha verification setted, the following calls will always fail regardless of the IP used by the proxy.

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

ssovit commented 3 years ago

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.

sesanzb commented 3 years ago

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