Some accounts verification box to spam

[skifli]

I can add one account successfully. However, as soon as I try to add another account, upon clicking sign in, the Verify account box is spammed infinitely, preventing me from logging in. I've tried using a VPN, and also having the account logged in on my browser, but none of those helped. You can tell the fact that the box is spammed infinitely because of the shadow that builds up from the countless amount of boxes, akin to when a program creates a bunch of windows on top of each other on Windows.

[skifli]

I would like to add that I tried logging in so many times that my IP was actually flagged and I had to contact support to get it unblocked.

[vladimiry]

I've never faced proton verification box as a user, nor did I explore the related code, so can't comment on this at the moment.

When using multiple accounts, it might make sense to use different IP addresses for each account. The app allows specifying proxy address on the per-account basis (you can find it in the collapsed by default "Advance Options" block located on the account edit form).

[skifli]

Thanks for the quick reply. I'm not sure if you understood, but if you didn't, by verification box I meant a captcha box.

[vladimiry]

Thanks for the clarification. There were issues before with a captcha box functioning in the app. When I fixed it last time, I tested it as working, but they/proton must be changing related things again. So some debugging will be required to happen in order to understand what causes the issue.

[skifli]

Yeah, I had a look at the issues on the repository and saw quite a few related to this problem, but none of them fixed it for me. Is there anything, such as logs, that you need from me?

[vladimiry]

I don't think app logs will be helpful here, as it looks like something happening at the proton's side of code/logic, like cycling iframe boxes creation.

[vladimiry]

The first step I'd do is updating the packaged in to the app https://github.com/ProtonMail/WebClients version and see if it helps, as technically, the recent app release might be including a potentially unstable WebClients version. They deploy updates quite often, so in-browser version is always fresh vs the static version the app comes with. So I might ask you to test a new work-in-progress app build when it's ready (or you build it yourself from the updated code, if you prefer this way). And then if the issue remains, debugging would be required.

[skifli]

I'd prefer to run a build you compile since I've never worked with Angular before. Also, the problem doesn't appear with one account, which also was the first account I added. Idk if this is linked in any way. For that account the verification box appears correctly and I can complete it, meaning I login successfully.

[vladimiry]

Also, the problem doesn't appear with one account, which also was the first account I added. Idk if this is linked in any way. For that account the verification box appears correctly and I can complete it, meaning I login successfully.

I didn't get it initially. This sounds weird, as the accounts in the app are isolated. The wild guess is that they run addition verification-related logic if multiple accounts get accessed from the same IP in the same time window.

[vladimiry]

They trigger verification modal displaying based on the XHR's response error code. That createModal function has a second argument - modal ID, which is not currently specified in their code. I guess the simplest thing to try will be specifying this ID value (just some static value to force single modal logic), so only one verification modal will be displayed at the same time.

[ask2018]

I can confirm the captcha problem on some accounts. I have 4 accounts and on 2 of them I noticed this with PC restart. I need to reenter login details and solve captcha on these 2 on each ElectronMail restart. Also the "lock" icon stays closed and not open like on the other 2 accounts where is not this problem. Except this everything seems to be working fine.

[vladimiry]

@ask2018 all accounts mapped to a different IP addresses? Per-account proxy address can be specified via the "Proxy rules" field placed on the "Advanced Options" block of the account edit form.

[vladimiry]

Also the "lock" icon stays closed and not open like on the other 2 accounts where is not this problem.

Sounds like an issue. Is there anything suspicious in the log file?

[ask2018]

No it is not mapped do different IP addresses. It is just work/spam/friends/etc accounts, so there was no reason to use different proxies for that. I'm only using there different login delay per each account. But it was working just fine for years until now.

The issue is actually bigger than just "lock" icon. There is as well no notification for new email in tray icon. One if the accounts with this problem is the one I'm using for Github, so I just noticed it. I have log level "error" and nothing in the log folder. I'll try with bigger level and I'll post here if I notice something.

[vladimiry]

The issue is actually bigger than just "lock" icon.

The persistent "lock" icon indicates that the custom logic the app integrates into the proton's web client, with help of @electron's preload scripts, didn't get fully initialized/integrated for so far unknown reason. So it's understandable that the issue is bigger than just persistent "lock" icon.

Ideally I'm able to reproduce the issue at my side, by it's not the case so far.

[ask2018]

Well it is odd. I've tried to change log level to "verbose" and restarted ElectronMail. The log folder is still empty. I need to enable this somewhere else as well? Also One of those problematic accounts now wanted only captcha and after captcha it log in with open "lock" icon. The second one asks as well for login info and after I input that, it wants captcha and mailbox password. Then I'm in, but "lock" icon stays locked. I have persistent session enabled on all of those accounts.

[ask2018]

I've tried to logout from that account manually and then login back. Again captcha and locked icon, but also this error.

"Invocation timeout of calling "notification" method on "electron-mail:webview-api:primary" channel with 25000ms timeout"

[vladimiry]

I need to enable this somewhere else as well?

Nope, it should work, and works well at my side. If it gets working, the possible thing to do, is to run the same action on both working and problematic accounts, and then comparing related log lines.

"Invocation timeout of calling "notification" method on "electron-mail:webview-api:primary" channel with 25000ms timeout"

Some users face this issue. This basically means that custom app logic didn't get initialized (and so "lock" icon stays locked, etc). It's a known one and the cause didn't get investigated yet nor even the scope got narrowed down. There is a related open issue.

[ask2018]

The missing log file is my fault. I'm just blind. There was some old log folder and I've been looking for it there. Sorry.

