Closed vincentneo closed 1 year ago
To start off, apologies for the number of issues generated by me during this short period of time.
Thank you for creation of the issues. You reported 2 bugs, which were fixed and are very unlikely to be reported by someone else, because they affected only watchOS
and HTTP-only proxies.
Any ideas on why thats the case? Did I missing something that I should implement? Or impossible to know due to lack of logs?
Does the user has 2-factor authentication? Did the user enter the password on the device while logging in? Is the user from America and was registered more than 7 years ago?
Thank you for creation of the issues
glad you didn’t find me a nuisance 😁, and thanks for replying to this issue.
Does the user has 2-factor authentication? Did the user enter the password on the device while logging in?
I assume you mean the Two Step verification? I highly doubt that it’s because of this, but then it’s a question that I didn’t ask the user. I assumed that wasn’t the issue as the screenshot given to me suggests it isn’t in the "incomplete login attempts" column since the screenshot that the user sent has the "accept on this device" section with the secret chats toggle, etc. which based on personal observation, when trying out if I didn’t enter the password yet.
Anyways, the watch app does work with Two Step Verification’s password field.
user from America and was registered more than 7 years ago
Also unsure about this, though the email’s domain (which has a country code) suggests it’s not from US.
To start off, apologies for the number of issues generated by me during this short period of time.
Now on the topic, after almost all users could do things as per normal after #2488 was resolved, there's one user, that appears to be stuck in
authorizationStateWaitOtherDeviceConfirmation
, even when the QR code is already scanned using the official app, and the device is already appearing in the "active sessions" list of the official app.It's definitely not on "incomplete login attempts" either since the screenshot that the user sent has the "accept on this device" section with the secret chats toggle, etc. At the same time however, the screenshot didn't have any IP address and location, but I think it can be reasonably assumed that was censored away rather than really not being there.
Advised to terminate session in app and rescan QR again, but that did not solve the problem. User claims to have reinstalled the app many times too.
Unlikely to be a network issue I guess, since user already has a valid QR code, one that the official app does acknowledges.
I have no access to logs in this case, user is running client based on TDLib 1.8.12.
Any ideas on why thats the case? Did I missing something that I should implement? Or impossible to know due to lack of logs?