TikTok-Live-Connector: Error: Request failed with status code 500
It was working until earlier to, when I started getting the following error message for everyone I try to connect to::
Error: Request failed with status code 500
I tried doing it on the example site as well and still get that message.
https://tiktok-chat-reader.zerody.one/
Any chance of finding a work around for this? I’ve been running it locally so if theres a way to do only on localhost, that would be amazing as well.
Thanks for your hard work on this project. It really has been a dream come true to be able to see who sent gifts and who tapped. I wish tiktok had a way to do this instead of resorting to third party plugin, but since they dont, I’ve been relying on your project to track the gifters and tappers.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 15 (3 by maintainers)
Issue fixed, an internal microservice (responsible for the functioning of the sign server) had to be restarted. One of the processes behind the sign server crashed and did not restart properly.
Someone asked why the code for the sign server is not public:
The reason we don’t just give people the ability to run the sign server is that it generates tokens to TikTok’s website to make requests (like making the request to get you the websocket URL). The nature of being able to do this means people can choose to spam TikTok with a massive number of requests and not get any sort of captchas. If they knew our method, they could scrape any part of TikTok, not just the LIVE side. TikTok used to block this library because we gave out tokens like that. In the interest of this library running forever, we don’t give out tokens anymore, only the websocket URL. This means we need the sign API to do all the token stuff behind the scenes so that there are no issues with us getting blocked. Obviously, we can’t give out the code to do this, or TikTok will be forced to block it.
Since adopting this method, TikTok have not attempted to block our library for over 6 months now. At one point they used to block it twice a week. It was absurd. It is frustrating in cases like this where I am literally sleeping and not there to fix things that go wrong, but it is much more preferable to no service at all.
Others would have had access to restart it when I am asleep, but we recently switched the host running the microservice, and I had not yet shared the details with the other library developers.
Fix in-bound, different reason… Being Ddosed.
Thank you for fixing this, and getting it working again! This really is an awesome project, and I’m so glad you and the team have started and continue to maintain it. I was scared in the beginning thinking I would not be able to find a work around to this issue.