Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AUTH_KEY_DUPLICATED #16

Open
Keyrxng opened this issue Oct 26, 2024 · 2 comments
Open

AUTH_KEY_DUPLICATED #16

Keyrxng opened this issue Oct 26, 2024 · 2 comments

Comments

@Keyrxng
Copy link
Member

Keyrxng commented Oct 26, 2024

Our session can be taken out because of this error (failed workflow)

An exception to this is the AUTH_KEY_DUPLICATED error, which is only emitted if any of the non-media DC detects that an authorized session is sending requests in parallel from two separate TCP connections, from the same or different IP addresses.
Note that parallel connections are still allowed and actually recommended for media DCs.
Also note that by session we mean a logged-in session identified by an authorization constructor, fetchable using account.getAuthorizations, not an MTProto session.

Critically:

If the client receives an AUTH_KEY_DUPLICATED error, the session was already invalidated by the server and the user must generate a new auth key and login again.

So based on our current login flow this requires manual handling where a team member who has the access to do it:

  1. logs in and removes all sessions from the TG client
  2. runs yarn sms-auth.
  3. that's it. I'll add handling in an open PR to remove any existing session strings from the DB when pushing a new one.

Automating this is really difficult because it's 2FA with a TG client with a code. Not certain how we'd implement this.

@Keyrxng
Copy link
Member Author

Keyrxng commented Oct 28, 2024

I opened this two days ago and that is when I reset my session because of this error. So two days without using the connection and I've just received the error again when running the MTProtoAPI.

  1. This may be resolved if we keep our connection warm.
  2. Basically the data centers switch and sessions are tied to a particular one from what I gather. I'm unsure rn if we are being 'logged out for inactivity' or if the data centers are rotating and we need to handle that switch (there is quite a bit of info in the docs regarding this area of things, something along the lines of keeping keys for each but I wasn't sure that was applicable to our use-case)

Ideally it's one as it's a simple solve but requires more info

@0x4007
Copy link
Member

0x4007 commented Nov 1, 2024

It doesn't make sense to me that the client is being logged out this frequently. I use Telegram on my devices and remain logged in, so their system is designed to allow for persistent login.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants