1Хто має доступ до бота

Зараз твій бот віддає список усіх, хто йому писав, кожному, хто знає команду, а /add, /edit і /del виконує для будь-кого: хто завгодно може написати боту й стерти запис у базі. Адреси бота ніхто не ховає — його знайдуть за назвою в пошуку Telegram. Сьогодні ти зачиниш ці двері. Список і всі зміни працюватимуть лише для тебе, а чужим бот відповість ввічливою відмовою. Для всіх лишиться команда /stats із двома числами: скільки людей писали боту і скільки повідомлень вони надіслали.

Як бот дізнається, що це ти? У кожного повідомлення Telegram дописує номер того, хто його написав (chat_id), і підробити цей номер не можна. Ти запишеш свій номер у .env як ADMIN_IDS, а бот перед кожною небезпечною командою звірятиме номер зі списком. Пароль і сторінка входу для цього не потрібні. Для сміливих є ще необов’язковий PIN: кілька цифр, які бот зберігає не як є, а у вигляді «відбитка» (хеша; пояснимо в розділі 3).

А ще ти розберешся з правами файлів у Linux і переконаєшся, що .env із токеном і база з іменами однокласників не читаються нікому, крім тебе.

Наприкінці покажеш: відмову чужому на /users, /add і /del (у try_bot.py з чужим номером і в Telegram з другого акаунта), список для себе, числа з /stats без жодного імені, права -rw------- у .env і app.db.

Перевіряємо лише своєУсі перевірки сьогодні — на твоєму власному боті: чужий номер ти імітуєш сам, через try_bot.py --id …. Бота однокласника з другого акаунта «пробувати на міцність» не можна без його згоди: ти не знаєш, що саме він зберігає в базі, і чужі дані дивитися так само заборонено, як змінювати. Помітив, що в когось команди досі відкриті, — скажи йому про це, а не користуйся.

Витік даних — це коли чужі люди бачать те, що їм бачити не можна. Не обов’язково через злам: найчастіше дані просто лежать відкрито, і хтось на них натрапляє. Саме так зараз із твоєю командою /users. Хто написав її боту, отримає для кожної людини ім’я, нік у Telegram, коли вона писала вперше й востаннє, скільки разів, і твою примітку про неї. Незнайомець, однокласник, бот-перебирач — не має значення: бот відповідає всім однаково.

«Але ж мого бота ніхто не знає» — не захист. Назва бота лежить у пошуку Telegram, її видно на скриншотах і в чаті класу, а нік бота можна просто вгадати. Адреса і назва — не пароль.

Чим це погано, якщо там «лише імена»? Ім’я, нік і час, коли людина пише, разом — це вже персональні дані: відомості, за якими можна впізнати конкретну людину. Незнайомець дізнається, що Оля з ніком @olya_kosmos щовечора о десятій пише боту про космос, — і може знайти її в Telegram, назвавшись «другом із гуртка». Люди писали твоєму боту, довіряючи тобі, а не всьому інтернету. На занятті 04 ти вирішив зберігати лише мінімум; сьогодні — показувати цей мінімум лише тому, кому він потрібен.

Що закрити, а що лишити відкритим? Правило таке: усе, що стосується конкретних людей або змінює дані, — лише власнику. Усе, з чого про конкретну людину нічого не дізнаєшся, — можна всім.

Замок ставимо у самому боті, на початку обробки кожного повідомлення, а не «десь збоку». Пояснення — просте: чужа людина може написати будь-яку команду будь-коли. Приховати команду з підказки /help нічого не захистить, а от перевірка в коді, яку відвідувач не може обійти, — захищає.

Перевірку «хто ти» називають автентифікацією, а рішення «що тобі можна» — авторизацією. У сайтів автентифікація — це пароль і сторінка входу. У бота все простіше: Telegram уже перевірив людину, коли вона зайшла у свій акаунт, і до кожного повідомлення дописав її номер:

{"message": {"from": {"id": 100200300, "first_name": "Богдан"},
             "chat": {"id": 100200300},
             "text": "/users"}}