Also One of those problematic accounts now wanted only captcha and after captcha it log in with open "lock" icon.

This account seems to be fixed now. But I have no idea why. The second one I got still the problem. And this is inside the log file if I try logout/login with error level. With working account there is nothing in the log. Log file attached. log.log

[skifli]

@vladimiry I've found the reason for the bug. When setting log level to Verbose, this line is spammed in the log file for every new box that appears in ElectronMail.

[2023-07-12 16:52:37.739] [warn]  src\electron-main\web-request\index.ts {
  resourceType: 'xhr',
  error: 'net::ERR_FAILED',
  url: 'https://mail-api.proton.me/core/v4/verification/ownership-email/<wiped-out>'
}

Here is the whole log. Also on line 285 something reports a possible memory leak, which is exactly what is happening. log.log

[vladimiry]

So like I mentioned before, proton triggers the verification box displaying based on the XHR's response error code. And they don't check if the box already there and so if for some reason XHR requests with specific error status gets cycled, the verification box spamming takes place. The change I'm going to enable and prepare test build, was described before. What causes cycled XHR's errors remains unclear, though, and the good idea is to fix the original issue vs applying half-measure.

Also on line 285 something reports a possible memory leak, which is exactly what is happening.

The 285 line is unrelated to this issue, and the cause is clear, and it's not an issue at all, but an opt-out @electron's warning.

[vladimiry]

@skifli, here is a fresh build to test. Assembled from the wip branch. Comes with up to date https://github.com/ProtonMail/WebClients clients and static ID set for HumanVerificationModal (as described in https://github.com/vladimiry/ElectronMail/issues/621#issuecomment-1627389416).

What causes cycled /core/v4/verification/ownership-email/<wiped-out>-like XHR calls remains unclear. Please keep the extended app logs level enabled, so we see if these uncontrolled cycled requests are still there. There is a chance that updated WebClients stack fixes the issue.

[skifli]

@skifli, here is a fresh build to test. Assembled from the wip branch. Comes with up to date https://github.com/ProtonMail/WebClients clients and static ID set for HumanVerificationModal (as described in https://github.com/vladimiry/ElectronMail/issues/621#issuecomment-1627389416).

What causes cycled /core/v4/verification/ownership-email/<wiped-out>-like XHR calls remains unclear. Please keep the extended app logs level enabled, so we see if these uncontrolled cycled requests are still there. There is a chance that updated WebClients stack fixes the issue.

Thanks, wont be home for quite a few hours but will run it as soon as possible (in abt 5-6 hours).

[skifli]

@vladimiry It works perfectly now - I logged in straight away. Thanks a lot.

[vladimiry]

@skifli the verification box, was it correctly displayed? Or it got skipped for some reason? If the box was there, and it didn't jump into the spamming mode, then the issue seems to be fixed.

Also, are there new /core/v4/verification/ownership-email/<wiped-out> request relater errors in the log?

[skifli]

@skifli the verification box, was it correctly displayed? Or it got skipped for some reason? If the box was there, and it didn't jump into the spamming mode, then the issue seems to be fixed.

Also, are there new /core/v4/verification/ownership-email/<wiped-out> request relater errors in the log?

The box didn't appear at all. However, that line is spammed a lot in the log.

log.log

[vladimiry]

Ok, closing for now. @ask2018, issue you posted is not related to this one, and if I remember right, it's already placed somewhere in https://github.com/vladimiry/ElectronMail/issues.

@skifli, let me know if something weir happens again with this verification box thing. Also let me know if you get the box displayed or spammed at some point as I just want to be sure I didn't cut out its displaying completely. Although I believe you would not get further without its logic fulfilling which can't be fulfilled without displaying, if the verification done right. So it looks like verification box didn't get triggered by proton which makes me think that they might trigger this box for the "outdated" web clients versions (sort of bad news for the app/project if so). If the guess about "outdated" clients detection is right, you should get verification box displayed at some point if you stick to the same app build.

However, that line is spammed a lot in the log.

Not really. There are no /core/v4/verification/ownership-email/ "failed" requests among today's log lines. So, like I wrote above, the verification box didn't get triggered by proton since there were no /core/v4/verification/ownership-email/ "failed" requests with this build and so you didn't see the box. I'd like you to see it, though, so the proper test gets conducted.

[ask2018]

@vladimiry Sorry for slow responses. I still have that issue with no tray notifications on account associated with Github, so I need to check manually. Also I cannot test the build,. as there is no Win78 branch. But as I see you said this issue was not related to the issue Ive posted anyway.

[ask2018]

@vladimiry I'm not sure if I should open new ticked, so I'll just post it here for now. I've been trying to do few more restarts of the ElectronMail and noticed as well, there is now some file created in my C:\Users\USERNAME\AppData\Local\Temp with dynamic filename (it was not happening before). It triggers my security software as new process trying for network access. After few tries playing with that I was able to unlock the remaining account correctly. I'm including the temp node file here in zip archive. f0441d2e-b000-449c-8dfb-1f7e8fae6ee7.tmp.zip

[skifli]

@vladimiry I'm not sure if I should open new ticked, so I'll just post it here for now. I've been trying to do few more restarts of the ElectronMail and noticed as well, there is now some file created in my C:\Users\USERNAME\AppData\Local\Temp with dynamic filename (it was not happening before). It triggers my security software as new process trying for network access. After few tries playing with that I was able to unlock the remaining account correctly. I'm including the temp node file here in zip archive. f0441d2e-b000-449c-8dfb-1f7e8fae6ee7.tmp.zip

Yeah please create a different issue.