"internal server error" on login

[Aloso]

I can't login! Please solve this issue or tell me how to fix it!

Steps to reproduce

1. Download Telegram Desktop and start it
2. Press "Start messaging"
3. Enter your phone number and press enter

Expected behaviour

Sends a authorization code to my phone

Actual behaviour

Displays "Internal server error." and underlines the phone number in red.

When I start Telegram with telegram-desktop -debug, the error message reads "API_ID_PUBLISHED_FLOOD:". There aren't any logs.

Configuration

Operating system: Arch Linux (Manjaro + KDE), with Linux 4.14.40-1

Version of Telegram Desktop: 1.2.20-1 (installed with pamac)

Used theme: Default

[john-preston]

@Aloso I'm afraid this is because someone uses not a custom api_id for the build, but the default one, that is embed here on github.

You can either download the official version from https://desktop.telegram.org and it should work fine or ask the package maintainers to create their own api_id — https://core.telegram.org/api/obtaining_api_id#obtaining-api-id — and build the app with it.

[Aloso]

@john-preston Thanks for the reply, installing it manually worked. I also mailed the packer of the faulty package.

[svenstaro]

Arch maintainer here. Since when is that the case? It definitely used to work until very recently.

[svenstaro]

At any rate, this is a legitimate bug in two ways: The backend should not respond with Internal Server Error and the client should not flood.

[svenstaro]

Also, I don't really understand. Why is your own client considered a third-party client if built from GitHub?

[john-preston]

@svenstaro Because each app build should have it non public api_id :( the one published on github is an example one and I heard it has strict api restrictions. Official builds use a different one and each unofficial build should have it's own. I didn't document it anywhere, sorry.

[svenstaro]

Hang on. Isn't the api_id essentially a secret? Isn't it also tied to my account? What is your preferred workflow for packaging in official ways like this?

[john-preston]

@svenstaro

Well, it is not entirely secret - it can be found inside the app binary anyway. But by the terms of Telegram API every client application should obtain and use its own api_id. When a user generates it, it is linked to his account, yes.

There are two ways. One is to package the official binaries (someone did that for Ubuntu, if I remember correctly), it will then contain official api_id.

Other one is to build a custom version of Telegram Desktop. That way if you're going to deploy it for users and not for your private use you're supposed to (I guess) obtain your own api_id

https://core.telegram.org/api/obtaining_api_id#obtaining-api-id

and use it instead of a built-on in source code.

This is first time that issue is reported here, so there was nothing prepared for that. Currently ApiId and ApiHash are specified like that:

https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/config.h#L204

So if you don't want to change code you can add a CUSTOM_API_ID define and provide a "TelegramPrivate/custom_api_id.h" file near "tdesktop" folder in your build env that will hold those two variables:

static const int32 ApiId = [api_id];
static const char *ApiHash = "[api_hash]";

Perhaps I should modify the code in some way in order to make this an easier task.

[svenstaro]

I already have a separate telegram app that I actually develop. How do I create a second app without creating an actual account? Can we get official api_ids for distro packagers perhaps? This might actually be the best for you guys to track.

[john-preston]

@svenstaro I don't know what to suggest :( Currently only one api_id per user is allowed by the API. You may either use your api_id for both your app and tdesktop package, or use a second account (second phone number? meh), or ask someone else to participate with providing an api_id for tdesktop package.

Unfortunately there is nothing I can do about that or about the server restrictions for the public api_id from github code. I've just noticed that this case and this error @Aloso received are even mentioned in the "obtaining_api_id" document I've linked above.

[svenstaro]

This is not really satisfactory. Any chance for official endorsement of distro maintainers in some way?
Or could I just use the same tokens you use for your own binaries?

[primeos]

NixOS maintainer here. I'm also upset about this (especially since it wasn't mentioned in the release notes)...

https://my.telegram.org/apps even states the following: "It is forbidden to pass this value to third parties." (behind the "App api_id" and "App api_hash" fields).

Which is exactly what we would need to do if we'd use it as packages maintainers (in the source-code for transparent and reproducible builds and we couldn't technically avoid shipping it with the app), so this isn't really an option anyway.

I would also like to use the same api_id and api_hash as in the official binaries or get an api_id and api_hash for the NixOS package like @svenstaro already suggested.

@john-preston Do you happen to know someone from the Telegram team (who's responsible for this) who you could cc / notify about this?

Update: Submitted a request via https://telegram.org/support and linked to this issue (if that doesn't work we could try to DM https://twitter.com/smstelegram).

[john-preston]

@primeos I asked and was told, that current way of obtaining api_id / api_hash is from https://my.telegram.org/apps and currently only one for one user. Sorry.

Also, for the same reasons I don't use the official tdesktop api_id / api_hash in the github source code. All other official Telegram source codes on github just have blank api_id / api_hash, so without obtaining your own pair they just won't compile or won't work.

Perhaps this (+ docs explaining that) should be the correct way to do that here as well.

[svenstaro]

Would it be an OK compromise for downstream maintainer to also use the same tokens as the official release in that case? Who could we discuss this issue with on an operative level?

…

On Sat, 26 May 2018, 12:52 John Preston, ***@***.***> wrote: @primeos <https://github.com/primeos> I asked and was told, that current way of obtaining api_id / api_hash is from https://my.telegram.org/apps and currently only one for one user. Sorry. Also, for the same reasons I don't use the official tdesktop api_id / api_hash in the github source code. All other official Telegram source codes on github just have blank api_id / api_hash, so without obtaining your own pair they just won't compile or won't work. Perhaps this (+ docs explaining that) should be the correct way to do that here as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4717 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAGgHuvXNP_Owtrg7QsFJIYpLQUQT4Jks5t2TPsgaJpZM4UIpFO> .

[phiresky]

Just wanted to say that this is pretty annoying and makes me unable to use telegram desktop (also on Arch) without manually downloading, installing and updating the program from the website.

[WebReflection]

So ... this is broken even installing via flathub and flatpak https://flathub.org/apps/details/org.telegram.desktop

Basically Telegram is the only software in flatpak that supposed to reach every distro and fails everywhere like a charm.

This makes me, and everyone else, unable to use regular Linux install/update channels to use Telegram, and it used to work until a month ago.

Please fix this, thank you.

[klimentyev]

@john-preston Hi!
What is a general purpose of api_id and api_hash? I see the parameters in Debian repo (they aren't testing from Telegram repo): https://salsa.debian.org/debian/telegram-desktop/blob/debian/master/debian/patches/Debian-API-ID.patch#L16
So anyone can build the Telegram with the same id and hash, and paradigm "one id/hash for one build" doesn't work.

[john-preston]

@klimentyev They are required for connecting to MTProto. Each app should connect using some pair of api_id / api_hash.

[klimentyev]

@klimentyev They are required for connecting to MTProto. Each app should connect using some pair of api_id / api_hash.

Thx!
We have overlay with ebuilds for Gentoo distro and use default pair: msva/mva-overlay@1ed3468#diff-9de9f62d0c9167e45eb5ef7f22e13220R114

Can we use the pair from Debian for our Gentoo builds? Is it official way to get pair for distro?

[Johnnynator]

Thx!
We have overlay with ebuilds for Gentoo distro and use default pair: msva/mva-overlay@1ed3468#diff-9de9f62d0c9167e45eb5ef7f22e13220R114

Can we use the pair from Debian for our Gentoo builds? Is it official way to get pair for distro?

https://github.com/telegramdesktop/tdesktop/blob/dev/docs/api_credentials.md

[msva]

There is: going to my.telegram.org.

But more correct question would be: how can I obtain more than one id/hash pair per one cellphone number?
What if I maintain/develop more than one application?

And also, the rule "doesn't tell id/hash to thirdparties" doesn't work with opensource paradigm :-/

[msva]

https://github.com/telegramdesktop/tdesktop/blob/dev/docs/api_credentials.md

@Johnnynator I think, @klimentyev meant "is it any separate way to obtain id/hash for major linux distros" (to avoid binding id/hash pairs to single person phone number).

[john-preston]

@msva Yes, it doesn't, unfortunately.

Currently there is no way to obtain more than one id/hash pair per one Telegram account :( I think you can use ones from Debian repository.

[FlorianFranzen]

@john-preston: What exactly do you hope to archive with this API_ID? From my uninformed view it seems it is really just a very inefficient way to control binary distribution. It's not like you can rotate the API_IDs in your app too frequently while it will be hard to keep hidden inside the binaries you distribute.

[john-preston]

@FlorianFranzen I don't hope to achieve anything. It is how the server side works. I don't know what they hope to achieve with it 🙄

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.