🐍 Python · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Сложный ·

Веб-приложения и API на Python

Сопоставляет маршруты, валидацию, зависимости, авторизацию и обработку ошибок. Здесь проверяется перенос знания на новый код: вопросы распределены между шкалами «HTTP и маршруты», «Валидация», «Авторизация» и «Обработка ошибок». Все задания рассчитаны на CPython 3.12; отличия других реализаций или версий учитываются только там, где это прямо оговорено.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Версия: CPython 3.12. Выберите один ответ из четырёх. На 20 вопросов отведено не меньше 40 минут; сравнивайте HTTP-контракты, границы валидации, права доступа и поведение при сбоях. После завершения вы увидите общий процент, четыре тематические шкалы и объяснение каждого ответа.

Вопрос 1 из 20

Почему GET не должен незаметно удалять или оплачивать объект?

GET могут автоматически повторить клиент, кэш или робот Параметры GET часто видны в адресе, но это не определяет безопасность метода GET поддерживает коды ошибок, но должен оставаться безопасным по смыслу Часть клиентов не отправляет тело GET, хотя это не главная причина

Вопрос 2 из 20

Что даёт отдельная модель входных данных?

Проверку формы и ограничений до вызова предметной операции Проверку существования адреса и уникальности записи в базе Шифрование полей модели перед передачей обработчику Создание пользователя без отдельной функции маршрута

Вопрос 3 из 20

Где безопаснее передавать bearer-токен?

В имени cookie без значения, рассчитывая на серверную сессию В теле ответа на запрос входа и затем в открытом виде в каждом запросе В заголовке `Authorization` по TLS, не в URL В параметре URL, ограничив срок жизни токена

Вопрос 4 из 20

Как обработать неожиданную ошибку на границе API?

Скрыть исключение и не оставить записи для расследования Преобразовать любую ошибку в успешный ответ 200 Вернуть клиенту полную трассировку для самостоятельной отладки Понятно отобразить ожидаемую ошибку, неожиданную скрыть и записать

Вопрос 5 из 20

После успешного создания заказа API возвращает представление созданного ресурса и его адрес. Какой HTTP-статус естественен для такого ответа?

201 Created с данными или адресом ресурса 204, но с обязательным телом 301 Moved Permanently 404 Not Found

Вопрос 6 из 20

Чем авторизация отличается от аутентификации?

Авторизация устанавливает личность, а аутентификация выбирает HTTP-метод После аутентификации пользователь получает все доступные системе права Аутентификация устанавливает личность, авторизация проверяет право Оба термина описывают один шаг проверки учётных данных

Вопрос 7 из 20

Почему интерактивный режим отладки веб-приложения нельзя оставлять в открытом выпуске?

Подробная страница ошибки безопасна, если маршрут доступен только после аутентификации пользователя Отладчик может раскрыть код, окружение и внутренние данные, а интерактивная консоль — дать выполнение команд Достаточно отключить вывод traceback в ответе, оставив интерактивный отладчик доступным Риск исчезает при работе через TLS, потому что содержимое страницы ошибки шифруется в пути

Вопрос 8 из 20

Обработчик сам создаёт сервис и репозиторий в каждой ветви. Какое проектное решение упростит управление и подмену зависимостей?

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

Вопрос 9 из 20

Что на самом деле делает CORS?

Проверяет предметное право пользователя на запрошенный объект Шифрует токен между браузером и сервером вместо TLS Разрешает браузеру читать ответы с указанных источников Блокирует обращения к API из серверных клиентов и командной строки

Вопрос 10 из 20

Как хранить пароль пользователя?

Зашифровать пароль постоянным ключом и показывать администратору Записать пароль в журнал для восстановления Сохранить обычный SHA-256 без соли Медленный солёный хеш, проверяемый API алгоритма

Вопрос 11 из 20

Почему подпись JWT не означает шифрование содержимого?

JWT хранится только в серверной базе и не передаётся клиенту Подпись удаляет служебные и пользовательские поля из токена Подпись защищает целостность, но не скрывает payload Разделение токена точками само включает шифрование содержимого

Вопрос 12 из 20

Повторный POST после сетевого тайм-аута может создать второй заказ. Какое исправление сделает операцию идемпотентной?

При каждом повторе формировать новый ключ запроса Повторять запрос, если его тело полностью совпадает с предыдущим Атомарно распознавать повтор по стабильному ключу идемпотентности После успешной записи возвращать ошибку, чтобы клиент не повторял запрос

Вопрос 13 из 20

Внутри `async def` маршрута выполняется обычный синхронный вызов `requests.get(...)`. Какая операция перестаёт отдавать управление циклу событий?

Параметр `timeout` делает вызов неблокирующим, поэтому остальные корутины продолжают работу `requests.get` удерживает поток цикла событий до завершения синхронного сетевого вызова Обычная функция становится ожидаемой операцией, потому что вызвана из тела `async def` Блокируется только текущая корутина, а цикл автоматически переносит `requests.get` в пул потоков

Вопрос 14 из 20

Как защищать загрузку файлов?

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

Вопрос 15 из 20

Что не так с проверкой, которая подтверждает вход пользователя, но не сверяет право на конкретный заказ?

Проверен вход в систему, но не право на конкретный заказ Достаточно убедиться, что заказ существует и пользователь вошёл Проверка должна выполняться до чтения `order_id` из маршрута Объект пользователя нужно преобразовать в строковый идентификатор

Вопрос 16 из 20

Зачем ограничивать частоту запросов?

Чтобы отказаться от очередей и ограничений на стороне зависимостей Чтобы после превышения лимита все ответы можно было кэшировать Чтобы сдерживать злоупотребление ресурсами по устойчивому ключу Чтобы ограничение частоты заменило проверку личности клиента

Вопрос 17 из 20

Почему пагинация только через большой OFFSET со временем становится проблемной?

База всё дольше пропускает строки перед страницей, а вставки между запросами сдвигают позиции Достаточно сортировать по неуникальному времени создания, чтобы страницы больше не смещались Индекс полностью устраняет стоимость любого OFFSET и стабилизирует страницы при вставках Проблема только в размере JSON-ответа; сама выборка с большим OFFSET не дорожает

Вопрос 18 из 20

Как не раскрыть существование чужого закрытого объекта?

Сначала найти объект по идентификатору, вернуть 403 для чужого и 404 только для отсутствующего Отбирать объект сразу вместе с условием доступа и одинаково отвечать 404 при отсутствии результата Вернуть 200 с пустым телом, если объект существует, но принадлежит другому пользователю Всегда возвращать 403, даже когда такого идентификатора в системе нет

Вопрос 19 из 20

Что должен показывать liveness, а что readiness?

Liveness проверяет процесс, readiness — готовность к трафику Обе проверки должны строить тяжёлый отчёт о всех зависимостях Liveness проверяет учётные данные пользователя перед ответом Readiness должна отвечать успехом даже при обязательной недоступной базе

Вопрос 20 из 20

Как поддержать изменение контракта без внезапного разрушения клиентов?

Ввести версию, период совместимости и объявленный порядок прекращения поддержки Поддерживать две версии бессрочно, не объявляя срок прекращения старой Выпустить новый контракт и сразу удалить старый маршрут после первого успешного запроса Изменить старый контракт на месте и считать заголовок `User-Agent` признаком готовности клиента

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу