Хто має право змінювати

Що ти зробиш сьогодні

Теорія

1. Автентифікація і авторизація — дві різні перевірки

Ці два слова звучать схоже, їх постійно плутають, а означають вони різні речі.

Автентифікація

Відповідь на питання «хто ти». Людина показує щось, що є тільки в неї: пароль, код із застосунку, відбиток пальця. Система звіряє це й каже: так, це Богдан.

Авторизація

Відповідь на питання «що тобі можна». Система вже знає, що це Богдан, і тепер вирішує: свої записи він редагувати може, чужі — ні.

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

В електронному щоденнику так само. Ти входиш зі своїм паролем — це автентифікація. Далі бачиш свої оцінки й не бачиш чужих, а вчитель тим самим щоденником оцінки виставляє. Логін однаково перевірений в обох, права різні.

Сьогодні ми робимо просту схему: у сервісу є один власник — ти. Автентифікація — перевірка твого пароля. Авторизація — правило «змінювати дані може лише власник, дивитися може будь-хто».

2. Чому сервіс не зберігає паролів

Найпростіше рішення — записати пароль у стовпець password і при вході порівняти рядки. Так робити не можна, і причина не в теорії. Бази витікають: помилка в коді, украдений бекап, забутий відкритий порт — так називають номер, за яким сервер розрізняє програми, що приймають запити з мережі; якщо номер, на якому працює база, доступний з інтернету, під’єднатися до неї може будь-хто. Якщо в базі лежали паролі, той, хто її отримав, має готовий список «логін — пароль». Найгірше не те, що він зайде у твій сервіс. Найгірше те, що більшість людей ставить той самий пароль у пошті й соцмережах, і тепер він відкриє їх теж.

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

Подивись, як це виглядає. Виконай ці три команди на сервері одну за одною. Python тут запускається довгим шляхом /opt/club/venv/bin/python, а не коротким python3: це окремо встановлений Python, спільний для всієї групи, і саме в нього адміністратор поставив бібліотеки курсу. Далі на цій сторінці буде тільки цей шлях, бо твій сервіс на сервері працює з тим самим Python.

/opt/club/venv/bin/python -c "import hashlib; print(hashlib.sha256('sonechko7'.encode()).hexdigest())"
/opt/club/venv/bin/python -c "import hashlib; print(hashlib.sha256('sonechko7'.encode()).hexdigest())"
/opt/club/venv/bin/python -c "import hashlib; print(hashlib.sha256('Sonechko7'.encode()).hexdigest())"

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

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

3. Сіль і чому sha256 для паролів мало

З sha256, який ти щойно запускав, є дві проблеми, і обидві практичні.

Перша: він швидкий. Звичайний комп’ютер рахує сотні мільйонів таких хешів за секунду. Для перевірки цілості файлів, задля якої sha256 і зроблений, це добре. Для паролів швидкість шкідлива: той, хто перебирає варіанти, перевіряє їх із такою самою швидкістю.

Друга: однаковий пароль дає однаковий хеш завжди й у всіх. Тобто в украденій таблиці видно, що двадцять людей мають один і той самий пароль. А ще заздалегідь порахований словник популярних паролів разом із їхніми хешами відкриває всі ці записи одним пошуком.

Обидві проблеми розв’язує bcrypt — алгоритм, зроблений спеціально для паролів. Він робить дві речі:

• Додає до пароля сіль — випадковий набір символів, свій для кожного запису. Однакові паролі з різною сіллю дають різні хеші, і словник наперед не порахуєш. Сіль не секрет, вона зберігається в тому ж рядку поруч із хешем.
• Навмисне рахує повільно, багато разів поспіль. Одна перевірка на вході займає частки секунди й людині не заважає, а перебір мільярда варіантів розтягується на роки: при чверті секунди на одну перевірку це майже вісім років безперервної роботи.

Запусти двічі й порівняй результат:

/opt/club/venv/bin/python -c "import bcrypt; print(bcrypt.hashpw(b'sonechko7', bcrypt.gensalt()).decode())"
/opt/club/venv/bin/python -c "import bcrypt; print(bcrypt.hashpw(b'sonechko7', bcrypt.gensalt()).decode())"

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

