hamid/baya-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

integrate telegram bot

Browse Source
This commit is contained in:
hamid
2026-07-28 22:25:15 +03:30
parent e6a8f93a1e
commit 630c7907ec
16 changed files with 760 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
telegram-otp-bot/README.md
+18 -7
View File
@@ -95,6 +95,7 @@ The two POST routes mirror the server's `ISmsSender` (`SendOtpAsync` / `SendAsyn
| `PORT` | `5010` | HTTP port. |
| `HOST` | `127.0.0.1` | Bind address. Keep it loopback unless the API runs on another machine. |
| `REDACT_CODE_IN_LOGS` | `false` | Keep the code out of *this process's* stdout (still delivered). |
| `TELEGRAM_PROXY_URL` | — | Optional outbound proxy for the Telegram hop — see below. |
The API key is the only access control — there is no IP allow-list and no TLS. Keep `HOST` on
loopback when the API runs on the same machine; if you must expose it, put it behind something that
@@ -111,15 +112,25 @@ Values come from `.env` (git-ignored) or from real environment variables, which
| `token check FAILED` / `fetch failed` | Wrong/revoked token, or no outbound access to `api.telegram.org` — see below. |
| `401` on every call | The caller isn't sending `X-Api-Key`, or its value differs from `API_KEY`. |
### Reaching Telegram from Iran
### Reaching Telegram from Iran — the proxy option
`api.telegram.org` is filtered, so the machine running this needs a proxy. On **Node 24+** the built-in
`fetch` honours the standard proxy variables once opted in — uncomment these in `.env`:
`api.telegram.org` is filtered, so the machine running this usually needs a proxy for **its own** hop to
Telegram. (The API → relay hop is loopback/LAN and never proxied.) Set one URL in `.env`:
```
NODE_USE_ENV_PROXY=1
HTTPS_PROXY=http://127.0.0.1:10809
TELEGRAM_PROXY_URL=http://127.0.0.1:10809 # or socks5://127.0.0.1:10808
```
pointing `HTTPS_PROXY` at whatever your VPN/proxy client listens on. On older Node, run the process
under a system-wide/TUN-mode proxy instead — `fetch` there ignores the env vars.
- **Opt-in.** Unset ⇒ the relay connects directly, byte-for-byte as before. The boot banner prints which
it is (`proxy: socks5://127.0.0.1:10808` or `proxy: (none — direct to api.telegram.org)`).
- **Schemes:** `http`/`https` (an HTTP `CONNECT` tunnel) and `socks5`/`socks5h`. Credentials go in the URL
(`socks5://user:pass@host:1080`) and are never logged.
- **Local machine with a VPN client** → point it at that client's HTTP or SOCKS listener.
**VPS with a proxy client in a docker container** → put the relay and the proxy on the same docker
network and use the container name, e.g. `http://proxy:1080`; from the host, `http://127.0.0.1:<published-port>`.
- SOCKS5 requests are sent with the hostname (not a pre-resolved IP), so DNS resolves at the proxy —
local DNS is filtered too.
- `HTTPS_PROXY` / `ALL_PROXY` (either case) are used as a fallback when `TELEGRAM_PROXY_URL` is unset, so a
container that already sets them needs no extra config. `NODE_USE_ENV_PROXY` is not needed and not read —
the tunnel is handled in-process, so behaviour is the same on every Node ≥ 18.
- A malformed proxy URL is fatal **at boot**, not silently at the first OTP.