Текущий пользователь как dependency

Бронирование от имени пользователя

Свяжите новую бронь переговорной с учётной записью, найденной по проверенному JWT. Если токена нет, он недействителен или соответствующего пользователя нет в базе, откажите в создании брони.

Владельцем должен стать найденный пользователь, независимо от переданного клиентом user_id. Сохраните прежние проверки комнаты, времени и пересечений. При отказе существующие записи не меняются; при успехе появляется только новая бронь с правильным владельцем.

Что уже дано

Это самостоятельная уменьшенная лаборатория, а не миграция полного auth_owned_demo. В видимом файле уже даны FastAPI app, SQLAlchemy-модели User(id, token_subject), Room(id, name, capacity), Booking(id, room_id, user_id, starts_at, ends_at), Settings и зависимости БД, схемы и работающие операции с комнатами/бронированиями. User.id — integer FK, token_subject — постоянная строка JWT sub. Здесь нет регистрации, login и парольных операций; настоящие учебные User заранее сохранены в SQLite, а диагностический issuer подписывает настоящие JWT. Проверка get_current_user не подменяется.

Перед видимым файлом переходник создаёт принадлежащую лаборатории временную папку и задаёт DATABASE_URL (str) для её SQLite-файла и ROOMLY_DEMO_KEY (str, искусственный начальный ключ). Эти имена доступны в том же namespace. Служебная подготовка может заменить Settings и записи тестовой БД. Ни .env, ни реальный пользовательский файл БД не требуются.

Публичный переходник вызывает настоящий TestClient(app) в процессе приложения и передаёт скрытой проверке JSON статуса, тела и заголовков. Отдельная SQL Session читает сохранённые строки, в том числе user_id, которого нет в BookingOut. JWT выпускаются настоящим PyJWT для задаваемых диагностикой claims/ключей. Код ожидаемых ответов не находится в переходнике. Диагностика также вызывает get_current_user(credentials, db, settings) с настоящими HTTPAuthorizationCredentials или None и собственной Session; порядок трёх аргументов сохраните. Проверяется возврат SQL User либо HTTPException401. Изменять переходник и писать диагностические функции не нужно.

Что нужно сделать

Реализуйте get_current_user по уроку: HTTPBearer(auto_error=False), доверенный HS256 и settings.secret_key, обязательные exp/sub, действительный срок, строковый sub и поиск существующего User по token_subject. Отсутствующие или недействительные credentials, неизвестная учётная запись дают401 с WWW-Authenticate: Bearer; используйте понятный detail. Подключите get_current_user через Depends к POST /api/rooms/{room_id}/bookings и сохраните владельца из возвращённого User. JSON user_id не выбирает владельца; лишнее поле BookingIn игнорируется.

Не меняйте предоставленные модели и поведение остальных маршрутов. GET/POST /api/rooms остаются публичными; name имеет2–60символов, capacity — целое1–50. GET /api/rooms/{room_id}/bookings публично возвращает список по id. POST брони с действительным токеном сохраняет ровно одну строку и возвращает201 с id, room_id, starts_at, ends_at в UTC, без владельца и секретов. Отсутствующая комната —404/detail Room not found; пересечение в одной комнате —409/detail Booking conflict. Границы aware, ends_at позже starts_at; нарушения дают422. Соседние интервалы допустимы. Отказ не меняет существующие SQL-строки; успешное создание не меняет остальные записи.

Действительный Bearer позволяет действовать от имени своей учётной записи; это упражнение не защищает от кражи действительного токена. Имена обработчиков и конкретный синтаксис SELECT не фиксируются. Сохраняйте get_current_user как зависимость и готовое управление Session.

Ввод и вывод

stdin не используется. Печатать через print в stdout ничего не нужно. После выполнения файла проверяющая система обращается к верхнеуровневому app: публичный переходник вызывает TestClient внутри процесса приложения и передаёт результат скрытой проверке. Запускать Uvicorn, сеть, клиентский скрипт или pytest не требуется.