$2b$12$eImiTXuWVxfM37uY4JANjQ.O5AbcDefGhIjKlMnOpQrStUvWxYz01

$2b$              назва алгоритму — bcrypt
12                скільки разів рахувати: 2 у 12-му степені, тобто 4096 повторів
наступні 22       сіль
останній 31       сам хеш

Разом рівно 60 символів. Початок $2b$ — це позначка версії bcrypt: її ставить та бібліотека, з якою ми працюємо. У старіших рядках трапляються ще $2a$ і $2y$ — той самий алгоритм із дрібними відмінностями. Автоматика курсу перевіряє саме $2b$, бо саме його дає наша бібліотека; за цим початком і довжиною видно, що в базі лежить хеш.

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

4. Як сервер пам’ятає, що ти вже увійшов: кука і сесія

Є деталь, через яку тема здається складнішою, ніж вона є. HTTP — набір правил, за якими браузер спілкується з сервером, — не має пам’яті. Кожен запит приходить окремо, сам по собі, і сервер не знає, чи бачив він цього відвідувача хвилину тому. Відкрив сторінку — запит. Натиснув кнопку — новий запит, і для сервера він ніяк не пов’язаний із попереднім.

Якби пам’яті не було зовсім, пароль довелося б надсилати з кожним запитом. Тому роблять інакше: пароль перевіряють один раз, а далі сервер видає браузеру короткий рядок, який діє обмежений час і замінює пароль у наступних запитах.

Кука

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

Сесія

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

Тепер головне питання: що покласти в куку, щоб її не можна було підробити. Якщо записати просто bohdan.g9, будь-хто відкриє інструменти розробника, впише туди свій рядок — і сервер повірить.

Тому в куку кладуть три частини: логін, час закінчення сесії й підпис. Підпис — це хеш від перших двох частин разом із секретним ключем, який знає тільки твій сервер:

bohdan.g9:1800000000:9Kx2p_wQ7hRt4mLdVzB1cYsNfGjE8aUoI3rTnP0qXeM

Середнє число — час закінчення сесії, записаний так, як його зберігає комп’ютер: скільки секунд минуло від 1 січня 1970 року. 1800000000 — це 15 січня 2027 року.

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

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

5. Що закривати, а що лишити відкритим

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

Перед розподілом варто знати, як запит узагалі доходить до твого коду. nginx — програма на сервері, яка приймає всі запити з інтернету й передає кожен потрібній програмі за адресою: усе, що починається на /u/bohdan.g9/, вона віддає твоєму сервісу. Сам сервіс працює на сервері як служба — програма, яку система запускає сама, тримає ввімкненою постійно й перезапускає за командою. Усе, що служба друкує під час роботи, система складає в журнал: там видно рядки про запуск і текст помилок. У практиці ти й перезапускатимеш службу, і читатимеш журнал.

Ендпоінт — пара «метод плюс адреса», яку вміє обробляти твій сервіс. GET /api/habits і POST /api/habits — два різні ендпоінти з однаковою адресою, і закривати їх можна окремо. Розподіл на сьогодні такий:

Тепер про те, як перевірку прикріплюють до ендпоінта. У FastAPI для цього є залежність — функція, яку фреймворк викликає перед тілом ендпоінта. Якщо вона відмовляє, тіло ендпоінта не виконується взагалі: запит зупиняється на вході. Нашу залежність зватимуть require_owner; у практиці ти додаси її до POST і DELETE, а GET лишиш без неї.

Коли гість намагається зробити те, на що не має права, сервер відповідає кодом. Коди відповідей ти бачив на занятті 05, тут додаються три нові:

401

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

403

«Заборонено». Означає: я знаю, хто ти, і саме тобі цього не можна. Ця відповідь знадобиться, коли в сервісі буде більше одного користувача. Сьогодні власник один, тому в нас скрізь 401.

422

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

Сховати кнопку — це не захист

