Visionary Users unable to Access ProtonDrive

[BelArvardan]

When I attempt to use ProtonDrive I receive the following message "Upgrade to access Proton Drive Proton Drive is currently in early access and only available to users with a paid plan."

Lifetime plans should be considered paid accounts. This has been an ongoing issue. Though several days ago it worked fine and I thought it finally got fixed. However today I tried to check the ProtonDrive tab and was blocked again.

Any help would be appreciated.

[vladimiry]

There was a long-standing issue before, but got fixed somewhere at the Proton side in mid-April this year. So apparently the issue is back on their backend with the v5 stack upgrade.

The interesting thing is that it works for me on the proton.me API entry point, but not on the Tor API entry point.

[BelArvardan]

That explains why it was working breifly and now isnt't working again.

Thanks for the info

[arch-btw]

I think that maybe 2FA and/or Two-Password mode play a role in this too. Because even right after the fix in https://github.com/vladimiry/ElectronMail/issues/377 it still wasn't working for me. I think that might be another reason why it won't work (in addition to the original access-scope issue).

[vladimiry]

The fun fact is that it works for me right now on proton.me API entry point, but it doesn't if I switch to the Tor API entry point, on the same account.

Unfortunately, proton team is not helpful when it comes to Drive service. I've tried to reach them before several times without success.

[BelArvardan]

Thanks for the help and comments y'all.

when I have some time I will try out a few different scenarios and I see if anything works.

[vladimiry]

@BelArvardan. A side question. Being a visionary user, why would you use the app like this vs Bridge thing?

However today I tried to check the ProtonDrive tab and was blocked again.

Did you do re-login into the account between working and nonworking access state (same user session vs new one)?

The fun fact is that it works for me right now on proton.me API entry point, but it doesn't if I switch to the Tor API entry point, on the same account.

Here is another fun observation which I've discovered trying to narrow down the issue scope.

On proton.me API entry point with a very old session it does work for me right now. The session is kept live for more than 6 months with help of the persistent session feature (originally introduced in v4.2.0 and got enabled by default for a newly added accounts since v4.10.2). And the weird thing is that it doesn't work on the same account on both Tor + proton.me API entry points, but with a fresh session.

I guess in mid-April Proton added the needed "access scope" to the existing/open account sessions + enabled "live" scope adding for new sessions, and so it started working. But recently Proton presumably stopped adding that "scope" to a new account sessions (this assumption is applicable to non-SSO sessions only, like used in the app, but not in the browser), and so now we face the same issue as was in place before mid-April.

Kindly pinging @bartbutler in a hope to at least shed some light on the issue.

[bartbutler]

Hmmm...not entirely sure what is going on here--there have certainly been some modifications to sessions to support drive being available to all users but I didn't think it was that inconsistent. What x-pm-appversion header do you send for authentication, and do you then use that session for everything or do you "fork" child sessions like the webapp does?

[vladimiry]

What x-pm-appversion header do you send for authentication

The app loads the account with the mail client page, which renders the login form if needed (MinimalLoginContainer). So the header value used during the login process is x-pm-appversion: web-mail@5.0.1.3 (API address is prefixed with mail-api subdomain for the "mail" app). The sessions list in the account settings shows ProtonMail for web session title.

So it's clear that signing in via browser occurs differently than in the app:

• Using SSO scenario vs non-SSO in the app (old way).
• Via "account" app vs "mail" app in the app, so x-pm-appversion: web-account@... is used in the browser and the sessions list in the account settings shows Proton Account for web vs ProtonMail for web.

do you then use that session for everything or do you "fork" child sessions like the webapp does?

The same session is used for all proton apps, and it works well, except for Drive service.

[bartbutler]

If it's easy, I'd try seeing if web-account doesn't fix your drive problem. In the SSO case the apps inherit a subset of the parent account session's scopes and as mail currently has no use for drive routes my guess is that it's not granted drive scopes as a result.

[vladimiry]

I'd try seeing if web-account doesn't fix your drive problem

Can confirm that applying the x-pm-appversion: web-account@...-like header to all /auth/*-like API requests makes the Drive service work even on a free accounts and I see the Proton Account for web session title in the settings (even if the API subdomain is mail-api, so setting the header is a sufficient measure for now). So I'm forcing the x-pm-appversion: web-account@... header on the app for now for the /auth/* API requests regardless of the proton app type being used/loaded. I understand that redirecting a user to a real "account app" would be a better solution (as no need to hardcore anything in the app's code and no need to track the possible account app auth flow changes), but just setting the header is an easier option for me at the moment.

mail currently has no use for drive routes

Do I get it right that when the mail app starts using Drive service for attachment purposes (or other needs), the "drive access scope" will be added to the ProtonMail for web session and so this headers hack won't be needed anymore?

[vladimiry]

Closing as resolved. Going to publish a new release soon. Thanks @bartbutler.

[arch-btw]

Thank you @vladimiry can confirm that it works in 5.0.1 !

[BelArvardan]

Thank you!