FastAPI: авторизация и отмена только своей брони

Отмена своей брони

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

После успешной отмены бронь должна исчезнуть из базы, а остальные записи — сохраниться. Повторная отмена того же бронирования возвращает ответ об отсутствии.

Что уже дано

Это самостоятельная лаборатория на основе уменьшенного API из 32. Весь готовый код находится в редакторе: реальные SQLAlchemy/SQLite, User с integer id и постоянным token_subject, Room с name/capacity, Booking с user_id, Settings, рабочая get_current_user с проверкой настоящего JWT, создание и публичное чтение комнат/броней. Удаление — единственный TODO. В лаборатории нет регистрации, login или парольных операций: учебные User уже сохранены, а диагностический issuer подписывает настоящие JWT. Это не подмена паролей и не миграция полного проекта курса.

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

Публичный переходник исполняет настоящие HTTP-запросы через TestClient(app), передаёт JSON-наблюдения и читает SQL-строки отдельной Session. Готовая get_current_user действительно проверяет JWT и ищет User; она не заменяется fake dependency. Диагностика также может вызвать готовую get_current_user(credentials, db, settings) с реальными аргументами. Переходник и ожидаемые ответы писать не нужно.

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

Реализуйте DELETE /api/bookings/{booking_id}. Используйте готовую зависимость get_current_user и существующее Booking.user_id. Без действительных credentials ожидается 401 с WWW-Authenticate: Bearer. Для авторизованного пользователя отсутствующая бронь даёт 404 с detail="Booking not found", чужая — 403 с detail="Forbidden" без любых изменений БД. Владелец удаляет только указанную запись, сохраняет удаление и получает 204 с пустым телом. Повторная отмена возвращает 404. Остальные брони, комнаты и пользователи сохраняются; освободившийся интервал снова доступен. Query/body не выбирают пользователя.

Не переписывайте предоставленные аутентификацию, модели и остальные маршруты. GET/POST /api/rooms и чтение броней остаются публичными. POST /api/rooms/{room_id}/bookings защищён настоящим JWT и сохраняет проверенного владельца. Прежние ограничения name (2–60 символов), capacity (целое 1–50), aware-границ, UTC, ответы 201/404/409/422, список по id и неизменность после отказа сохраняются. Новых ролей, администратора, ограничений по времени отмены и скрытия существования чужой записи нет. Имя обработчика и конкретный способ SQL-удаления не фиксируются.

Ввод и вывод

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