Далі в практиці ти зробиш так, щоб гість не бачив форми додавання й кнопок «видалити»: вони будуть сховані стилем CSS. Це зручність, а не захист. Стилі й розмітка виконуються в браузері відвідувача, і він може змінити там усе: відкрити інструменти розробника (клавіша F12), прибрати правило, що ховає кнопку, і натиснути її.

Відмовити у видаленні може перевірка на сервері: до неї відвідувач не дістає, бо код сервера виконується не в його браузері. Це та сама думка, що й на занятті 05 із валідацією: атрибут required у формі підказує людині, поки вона заповнює поля, а рішення про запис ухвалює сервер.

6. Секрет і файл .env

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

Секрет не пишуть у коді, і причина конкретна: код лежить у git, а git зберігає всю історію. Нагадаю два слова з заняття 03. Репозиторій — тека проєкту разом із прихованою текою .git, у якій git тримає всі попередні стани файлів. Коміт — збережений стан усіх файлів проєкту на певний момент, із датою, автором і твоїм описом зміни; історія проєкту складається саме з комітів, і кожен із них можна відкрити пізніше.

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

git show HEAD~5:main.py

Тому секрети виносять у файл .env поруч із кодом, а сам файл додають до .gitignore — списку того, що git не відстежує. Назва .env — від слова environment, «оточення»: усередині звичайний текст, по рядку на значення.

SESSION_SECRET=8f3c1a94e07b25d6f8a1c0b73e9d4526a7f0c8b1d2e3f4a596071829304a5b6c

Крапка на початку назви означає, що файл прихований: ls його не покаже, потрібно ls -a. Це не захист, просто традиція для службових файлів.

Порядок дій тут важливий, і саме на ньому найчастіше помиляються. Спочатку рядок у .gitignore, потім створення файлу з секретом. Навпаки — і є всі шанси зробити git add ., не подивившись, що саме додається.

Практика

У прикладах — таблиця habit з полями id, title, days і ендпоінти з заняття 05. Підставляй свої назви: вони записані у project.yaml у розділах database й endpoints.

ssh bohdan.g9@91.219.61.4
cd ~/app
git check-ignore -v .env

echo ".env" >> .gitignore
git add .gitignore
git commit -m "gitignore: закрив .env до того, як його створив"

cd ~/app
/opt/club/venv/bin/python -c "import secrets; print('SESSION_SECRET=' + secrets.token_hex(32))" > .env
chmod 600 .env
cat .env

git status --short

sqlite3 ~/data/app.db "CREATE TABLE IF NOT EXISTS owner (
  id            INTEGER PRIMARY KEY,
  login         TEXT NOT NULL UNIQUE,
  password_hash TEXT NOT NULL
);"
sqlite3 ~/data/app.db ".schema owner"

nano ~/app/auth.py

"""Автентифікація. Готова заготовка — цей файл не редагуємо.

Дає чотири речі:
  hash_password / check_password — зробити хеш пароля і звірити з ним введений
  make_session                   — вміст куки після успішного входу
  current_owner                  — хто увійшов, або None; помилки не викидає
  require_owner                  — залежність, що закриває ендпоінт: гість дістає 401
"""
import base64
import hashlib
import hmac
import os
import time
from pathlib import Path

import bcrypt
from fastapi import Cookie, HTTPException

COOKIE_NAME = "club_session"
SESSION_HOURS = 12


def _load_env(path):
    """.env — звичайний текстовий файл, по рядку «КЛЮЧ=значення»."""
    if not path.exists():
        return
    for line in path.read_text(encoding="utf-8").splitlines():
        line = line.strip()
        if not line or line.startswith("#") or "=" not in line:
            continue
        key, value = line.split("=", 1)
        os.environ[key.strip()] = value.strip()


_load_env(Path(__file__).parent / ".env")
SECRET = os.environ.get("SESSION_SECRET", "")
if not SECRET:
    raise RuntimeError("У файлі ~/app/.env немає рядка SESSION_SECRET")


def hash_password(plain):
    """З пароля робить хеш, який можна зберігати в базі."""
    return bcrypt.hashpw(plain.encode("utf-8"), bcrypt.gensalt()).decode("ascii")