Число 100200300 — це і є from.id (номер людини) та chat.id (номер чату; у приватній розмові вони збігаються). Ім’я та нік людина може змінити на які завгодно — написати «Богдан» може будь-хто. А от номер Telegram ставить сам, і підробити його в повідомленні, яке приходить боту, не можна. Тому доступ дають за номером, а не за іменем.

Правило авторизації в нас одне: номер у списку ADMIN_IDS — адмін, може все; решта — лише відкрите. Список лежить у ~/app/.env, поруч із токеном:

ADMIN_IDS=100200300
ADMIN_IDS=100200300,777888999

Один рядок із одним номером або кількома через кому (другий рядок — лише приклад, у файлі має бути один рядок ADMIN_IDS). Готовий модуль access.py читає цей рядок і дає боту одну функцію:

refusal = access.check(sender.get("id"), text)
if refusal:
    return refusal

Якщо людині цю команду не можна, check() повертає текст відмови, і бот просто відповідає ним та більше нічого не робить: до бази справа не доходить. Якщо можна — повертає None («нічого заважати»), і бот працює як раніше. Відмова — це зрозуміла відповідь: «Ця команда лише для власника бота», а не мовчання і не рядки з помилкою. Порядок важливий: перевірка стоїть першою, ще до того, як бот розбереться, що саме в команді (скажімо, чи є в ній номер запису). З тим, хто не має права, бот не обговорює, що не так у його даних.

Чому не просто один власник? Бот може обслуговувати вчителя й помічника, тому в ADMIN_IDS можна кілька номерів. А якщо номер змінити в .env і перезапустити службу, право отримує інша людина: пароля передавати не треба.

Номер — не секрет, але й не прикрасаСвій номер можна показувати: самого по собі він нічого не відкриває. Небезпечно інше: якщо хтось дізнається токен бота. Тоді він зможе писати від імені бота. Тому токен ніколи не публікують, а файл .env закривають від сусідів (розділ 4).

Як користуватися ШІ-помічникомБезпека — тема, де ШІ добре пояснює: «Що таке chat_id у Telegram?», «Чим автентифікація відрізняється від авторизації?». Але в чат ніколи не вставляють вміст .env, токени, PIN, хеші й справжні номери чужих людей — навіть «щоб ШІ подивився, чи все правильно». Замість значень показуй назви: ADMIN_IDS=…. Кожну відповідь перевіряй на своєму боті, а на занятті пояснюй своїми словами: викладач може показати будь-який рядок access.py.

Номер чату відповідає на питання «хто пише», але не на питання «чи пише справді він». Телефон адміна можна залишити без нагляду, і тоді хтось інший відкриє розмову з ботом і напише /del. Тому для найнебезпечнішої команди (видалення) додають ще й PIN: кілька цифр, які ти вводиш командою /pin і які діють п’ять хвилин. Цей PIN бот зберігає не як є, а як хеш.

Хеш — «відбиток» тексту: рядок однакової довжини, який отримують із PIN за незмінним правилом. З PIN хеш порахувати легко, а з хеша PIN — ні. Спробуй на сервері (ці команди нічого не змінюють):

python3 -c "import hashlib; print(hashlib.sha256(b'sonechko7').hexdigest())"
python3 -c "import hashlib; print(hashlib.sha256(b'sonechko7').hexdigest())"
python3 -c "import hashlib; print(hashlib.sha256(b'Sonechko7').hexdigest())"

Перші дві надрукують однаковий рядок із 64 символів — 020320950c4f…71a00e9a: той самий текст завжди дає той самий результат. Третя відрізняється однією великою літерою, а рядок вийде зовсім інший: 7c1fe0e31d5d…4834712a. На цьому тримається перевірка: бот рахує хеш введеного PIN і порівнює з тим, що лежить у .env. Збіглося — PIN правильний, хоча сам PIN бот ніде не зберігав.

Але одного sha256 мало. Він дуже швидкий, тож той, хто вкрав файл, перебирає варіанти за долі секунди. І однаковий PIN дає однаковий хеш. Від цього рятують сіль (випадковий рядок, свій для кожного хеша, який додають перед хешуванням) і спеціальний повільний алгоритм scrypt, що є в стандартній бібліотеці Python. У нашому pin.py до хеша додано і те, і те:

$scrypt$n=16384,r=8,p=1$226c93a469f6d5426ab0078b91e8f3e4$2d8545f1eb174ad008d4fc1f0eb15095150879886fb0a9459bb134af922fb5e9

scrypt              назва алгоритму
n=16384,r=8,p=1     налаштування: скільки роботи й пам’яті
226c93a4…f3e4       сіль: 16 випадкових байтів, записаних 32 символами
2d8545f1…5e9        сам хеш: 32 байти, записані 64 символами

Для цікавихПеревірку check_pin() написано так, щоб вона порівнювала хеші функцією hmac.compare_digest(): вона витрачає однаковий час, хоч би де рядки розійшлися, а звичайне == зупиняється на першому відмінному символі, і за часом відповіді можна було б підбирати символ за символом.

Скільки захисту дає такий PIN? Менше, ніж довгий пароль. Чотири цифри — лише 10 000 варіантів, і якщо хтось отримає твій файл .env, він переб’є їх за хвилини, навіть із scrypt. Тому PIN захищає від людини, яка взяла твій телефон, але не від викрадення файлів: для цього є права файлів (розділ 4) і правило «токен не в git». Навіщо тоді хеш? Щоб PIN не лежав у файлі відкритим текстом, а файл не був готовою відповіддю.

Ще одна деталь. PIN вводять у терміналі через getpass.getpass(), а не пишуть у команді (pin.py 1234). Усе, що набираєш у терміналі, записується в ~/.bash_history, а поки команда працює, її рядок видно в списку процесів сервера (ps) усім, хто на нього зайшов. А ще екран може бачити весь клас. І команду /pin у Telegram після введення видали з чату.

Усі замки в боті марні, якщо сусід по серверу просто прочитає файл ~/app/.env з твоїм BOT_TOKEN і списком ADMIN_IDS або скопіює собі ~/data/app.db з іменами. На нашому сервері працює вся група, і в кожного свій користувач Linux — обліковий запис із власним іменем (твій логін) і номером. Подивись, хто ти для системи:

id

Відповідь буде схожа на uid=1023(bohdan.g9) gid=1023(bohdan.g9) groups=1023(bohdan.g9),1001(klub): номер і ім’я користувача, твоя основна група (у Linux у кожного користувача є група з тим самим ім’ям, і в ній лише він) і додаткова група klub, у якій усі учні, — через неї сервер дозволяє вам входити за паролем. Числа в тебе будуть інші.

Кожен файл і кожна тека мають власника, групу і права для трьох кіл: власника, групи й усіх інших. Їх показує ls -l:

-rw-------. 1 bohdan.g9 bohdan.g9  312 … .env
drwxr-x---. 2 bohdan.g9 bohdan.g9 4096 … data

-  або  d       тип: звичайний файл чи тека (directory)
rw-             власник: читати (r), писати (w), запускати (x) — тут без x
---             група: нічого
---             усі інші: нічого
.               позначка SELinux — додаткового захисту на нашому AlmaLinux; на неї можна не звертати уваги
bohdan.g9       власник
bohdan.g9       група

Для теки букви означають трохи інше: r — бачити список файлів, w — створювати й видаляти в ній файли, x — заходити в неї й діставати файл за назвою.

Права часто записують трьома цифрами — по одній на коло. Кожна буква має вагу: r = 4, w = 2, x = 1, і ваги додають. rw- = 4 + 2 = 6, r-x = 4 + 1 = 5, --x = 1, --- = 0. Змінює права команда chmod: chmod 600 .env — «власникові читати й писати, решті нічого».

Права на теці й права на файлі — два різні замки. .env лежить у закритій теці ~/app, але якщо колись ти відчиниш теку (скажімо, chmod 755 ~/app, щоб показати другові файл), файл із правами 644 одразу стане читабельним для всіх. Тому закривають і теку, і сам файл. Автоперевірки L07.6 і L07.7 дивляться саме на права файлів: у групи й інших не має бути жодної букви.

