В отсутствие ответа, который фактически решает проблему, я подумал, что должен ответить тем, на котором я неохотно остановился.
Хотя технически правильно, что отсутствие действительных учетных данных может привести к в ответе 401/403 для ресурса это верно и для навигационной нагрузки. Если вы отвечаете 307 на перенаправление для аутентификации, вы уже подрываете это ожидание.
На практике важно то, что видит конечный пользователь: когда браузер пытается загрузить встроенный ресурс, но получает назад 307, он идет и выбирает страницу формы входа HTML, на которую он был перенаправлен. Поскольку это не ресурс изображения (или что-то еще ожидаемое), а также потому, что он изменил тип содержимого на что-то, что потенциально может быть вредоносным, современные браузеры блокируют его на основе CORB. Я не уверен, что делают старые браузеры, но я сомневаюсь, что они отображают HTML вместо img или любого другого элемента, указанного на странице. Результат net одинаков в обоих случаях - вместо встроенного ресурса пользователь видит неработающую ссылку.
Сравните это с нагрузкой, возникающей в результате действия навигации, когда браузер будет счастливо перенаправить и показать HTML форму входа, как и предполагалось. Это может быть немного затруднительно, если вы вставили страницу, которая будет перенаправлена на другую страницу, но мы уже получили X-Frame-Options: DENY в нашей форме входа в систему из соображений безопасности, чтобы в этом случае она не работала.
Таким образом, в отсутствие хорошего способа сделать это «правильно», вы можете просто выбрать перенаправление во всех случаях, и вы получите конечный результат, который, возможно, в порядке. Было бы гораздо приятнее, если бы сам HTTP имел более изящную интеграцию, например, возможность добавить перенаправление в ответе 401/403 и отправить браузеру «куда-то еще», чтобы получить токен Bearer обратно, но есть причины, по которым я не могу понять, почему это плохая идея.