def check_password(plain, stored):
    """Звіряє введений пароль із хешем із бази. Повертає True або False."""
    try:
        return bcrypt.checkpw(plain.encode("utf-8"), stored.encode("ascii"))
    except (ValueError, AttributeError):
        return False


def _sign(data):
    """Підпис рядка секретом із .env."""
    mac = hmac.new(SECRET.encode("utf-8"), data.encode("utf-8"), hashlib.sha256)
    return base64.urlsafe_b64encode(mac.digest()).decode("ascii").rstrip("=")


def make_session(login):
    """Вміст куки: логін, час закінчення і підпис."""
    until = int(time.time()) + SESSION_HOURS * 3600
    data = login + ":" + str(until)
    return data + ":" + _sign(data)


def _read_session(value):
    """Розбирає куку. Повертає логін або None, якщо кука підроблена чи стара."""
    parts = (value or "").split(":")
    if len(parts) != 3:
        return None
    login, until, sign = parts
    expected = _sign(login + ":" + until)
    if not hmac.compare_digest(sign.encode("utf-8"), expected.encode("ascii")):
        return None
    try:
        if int(until) < time.time():
            return None
    except ValueError:
        return None
    return login


def current_owner(club_session: str = Cookie(default="")):
    """Логін того, хто увійшов, або None."""
    return _read_session(club_session)


def require_owner(club_session: str = Cookie(default="")):
    """Залежність FastAPI: гість сюди не проходить."""
    login = _read_session(club_session)
    if not login:
        raise HTTPException(status_code=401, detail="Потрібно увійти")
    return login

nano ~/app/set-password.py

"""Записує власника і хеш його пароля в базу. Запускати з теки ~/app."""
import getpass
import sys

from auth import hash_password
from db import query, execute

login = input("Логін власника: ").strip()
first = getpass.getpass("Пароль: ")
again = getpass.getpass("Ще раз: ")

if first != again:
    sys.exit("Паролі не збігаються, нічого не записано")
if len(first) < 8:
    sys.exit("Пароль коротший за 8 символів, візьми довший")
if len(first.encode("utf-8")) > 72:
    sys.exit("Пароль довший за 72 байти — bcrypt такий не бере, візьми коротший")

stored = hash_password(first)

if query("SELECT id FROM owner WHERE login = ?", (login,)):
    execute("UPDATE owner SET password_hash = ? WHERE login = ?", (stored, login))
    print("Пароль оновлено для", login)
else:
    execute("INSERT INTO owner (login, password_hash) VALUES (?, ?)", (login, stored))
    print("Власника додано:", login)

cd ~/app
/opt/club/venv/bin/python set-password.py

sqlite3 ~/data/app.db "SELECT login, password_hash FROM owner;"

nano ~/app/main.py

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field

from db import query, execute

from fastapi import FastAPI, HTTPException, Depends, Response
from pydantic import BaseModel, Field

from db import query, execute
from auth import (COOKIE_NAME, SESSION_HOURS, check_password, current_owner,
                  make_session, require_owner)

COOKIE_PATH = "/u/bohdan.g9/"        # ← свій логін


class LoginData(BaseModel):
    login: str = Field(min_length=1, max_length=64)
    password: str = Field(min_length=1, max_length=200)


@app.post("/api/login")
def login(data: LoginData, response: Response):
    """Перевіряє пароль і видає куку сесії."""
    rows = query("SELECT * FROM owner WHERE login = ?", (data.login,))
    if not rows or not check_password(data.password, rows[0]["password_hash"]):
        raise HTTPException(status_code=401, detail="Невірний логін або пароль")

    response.set_cookie(
        COOKIE_NAME,
        make_session(data.login),
        max_age=SESSION_HOURS * 3600,
        httponly=True,
        samesite="lax",
        path=COOKIE_PATH,
    )
    return {"ok": True, "login": data.login}


@app.post("/api/logout")
def logout(response: Response):
    """Прибирає куку — далі сервіс бачить звичайного гостя."""
    response.delete_cookie(COOKIE_NAME, path=COOKIE_PATH)
    return {"ok": True}


