Possible login issue about degoo

[bernd-wechner]

Could be. I can't login either, just tried. Need to find time or someone who has time, to do a quick snoop watching teh network traffic on a web login. Will do so when I get time.

[bernd-wechner]

Mind you, it's more likely they just changed the login URL not the API. Happened once before and is a trivial fix.

[prichiyak]

How to fix Login failed.

[bernd-wechner]

Yep, I've tried to fix but so far am stuck. I have a full trace of what the web browser sends when logging in. I am trying to duplicate it with Python but it doesn't work. It used to, and I have looked closely at all the HTTP headers and the data and no luck. I have parked it for now as replicating with Python is a little tricky as I can't see (on the wire) what teh Python libraries are sending. Am looking at options to sniff that. Tricky as it's HTTPS.

I haven't found any on-line request mirror (a service that might mirror back the request it receives for diagnosis), and I've tried Fiddler but without success yet and am low on time for it at present. Fiddler may be able to help. The thing is to compare what the replicate what the web browser sends perfectly. If the web browser can log in, anyone pretending to be that web browser in an indistinguishable manner can too and that is the goal of course.

What puzzles me is what Degoo changed and why. Suspecting some added layer of security. But I haven't found out what it is yet. Contributions in research always welcome in this space, not least to share and spread skills in this zone.

[IAMSDR]

A temporary solution 😊. we can use register url for login.

off-topic :
Sir , I made Telegram Bot using this API.
try once if you have free time
https://t.me/DegooUploaderBot
Thank u ❤️

[bernd-wechner]

Why thank you. I'll give it a try some time. And drop a line back then. A bit snowed under this week alas for work on this, but if anyone else wants to try this workaround and report back as well, all welcome.

[bernd-wechner]

This was fixed in:

89e62e8

Seems to be working again.

[DLBerger]

I'm still seeing the following with degoo_login:

Login failed with: 429: Too Many Requests
Login failed.

[bernd-wechner]

Did you pull the latest version?  Just checking. Sent on the go with Vodafone-------- Original Message --------Subject: Re: [bernd-wechner/Degoo] Possible login issue (#25)From: DLBerger To: bernd-wechner/Degoo CC: Bernd Wechner ,State change I'm still seeing the following with degoo_login: Login failed with: 429: Too Many Requests Login failed. —You are receiving this because you modified the open/close state.Reply to this email directly, view it on GitHub, or unsubscribe.

[DLBerger]

Yes, but still seeing it. I can login to degoo.com without issue. Using Python 3.9.2 inside of WLE using WSL2 on Windows 10.

[bernd-wechner]

Not sure I understand.

WSL2 is Windows Subsystem for Linux right?
WLE? Looks after some searching online to be Pengwin Enterprise whatever that is and no idea how it relates to the TLA WLE?

Are you saying that:

1. In a Linux environment degoo_login works for you?
2. In the Windows environment it doesn't?

[DLBerger]

I've always used your code on WSL/WSL2 on Windows 10 and it has always worked (with issues) until a few months ago.
Using your code directly and my modified code always fails executing ./degoo_login with:

Login failed with: 429: Too Many Requests
Login failed.

[bernd-wechner]

Interesting because I was getting the same a while back. I haven't used it in a while as it's a backburner project until I get it slick enough to serve as a useful backup tool for my servers (which is why I started on it, to exploit 10TB of cloud storage for backups). It worked fine (I mean it is a WIP (work in progress) and lacks polish in many areas, hastily cobbled together , but it was logging in fine. Then out of the blue I saw these Too Many Requests errors too and tried hard to fix them (looking briefly into how I could use fiddler to see what the Python request was byte for byte compared with Firefoxes login request, byte for byte, then @squidharth submitted a fix, I tried it and it was all good again ...

To wit a puzzle you still see it. I would double check the local code that it is this:

Degoo/degoo/API.py

Line 281 in 1077f89

def login(self, username=None, password=None):

As that's the change that was made and login seems to work fine again. At least from here.

BUT there is a chance (as I did insufficient testing) that it's a red herring, that Too Many Requests does not even relate to this fix, so much as some other issue that is account specific, source IP specific or something else as it has the ring of a rejection because of well "too many requests" ...

If only Degoo would provide some support in diagnosing it, but they aren't the best at that pretty closed shop in that space.

[bernd-wechner]

Turns out I just did a test my end again and luckily I'm seeing a 429 again ... well, not lucky in that it's again, but lucky in that I could drill into a bit. I hence pushed a new build version and you can try degoo_login -vvv (three vvv I tend to use for deep drill down debugging) and it will spit out something like:

Login failed with: 429: Too Many Requests
Request:
	URL: https://rest-api.degoo.com/login
	method: POST
	headers:
		User-Agent: Degoo-client/0.3
		Accept: */*
		Accept-Language: en-US,en;q=0.5
		Accept-Encoding: gzip, deflate
		Content-Type: application/json
		Origin: https://app.degoo.com
		Connection: keep-alive
		Content-Length: 61
	body:
		{"Username":"myusername","Password":"mypassword"}
Response:
	headers:
		Date: Sun, 25 Jul 2021 06:21:02 GMT
		Content-Type: text/plain;charset=UTF-8
		Content-Length: 0
		Connection: keep-alive
		Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
		Vary: Accept-Encoding
		Server: cloudflare
		CF-RAY: 67434927ec00fea5-MEL
	content:
		b''

Which is telling as it implicates cloudflare which is weird as we're not requesting from them. That takes me here:

https://themebeez.com/blog/fix-err-too-many-redirects-cloudflare-loop/

[bernd-wechner]

And so, I did a quick experiment with headers, removed the keep-alive request and voila my 429 went away. Pushed that code and would be good for you to try it. Fingers crossed that solves it. Not sure what's going on as the browser sends a a keep-alive request and I was mimicing it. And it often worked clearly. Seems we have a case where it doesn't.

And here is why:

https://www.imperva.com/learn/performance/http-keep-alive/

Can't see what's to cause a cloudflare retry loop in that. Shrug. Hypothesis: degoo make multiple cloudflare requests (we don't) when the keep-alive is set exceeding some rate limit. Puzzle: why the web browser does not encounter a 429.

[DLBerger]

Now I'm getting the following error with ./degoo_login:

[dberger@DavidPC degoo]$ ./degoo_login
Traceback (most recent call last):
File "/home/dberger/degoo/./degoo_login", line 292, in
sys.exit(main())
File "/home/dberger/degoo/./degoo_login", line 233, in main
success = degoo.login(args.username, args.password, args.verbose)
TypeError: login() takes from 0 to 2 positional arguments but 3 were given
degoo_login: login() takes from 0 to 2 positional arguments but 3 were given
for help use --help

Very strange. You're also creating a 'd' command that is not in your .gitignore.

[bernd-wechner]

Should be fixed now. Slight slip up as I only use it with the -f option to save typing so missed it in tests.

[bernd-wechner]

Oh and d is just an experiment. So I can run d login rather than degoo_login, in short another step toward: #13

[DLBerger]

Looking good. Thank you.