bernd-wechner
commented
3 years ago 400 of course is malformed request. I just checked on my instance and it's working fine, so it;s not a case of an obvious API change (the API is a sluggishly moving target of course). Which suggests there's a bug in the script (a broken premise). It would be great to nail what it is.
I an instrument it up with a debug command line option which dumps the HTTP request and response, which isn't a bad idea for on-the-fly drill down into such errors.
In the mean time, if you're comfortable enough with Python you can take a look here:
which is what's giving you the 400 error, and what I'd do is log the the full request and response just after this:
and we can compare. If you do that and post it here, make sure to anonymise the Token in the request as a precaution (they don't seem to expire, though I should hope they invalidate when you logout, haven't tested that yet, but this Token technically provides access to your data while you're logged in).
You'll see that Token where the request is built:
Then to get a reference what I'd do is surf to degoo.com in a browser, open the debug window and the network page there (Firefox and Chrome are very similar there). Clear the network history if needed, then log in to degoo. A trace appears and among the long list is a getFileChildren3 request. I save that in JSON format and format it nicely and then compare with mine.
As this is a black box reverse engineering of their API this is the option we have, and I'm certainly happy to learn from your experience (i.e. improve our understanding of their API).
Another thing to try is if degoo_put and degoo_get exhibit the same problem, or if they work. I just put a pile, then get it again for such a test.
On possible source of this is the devices conundrum. The top level folders on a degoo filesystem as it's presented on their web interface is called a device. These cannot be created. You have what you have. So you have to surf into a device (degoo_cd) before you can put a file.
There's also a slim possibility that they build their request a little differently based on the user, their license, or whatever, and I'd be really curious to get a getFileChildren3 request that you've logged to learn if that's the case. I have only one account and hence only that one view on their API of course.
MDKPredator
growtopiajaw
Running on my Android phone :)
Hi there, I really appreciate such project exists. I really regret using Degoo and it is getting more and more ridiculous every day.
I've encountered an error where all the command doesn't work except degoo_login, degoo_pwd and degoo_user. I'm using Python 3.9.1 on Ubuntu 20.10 and Debian 10 just for reference. Whenever a command is executed it always returns with an error
getFileChildren3 failed with: <Response [400]>. All python module requirements are installed. Adding the verbose flag doesn't return any extra debug info except for the error above. Below is an image that I have attached.