Хто ще є на сервері? nginx — окремий користувач, програма, що віддає сайти: вона читає твою ~/www, бо там права «читати всім», і не дістає до ~/app і ~/data. І root — головний користувач, адміністратор сервера. Для нього права файлів не діють, він може прочитати будь-що. Тому на шкільному сервері не тримають нічого справді особистого: адміністратор технічно бачить усе, і це треба знати.

Linux так само береже паролі власних користувачів — і твій пароль для входу по SSH теж:

ls -l /etc/passwd /etc/shadow

У /etc/passwd (права -rw-r--r--, читати всім) — список користувачів, а на місці пароля стоїть x: «шукай деінде». Хеші паролів лежать в /etc/shadow, і в нього права ----------: не прочитає ніхто, крім root. Та сама ідея, що й у твоїй адмінці: хеш замість пароля і файл, закритий від сторонніх.

Кожне питання оцінюється відразу в браузері — це лишається так само. Ця кнопка лише надсилає підсумок учителю, щоб відповіді не зникли разом із закритою вкладкою.

Список критеріїв і що саме вони означають — у таблиці вище, «Що перевіряє автоматика». Тут — та сама перевірка, але прямо зараз, без очікування на найближчий прохід за розкладом.

1. Другий адмін. Попроси друга-учня з групи дати тобі свій номер (він дізнається його так само, як ти в кроці 2, і це не секрет). Але в ADMIN_IDS його не додавай, а лише подумай: яку одну команду ти йому довірив би, а яку ні? Допиши в ~/app/README.md розділ ## Хто має доступ: що відкрито для всіх, що лише для власника, чому, і як власник додає ще одного адміна (без токена й PIN, звісно). Три-п’ять речень своїми словами. Розділи ## Що це і ## Як запустити не чіпай.
2. Нова закрита команда. Придумай для бота ще одну команду, яка показує людей чи щось змінює (скажімо, /export зі списком у вигляді тексту), і додай її в ADMIN_COMMANDS. Перевір через try_bot.py --id 777 (відмова) і зі своїм номером (працює).
3. Свої PIN-команди. (за бажанням, після кроку 9) Додай до PIN_COMMANDS ще одну команду, яку варто захистити. Поясни, чому PIN із чотирьох цифр захищає від чужих рук, але не від викрадення файлу .env.
4. Поясни свій код. Підготуйся пояснити будь-який рядок check(), admin_ids() і check_pin(). Зокрема: чому перевірка стоїть першою у handle_update(); чому доступ тримається на номері, а не на імені; навіщо відмова — текст, а не помилка; що означають цифри в 600, 700, 711; чому токен бота треба закривати і правами, і Git.
5. Збережи. git add -A, git commit -m "Заняття 07: розділ «Хто має доступ» у README", git push origin main і git push. Перед git add — git status --short: .env у списку бути не повинно.

29Після правки bot.py служба не стартує

Ознаки: systemctl --user is-active club-bot пише activating або failed, а бот у Telegram мовчить. Причину назве Python — сам або в журналі:

cd ~/app
/opt/club/venv/bin/python3 -c "import bot"
tail -n 30 ~/logs/club-bot.log

Дивись на останній рядок звіту Traceback:

• ModuleNotFoundError: No module named 'access' (або 'pin') — файлу немає в ~/app: ls ~/app/access.py, і якщо його немає — крок 4;
• NameError: name 'access' is not defined — пропущено import access (крок 5);
• SyntaxError чи IndentationError — дужки або відступи у вставках кроку 5. Не бачиш помилки очима — git diff bot.py покаже все, що ти змінив сьогодні;

Виправ і зроби systemctl --user restart club-bot. Якщо служба надто часто падала, systemd перестає її підіймати й пише start request repeated too quickly — тоді спершу systemctl --user reset-failed club-bot, потім restart.

30Автоперевірка: L07.1 «ADMIN_IDS» не зараховано

Перевірка читає ~/app/.env і вимагає один рядок ADMIN_IDS= з числами через кому. Найчастіші причини: рядок не дописано (крок 3); у номері є літери, лапки або пробіл усередині; замість номера стоїть ім’я чи нік (@bohdan — це не номер); порожнє значення. Перевір: grep -c "^ADMIN_IDS=" ~/app/.env має дати 1. Номер — це лише цифри, наприклад 100200300.