@app.get("/api/me")
def me(owner=Depends(current_owner)):
    """Сторінка питає це при відкритті: показувати кнопки чи форму входу."""
    return {"logged_in": owner is not None, "login": owner}

@app.post("/api/habits")
def create_habit(item: NewHabit):

@app.post("/api/habits")
def create_habit(item: NewHabit, owner: str = Depends(require_owner)):

@app.delete("/api/habits/{habit_id}")
def delete_habit(habit_id: int, owner: str = Depends(require_owner)):

nano ~/app/project.yaml

endpoints:
  list:   "GET /api/habits"           # уже є з заняття 05
  create: "POST /api/habits"          # уже є з заняття 05
  delete: "DELETE /api/habits/{id}"   # уже є з заняття 05
  login:  "POST /api/login"           # додаєш сьогодні

auth:                                 # цього розділу ще немає, додаєш цілком
  table: owner
  password_field: password_hash

systemctl --user restart club-api
systemctl --user status club-api

journalctl --user -u club-api -n 30

curl -s http://127.0.0.1/u/bohdan.g9/api/ping

curl -i -X POST http://127.0.0.1/u/bohdan.g9/api/habits \
  -H "Content-Type: application/json" \
  -d '{"title":"Спроба зайти без пароля","days":3}'

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/u/bohdan.g9/api/habits

read -s -p "Пароль: " PW; echo
PW="$PW" /opt/club/venv/bin/python -c "import json, os; print(json.dumps({'login': 'bohdan.g9', 'password': os.environ['PW']}))" \
  | curl -i -c ~/cookies.txt -X POST http://127.0.0.1/u/bohdan.g9/api/login \
      -H "Content-Type: application/json" -d @-

curl -i -b ~/cookies.txt -X POST http://127.0.0.1/u/bohdan.g9/api/habits \
  -H "Content-Type: application/json" \
  -d '{"title":"Запис від власника","days":3}'

unset PW
rm ~/cookies.txt

<section id="owner-box">
  <form id="login-form">
    <label for="f-login">Логін</label>
    <input id="f-login" type="text" autocomplete="username">

    <label for="f-pass">Пароль</label>
    <input id="f-pass" type="password" autocomplete="current-password">

    <button type="submit">Увійти</button>
  </form>
  <button type="button" id="logout-btn" class="only-owner">Вийти</button>
  <p id="login-msg"></p>
</section>

.only-owner { display: none; }
body.is-owner .only-owner { display: inline-block; }
body.is-owner form.only-owner { display: block; }
body.is-owner #login-form { display: none; }

<script>
const AUTH = '/u/bohdan.g9/api';          // ← свій логін

const loginForm = document.getElementById('login-form');
const loginMsg  = document.getElementById('login-msg');
const logoutBtn = document.getElementById('logout-btn');

async function refreshOwner() {
  const res = await fetch(AUTH + '/me');
  const data = await res.json();
  document.body.classList.toggle('is-owner', data.logged_in);
  loginMsg.textContent = data.logged_in ? 'Ви увійшли як ' + data.login : '';
}

loginForm.addEventListener('submit', async function (event) {
  event.preventDefault();
  const res = await fetch(AUTH + '/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      login: document.getElementById('f-login').value,
      password: document.getElementById('f-pass').value
    })
  });
  document.getElementById('f-pass').value = '';
  if (res.ok) {
    await refreshOwner();
  } else {
    loginMsg.textContent = 'Невірний логін або пароль';
  }
});

logoutBtn.addEventListener('click', async function () {
  await fetch(AUTH + '/logout', { method: 'POST' });
  await refreshOwner();
});

refreshOwner();
</script>

cd ~/app
git status --short
git add auth.py set-password.py main.py project.yaml .gitignore
git commit -m "auth: вхід за паролем, POST і DELETE лише для власника"
git push origin main

git log --all --oneline -- .env

