Closed mattw-mega closed 3 years ago
megasdk_PR FAILED (3637) :-1:
megasdk-winx64-PRs FAILED (1120) :-1:
megasdk-crossAndroid-PRs FAILED (1295) :-1:
megasdk-winx64-PRs SUCCEDED (1121) :+1:
megasdk-crossAndroid-PRs SUCCEDED (1296) :+1:
megasdk_PR SUCCEDED (3638) :+1:
megasdk_PR FAILED (3643) :-1:
megasdk-winx64-PRs SUCCEDED (1126) :+1:
megasdk-crossAndroid-PRs SUCCEDED (1301) :+1:
About logout, that is an interesting thought, and something I wondered about too. However, it's possible that the folder link might be in use in multiple places (eg. same app running on main phone and backup phone, both logged into the same link - or personal phone and work phone), and we wouldn't want logging out of one to cause the other to fail, I think. Probably in this scenario, cancelling the link from the same place it was created (typically from the webclient) would be the way to go.
As for the logout, I don't understand the use case you mention. When the SDK instance is logged into a folder link, it's not logged into the owner's account. Therefore, a logout will never invalidate the folder link itself, it cannot, but it can forget about the "session" that is saved (the public handle and the auth token). In other words, when the SDK is logged in into an account, a logout invalidates the session. I'm suggesting whether the SDK logged into a folder link should invalidate (meaning to delete, in this case) the "session" upon logout (despite both public handle and auth token remain valid, but for analogy with a user's session).
megasdk_PR FAILED (3649) :-1:
megasdk-crossAndroid-PRs SUCCEDED (1307) :+1:
megasdk-winx64-PRs FAILED (1132) :-1:
Session resume is also enabled for read-only folder links. Resuming means we can load the locally cached node database instead of re-requesting from the server, just like a normal account Of course for folder links it's not really using a session id, but follows the pattern of calling dumpsession() and re-login with the output of that.