Repository navigation
[BUG] HTTP 402 for Mega #150
Description
Please confirm the following
- I confirm my description is clear and polite, that I have provided the necessary diagnostic information, and that this is reproducible on the latest version.
- I confirm I have checked the relevant documentation and existing issues / discussions, and this report is not a duplicate.
- I confirm this is an issue with the Worker project, not caused by network or user error, and not an issue specific to the Go version.
- I confirm I have read the open-source license / disclaimers / usage policy, and understand that I bear all risks of use.
Version (required)
No response
Platform (required)
Cloudflare Workers
DB_FORMAT (required)
map (single JSON blob)
DB_DRIVER (required)
auto
Storage Driver (required)
Mega
Bug Description (required)
Mega API HTTP error: 402
Error Information (required)
This thread may be helpful:
qgustavor/mega#239 (comment)
Relevant Configuration (required)
Irrelavent
Reproduction Link (optional)
No response
Activity
PIKACHUIM commentedon Nov 2, 2026
Please try #166
Wait your feedback
BrandonStudio commentedon Nov 3, 2026
Mega authentication failed: -9
No relavent log captured
fix(mega): implement the real login protocol and node decryption (fixes
PIKACHUIM commentedon Nov 9, 2026
Please retry #166
I tested on cf worker, it works but a little bit slow :(
PIKACHUIM commentedon Nov 9, 2026
"Mega authentication failed: -9" means your account has been blocked, and you may need to allow login or input 2FA Code
BrandonStudio commentedon Nov 10, 2026
OK now. But 503 sometimes.
Fundamentally, I doubt whether this is the right way. As these PoW things take a lot of CPU time on serverless worker, while the worker could have returned very early just dealing with API calls. So I wonder that is it possible to move the PoW computes elsewhere, for example, moving to a client browser? Could there be a mechanism supporting this?
BrandonStudio commentedon Nov 10, 2026
A comparison:
normal requests of this project take 2-5 CPU time, whereas the fs/list with Mega PoW takes 1837 CPU time
PIKACHUIM commentedon Nov 10, 2026
The 503 was caused by rate limiting due to Mega, and this issue has just been fixed.
POW is not suitable for frontend processing because the direct download scenario needs to be taken into account.
The recent push made the following changes:
PIKACHUIM commentedon Nov 10, 2026
However, since the first login always requires POW verification, and the CF free plan only supports 10ms of CPU time, there is a certain probability that 5xx errors will occur. But theoretically, once you have logged in successfully once, there is no need to repeatedly verify the POW.
BrandonStudio commentedon Nov 10, 2026
My Mega account was blocked just now... saying that unauthorized third party login detected
Now it's fine, 8ms for fs/list.
Since PoW only happens when first logging in, I'm wondering that could there be a protocol that the first time PoW should be done together with the front end and the client browser, later API calls could then process?
PIKACHUIM commentedon Nov 10, 2026
You can use the email link to reset your password, which will unlock your account.
However, because the Cloudflare IP is used by a very large number of users, it is quite "dirty," so encountering this situation is very common.
Computing POW on the frontend is a fairly large undertaking, and for a case where it only needs to be computed once, it's not really recommended to implement it.
But I'll consider whether to add the option of using api.oplist.org to generate credentials on the frontend and then fill them into the worker instance — this feature isn't available yet
The PR will be merged and this issue will be closed. If you have any further questions, please open a new issue.
BrandonStudio commentedon Nov 10, 2026
Could you talk a little bit more about this? How would this work?
BrandonStudio commentedon Nov 10, 2026
BTW, is this PoW feature implemented on the Go version?
fix(mega): handle API Hashcash challenges (OpenListTeam#166)
PIKACHUIM commentedon Nov 10, 2026
Yes, the Go version does implement POW verification for this cloud drive.
Regarding POW verification on the API site (api.oplist.org), its principle is the same as what you described — except it's implemented not on the worker's frontend but on the frontend of the credential request site. If possible, the data should not be sent to the backend and would be processed entirely on the frontend.