curl -s -o /dev/null -w "GET  %{http_code}\n" http://91.219.61.4/u/bohdan.g9/api/habits
curl -s -o /dev/null -w "POST %{http_code}\n" -X POST http://91.219.61.4/u/bohdan.g9/api/habits \
  -H "Content-Type: application/json" -d '{"title":"сусід","days":1}'

Що перевіряє автоматика

Чотири критерії заняття 07, усі чотири перевіряє програма. Перевірка запускається за розкладом, тому відмітка в кабінеті з’являється не в ту саму секунду, коли ти виконав команду. Адреси ендпоінтів програма бере з project.yaml, а назву таблиці власника й поле з паролем — із розділу auth.

Домашнє завдання

# Що я перевіряв

## Спроба 1. Переглянути список без входу
Що робив: відкрив http://91.219.61.4/u/bohdan.g9/ у приватному вікні.
Відповідь сервера: GET /api/habits — 200, список видно.
Висновок: так і має бути, читання відкрите для всіх.

## Спроба 2. Натиснути «видалити», прибравши стиль через F12
Що робив: ...
Відповідь сервера: DELETE /api/habits/4 — 401.
Висновок: ...

cd ~/app
git add SECURITY.md
git commit -m "SECURITY: чотири спроби доступу без входу та відповіді сервера"

cd ~/app
/opt/club/venv/bin/python set-password.py
sqlite3 ~/data/app.db "SELECT COUNT(*) FROM owner;"

Якщо щось не працює

Служба не запускається після підключення auth.py

systemctl --user status club-api показує failed. Причина завжди в останніх рядках журналу:

journalctl --user -u club-api -n 30

• RuntimeError: У файлі ~/app/.env немає рядка SESSION_SECRET — файл .env не створився, порожній або лежить не в ~/app. Перевір: cat ~/app/.env. Файл прихований, у звичайному ls його не видно, потрібно ls -a ~/app.
• ModuleNotFoundError: No module named 'auth' — файл названо інакше або лежить не поруч із main.py. Обидва мають бути в ~/app.
• ModuleNotFoundError: No module named 'bcrypt' — служба запускається не тим Python. Перевір, що бібліотека є в спільному оточенні: /opt/club/venv/bin/python -c "import bcrypt; print('ok')". Якщо й тут помилка, скажи викладачеві: бібліотеки в це оточення ставить адміністратор, самому нічого встановлювати не треба.
• IndentationError — збилися відступи під час вставляння коду в nano. Усередині функції рівно чотири пробіли, змішувати пробіли з табуляцією не можна.

Вхід через форму проходить, але наступний POST усе одно 401

Кука видана, але не повертається назад. Відкрий F12, вкладку Application (у Firefox — Storage), розділ Cookies. Якщо club_session там є, дивись його стовпець Path.

Найчастіша причина — у COOKIE_PATH написано не те. Значення має точно збігатися з адресою сторінки: /u/bohdan.g9/, зі своїм логіном і з косими рисками з обох боків. Якщо там лишилося bohdan.g9 зі зразка, кука зберігається під чужий шлях, і до запитів твого сервісу браузер її не додає.

Якщо куки в списку немає взагалі, подивись у вкладці Network відповідь на /api/login: чи є в ній заголовок set-cookie. Якщо заголовка немає, у коді ендпоінта login немає аргументу response: Response або рядка response.set_cookie(...).

curl каже 401 на вхід, хоча пароль правильний

Перевір по черзі три речі. Перша — чи є взагалі запис у базі й чи той у ньому логін:

sqlite3 ~/data/app.db "SELECT id, login FROM owner;"

Логін має збігатися символ у символ із тим, що ти надсилаєш, — без пробілів на кінці й з тією самою крапкою перед номером групи.

Друга — чи справді в базі хеш:

sqlite3 ~/data/app.db "SELECT password_hash FROM owner;"

Рядок має починатися з $2b$12$ і мати 60 символів. Якщо там текст пароля, запис робили не через set-password.py.

Третя — чи не помилився ти в самому паролі. Перевір його окремо, без сервісу:

cd ~/app
read -s -p "Пароль: " PW; echo
PW="$PW" /opt/club/venv/bin/python -c "
import os, bcrypt
from db import query
row = query('SELECT password_hash FROM owner')[0]
print(bcrypt.checkpw(os.environ['PW'].encode(), row['password_hash'].encode()))
"
unset PW

