add 2fa support for mega

[bingoxo]

What is your current rclone version (output from rclone version)?

1.47.0

What problem are you are trying to solve?

logging in mega with 2fa

How do you think rclone should be changed to solve that?

use same implementation as Megasync : https://github.com/meganz/MEGAsync/blob/master/build/MEGAsync/MEGAsync/megasync.changes/
meganz/MEGAsync#233

[ncw]

This probably needs work doing in the upstream repository: https://github.com/t3rm1n4l/go-mega

Do you want to implement this?

[bingoxo]

@polmr @wizzard @javiserrano , can you guys help with this please ?

[pixel8383]

Any progress on this?

[ncw]

I'm looking for volunteers for this :-)

[alexanderadam]

Just to be sure: there's no upstream issue in go-mega, right? 🤔

The API also doesn't seem to support any token based authorization if I interpret this correctly (only user & password auth).

[tddschn]

other mega cli clients don't support 2fa either iirc

[MrSAHaseeb]

There is Android App on Play Store called "Autosync for MEGA - MegaSync" that support Mega 2FA.

here is a link: https://play.google.com/store/apps/details?id=com.ttxapps.megasync&hl=en_IN
Contact app developer for help if you may - megasync@metactrl.com

[krazyjakee]

@alexanderadam there was no upstream issue so I created one.

[krazyjakee]

MegaCMD has an undocumented auth-code flag. This looks to be the only library I have found that has that functionality.

It looks like the go-mega library uses some rest api which I can't find any documentation for. So, if that REST api doesn't support 2fa, the only other solution I can see is that either they wrap megaCMD or rclone wraps megaCMD.

I have posted this information on the go-mega issue as well and will report back here with updates.

[AverageHelper]

The upstream repo doesn't seem to have seen updates in a while. It already has two PRs (#30 and #34) for adding 2FA. #34 seems to pass its CI checks, where the other does not. Should we perhaps integrate work from that?

[ncw]

Thanks, I'll take a look at that.

[EinarasGar]

Any updates on this issue?

[AverageHelper]

@EinarasGar go-mega#34 seems to be the closest relevant PR in the upstream repo. It's awaiting review, possibly from @ncw.

[mxr576]

Based on the progress and activity on the upstream repo, it seems to me it is time to (fork and) replace the Mega provider. Although, I'm not sure if anybody asked if sponsorship would help...

[mptpro]

Any update on 2FA for mega? I use rclone for quite a few cloud storages and all have 2FA, but I can't get Mega to work with rclone.

[D3an1el]

Any Progress?

[MickCue]

Is 2FA working yet for MEGA?

[Abejo]

Any Progress?

[avmaksimov]

I found 2fa realization in go-mega fork: t3rm1n4l/go-mega#34

Could be anyone change the integration module in rclone for that?

@ncw , I see you wrote many useful code for mega backend. Can you help us, please?!))

[nvllz]

I know asking such questions won't help much, but is there any progress? If not, where can we look for people to help us make rclone work with a 2FA secured mega-cloud? Is it really that hard to implement, or is there just not that much of a need for something like this out there?

[AverageHelper]

As far as I can tell, the code is written. It only needs to be merged upstream by a maintainer, then merged here.

[alexdibella]

Any chance for a maintainer to look at this? This could make rclone available to folks using mega

[ncw]

I merged the 2fa support for the mega library. Would someone like to make a PR to add support to it for rclone?

[nvllz]

I merged the 2fa support for the mega library. Would someone like to make a PR to add support to it for rclone?

@ncw Can't you try putting it here, please? You know how to do it if you have merged such a thing for the mega library. And as we can see, nobody else knows how to implement this thing. Or am I missing something and you just added it to rclone? Because I don't really understand what you were trying to say in your message.

[Masamune3210]

There are only so many hours in a day, they were merely asking if someone could take a crack at it if they got the chance. Trust me, knowing how to merge isn't the issue here lol

[ncw]

What needs to be done is call the MultiFactorLogin method instead of the Login method, but do this with the 2fa factor.

This needs to be supplied to rclone somehow. For other backends that do 2fa this only needs to be supplied during the initial oauth but rclone logs in every time it is called

rclone/backend/mega/mega.go

Line 216 in 56b582c

err := srv.Login(opt.User, opt.Pass)

To fix this we'd need to save the session to disk (in the config file) which would probably be a good idea anyway.