31Чужий бачить список або змінює базу (L07.2, L07.4)

Перевірка пише, яка саме команда пройшла. Що робити:

• на /users чужий побачив записи — вставку access.check(...) з кроку 5 зроблено нижче за обробку цієї команди або її нема. Вона має стояти перед першим if text.startswith(...);
• відповідь на /users збігається з «Не знаю такої команди» — бот узагалі не знає цієї команди, а перевірка очікує саме відмову. Додай команду в ADMIN_COMMANDS у access.py (вона там уже є для /users, /list, /add, /edit, /del) і перевір, що import access у bot.py є;
• чужий змінив базу — шукай у bot.py команди, які пишуть у базу, але мають іншу назву, ніж у ADMIN_COMMANDS. Додай їх у список;
• служба працює, а try_bot.py пускає чужого — ADMIN_IDS містить номер 777 (ти сам його додав під час досліду): grep ^ADMIN_IDS= .env.

32Власник не бачить список (L07.3)

Перевірка питає від імені людини з ADMIN_IDS і чекає, що /users або /list покажуть записи. Найчастіше: команди зі списком немає зовсім (заняття 04–05), у access.py зайва команда, а в боті її нема, або номер у .env не збігається з номером, з яким ти пробуєш. Спробуй python3 try_bot.py --id <свій номер> "/users": має бути список, а не відмова.

33Статистика порожня чи не зараховано (L07.5)

Чужий на /stats має отримати відповідь із числом людей, але без жодного імені. Ця команда лише для власника на /stats — ти додав /stats у ADMIN_COMMANDS, прибери. Не знаю такої команди — немає вставки if text.startswith("/stats") (крок 5) або вона стоїть нижче за загальне «невідома команда». у project.yaml порожнє commands.stats — не заповнено рядок у кроці 5. Помилка no such table: users — таблиці немає: python3 init_db.py.

34Секрет записано двічі або .env затерто

Якщо ADMIN_IDS опинився у файлі двічі — служба візьме перший, автоперевірка інший. Прибери старі рядки й запиши один:

cd ~/app
sed -i '/^ADMIN_IDS=/d' .env
echo "ADMIN_IDS=100200300" >> .env
grep -c "^ADMIN_IDS=" .env
ls -l .env
systemctl --user restart club-bot

sed -i редагує файл на місці, а /^ADMIN_IDS=/d означає «видали рядки, що починаються з ADMIN_IDS=»; решту .env він не чіпає. grep -c має сказати 1, ls -l — -rw------- (інакше chmod 600 .env).

Якщо ж замість >> вийшло > і в .env лишився один рядок, відновлюй решту. BOT_TOKEN візьми в @BotFather (/mybots → твій бот → API Token). Рядки ШІ з заняття 06 для учнів до 18 років такі: LLM_BASE_URL=http://127.0.0.1/llm/v1, LLM_API_KEY=school, LLM_MODEL=openrouter/free. Вписуй їх через nano ~/app/.env, кожен з нового рядка, потім ls -l .env (має бути -rw-------) і restart. Перевір бота: python3 try_bot.py "/start".

35Автоперевірка: L07.6–L07.8 не зараховано

Кожна перевірка пише причину. Що вона означає:

• L07.6 чи L07.7 права … — 644: сусіди по серверу можуть його прочитати — chmod 600 ~/app/.env ~/data/app.db (крок 10);
• L07.8 .gitignore не приховує .env — допиши правило: echo ".env" >> ~/app/.gitignore (дві дужки!) і закоміть .gitignore. у історії є .env — файл колись потрапив у коміт, і все, що в ньому було, вважай украденим. Спершу заміни секрети: новий токен бота в @BotFather (/revoke, потім новий токен у .env), потім restart. Далі git rm --cached .env і коміт — Git перестане стежити за файлом. А стару історію чистять окремою командою, яка переписує всі коміти, — це роби лише разом із викладачем.