PW="$PW" перед командою передає значення тільки цьому запуску Python і нікуди більше. Має надрукуватися True. Якщо False — пароль інший, ніж ти думаєш.

Простіше й надійніше — просто перезаписати пароль скриптом set-password.py ще раз.

Секрет потрапив у коміт

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

1. Замінити секрет. Старий вважай відомим стороннім, він більше не секрет. У .env може бути й інше, крім SESSION_SECRET, тому файл не перезаписуємо цілком, а міняємо в ньому один рядок:

cd ~/app
touch ~/env.new
chmod 600 ~/env.new
grep -v '^SESSION_SECRET=' .env >> ~/env.new
/opt/club/venv/bin/python -c "import secrets; print('SESSION_SECRET=' + secrets.token_hex(32))" >> ~/env.new
mv ~/env.new .env
cat .env
systemctl --user restart club-api

grep -v переписує в новий файл усі рядки, крім старого SESSION_SECRET; далі туди дописується новий ключ, і новий файл стає на місце старого. Проста команда ... > .env з однією кутовою дужкою стерла б решту рядків .env разом зі старим ключем.

Після заміни всі раніше видані куки перестають діяти — доведеться увійти заново. Так і має бути.

2. Прибрати файл з історії. Якщо він потрапив тільки в останній коміт:

git rm --cached .env
git commit --amend --no-edit

--cached прибирає файл з-під нагляду git, не видаляючи його з диска. --amend переписує останній коміт замість того, щоб робити новий.

Якщо цей коміт ти вже відправляв на сервер командою git push origin main (крок 12), то після --amend звичайний git push сервер відхилить: на сервері лежить попередня версія цього коміта, і git не замінює її мовчки. Тоді потрібно:

git push --force origin main

--force велить серверу взяти твою версію історії замість тієї, що в нього збережена. Робити так можна лише у своєму репозиторії й лише коли з ним більше ніхто не працює.

Якщо коміт із .env глибше в історії, треба пройти по всіх комітах:

FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch --force --index-filter \
  "git rm --cached --ignore-unmatch .env" --prune-empty -- --all
rm -rf .git/refs/original
git push --force origin --all

Команду filter-branch сучасний git вважає застарілою. Без рядка FILTER_BRANCH_SQUELCH_WARNING=1 він спершу друкує довге попередження й чекає близько десяти секунд, перш ніж почати роботу; це не зависання, але з цим рядком ні попередження, ні паузи не буде.

Команда переписує історію, тому номери всіх комітів зміняться. Роби її лише у своєму репозиторії й лише коли впевнений, що .env справді там є. Після цього ще раз перевір: git log --all --oneline -- .env — команда має нічого не вивести.

Сторінка показує кнопки гостю або ховає їх від власника

Відкрий F12, вкладку Network, знайди запит me і подивись його відповідь.

Якщо там {"logged_in": false}, а ти щойно увійшов, — проблема в куці, дивись пункт про 401 після входу вище.

Якщо відповідь правильна, а кнопки все одно не такі, як треба, справа в класі. Перевір три речі: клас only-owner справді стоїть на формі додавання; рядок del.classList.add('only-owner'); додано в блок із заняття 05; у стилях є всі три правила — .only-owner { display: none; }, body.is-owner .only-owner { ... } і body.is-owner form.only-owner { ... }. Якщо в консолі (вкладка Console) є рядок Cannot read properties of null, код не знайшов елемент: id у розмітці написано інакше, ніж у getElementById.

sqlite3 пише «no such table: owner»

Таблиця не створилася або створилася в іншому файлі бази. Подивись, що взагалі є в твоїй базі:

sqlite3 ~/data/app.db ".tables"

Якщо owner у списку немає, повтори крок 3 практики й уважно прочитай, що відповість команда. Якщо база називається інакше, дивись project.yaml, розділ database, поле file: db.py бере шлях саме звідти, тобто ~/data/ плюс ця назва.