It is a fair amount of work to integrate 2FA. I'm willing to talk anyone through it who wants to do it, but I don't have time at the moment :-(

[thegabriele97]

What needs to be done is call the MultiFactorLogin method instead of the Login method, but do this with the 2fa factor.

This needs to be supplied to rclone somehow. For other backends that do 2fa this only needs to be supplied during the initial oauth but rclone logs in every time it is called

rclone/backend/mega/mega.go

Line 216 in 56b582c

err := srv.Login(opt.User, opt.Pass)

To fix this we'd need to save the session to disk (in the config file) which would probably be a good idea anyway.

It is a fair amount of work to integrate 2FA. I'm willing to talk anyone through it who wants to do it, but I don't have time at the moment :-(

Hi! I started working on this and I see you're a contributor of the go-mega library. As I can see, the library doesn't provide a way to store/restore a session. Which is the correct way to proceed in your opinion? Adding some functions in go-mega or doing something from the rclone side?

EDIT: I can contribute to go-mega too, to add a save/restore feature if this if the correct way to proceed

[ncw]

Hi! I started working on this and I see you're a contributor of the go-mega library.

I took over maintenance because the original author got bored of the project. Doesn't mean I know how it works though ;-)

As I can see, the library doesn't provide a way to store/restore a session. Which is the correct way to proceed in your opinion? Adding some functions in go-mega or doing something from the rclone side?

It depends on exactly what you mean by saving a session?

Are we talking about just saving a session ID? Or are we talking about saving the entire file system state?

The latter way is how mega expects rclone to operate and is one of the reasons rclone often fails with mega I think.

If just a session ID then rclone would normally save it in its config file. If it is more than that, then I'm not sure, we'll have to discuss!

EDIT: I can contribute to go-mega too, to add a save/restore feature if this if the correct way to proceed

Let's discuss the design here and then we can work out the way forward.

[thegabriele97]

It depends on exactly what you mean by saving a session?

Are we talking about just saving a session ID? Or are we talking about saving the entire file system state?

The latter way is how mega expects rclone to operate and is one of the reasons rclone often fails with mega I think.

If just a session ID then rclone would normally save it in its config file. If it is more than that, then I'm not sure, we'll have to discuss!

Well, I was thinking to just save the session id, I didn't know about the file system state. Can you explain better what you mean with "The latter way is how mega expects rclone to operate"?

More in general, at this point, would be great to save in the config file an entire serialization of the "mega object" that contains, among other things, the sid and the FS. With serialization i mean taking the content of everything, converting it in something like base64 and save it in the config file and then we can do a backward process to restore. In this way, theoretically, it is like the "Mega object" is never destroyed/recreated but continues to operate normally.

Moreover, I was thinking about the rclone config file and the fact that it is not thought to be modified externally the "configuration" procedure so I expect some problems here. Any suggestion on this?

I would suggest to start by only saving the session id for now. I don't know what else is needed to do correct api calls to mega.

[ncw]

Well, I was thinking to just save the session id, I didn't know about the file system state. Can you explain better what you mean with "The latter way is how mega expects rclone to operate"?

The other mega clients store the whole state of the filing system, so info about all the objects etc. So when you log in, you just get updates for stuff which has happened since you last checked in. This is much more efficient, but the go mega library doesn't work like that and neither does rclone.

More in general, at this point, would be great to save in the config file an entire serialization of the "mega object" that contains, among other things, the sid and the FS.

That is what I meant - a serialization of everything.

With serialization i mean taking the content of everything, converting it in something like base64 and save it in the config file and then we can do a backward process to restore. In this way, theoretically, it is like the "Mega object" is never destroyed/recreated but continues to operate normally.

We can store small strings in the config file, but file system dumps will have to go in the cache directory probably.

Moreover, I was thinking about the rclone config file and the fact that it is not thought to be modified externally the "configuration" procedure so I expect some problems here. Any suggestion on this?

Lots of the rclone backends store things in the config file. For example when google drive updates its token (which it does every hour) rclone stores it in the config file.

I would suggest to start by only saving the session id for now. I don't know what else is needed to do correct api calls to mega.

Storing the session ID for now sounds OK. What does that get us? Not having to MFA each time?

I'm not sure what modifications go-mega will need to save/restore the session ID though.

[thegabriele97]

Storing the session ID for now sounds OK. What does that get us? Not having to MFA each time?

Yes. Moreover, the MFA code change continuously so the one given as input by the user expires after a while.

I'm not sure what modifications go-mega will need to save/restore the session ID though.

I will perform some tests in the following days. I gave a fast read to the api request function and it uses the session id and a sequence number that is incremented ad each call.

[ncw]

Good luck! I don't know much about the mega protocol - the "documentation" is the Mega C++ SDK 😦

[tripplehelix]

Is there a way to do this yet?

[s0lst1ce]

I know the MegaCMD tool provided by mega can bypass the 2fa. I only ever gave it user+pass and it works flawlessly. So surely there's a way to authenticate solely through user+pass. Though I don't know how to do it.

[ThinkPud]

If of any assistance to Rclone, there are several third-party apps that support MEGA, with 2FA enabled. Air Explorer, Air Cluster, Air Live Drive, and MultCloud. Desktop apps, Air Explorer, Cluster and Live Drive, display a popup window, when the TOTP code is requested.

[hbednar]

@ThinkPud @s0lst1ce @tripplehelix
See #6868

[bingoxo]

@ThinkPud @s0lst1ce @tripplehelix See #6868

apparently that pull request isn't working unfortunately

[hangukhiphop]

dang still nothing? D=