Ошибка 403 из Azure только в определенной конечной точке с определенной версией API
Мы разработали приложение веб-API службы промежуточного программного обеспечения в .NET 6 с несколькими конечными точками и развернули его в Azure. Мы получаем странную ошибку с конечной точкой, реализующей метод POST.
Если мы изменим версию конечной точки с v2.1 на v3, Azure вернет ошибку http 403 — она отлично работает в локальной среде.
Подведем итоги:
{{Baseurl}}/bookings/api/v2.1/checkout/nexi -> Status Code: 200 Ok
{{Baseurl}}/bookings/api/v3/checkout/nexi -> Status Code: 403 Forbidden
В контроллере мы обновили только версию, других изменений нет.
Как возможно, что Azure остановит запрос на версию API V3? Все конечные точки, кроме этого, работают отлично.
Мы выяснили, что проблема заключалась в объекте в запросе, но до сих пор не понимаем, почему это проблема только с версией v3 конечной точки.
Спасибо за ваш ответ. Только эта конечная точка имеет проблему в V3, но я не пытался вызвать другие конечные точки с запросом, из-за которого инкриминируемая конечная точка выдает ошибку 403. ko означает, что запрос не дал ожидаемого ответа.
Я понимаю. Вам нужно будет вызвать, о котором я просил, чтобы получить дополнительную диагностику. В противном случае есть риск, что вы не получите особой помощи от сообщества. А еще вы рискуете получить избиение (нередко неоправданно жесткое). Насколько я могу предположить, исходя из ограниченной информации, в вашей локальной настройке что-то настроено иначе, чем обычно. Я опубликую ответ, но не уверен, что нахожусь на правильном пути.
Ответы 1
Отказ от ответственности Доступна лишь ограниченная информация, и на данный момент нет диагностики того, как другие конечные точки будут вести себя с измененным маршрутом. Следовательно, все нижеизложенное является лишь догадкой и вполне может быть совершенно неуместным и вводящим в заблуждение.
Я отмечаю две вещи. Во-первых, кажется, что в вашей локальной системе он ведет себя ожидаемо (и, насколько я знаю, в общем случае то же самое происходит и на сервере). Таким образом, ваша конкретная среда хостинга здесь является подозрительной.
Во-вторых, необычный код статуса: 403 ko. Это дает мне ощущение вонючей концепции, потому что это должно быть 403 Запрещено, что означает, что пользователь идентифицирован (вошел в систему, следовательно, нет 401 Неавторизованный).
Итак, я **предполагаю*, что тот, кто настраивал ваш хостинг (инфра-чуваки, DevOps или кто-то, кто управляет серверной средой у вас дома), сделал ляп и каким-то образом помешал пересылке определенных шаблонов в приложение.
Это может быть связано с настройками балансировщика нагрузки, оркестровкой докеров, конфигурацией шлюза и, возможно, кучей других странных мест, о которых разработчик должен знать, но с которыми он неохотно будет суетиться.
Есть ли у вас доступ к этим свойствам вашей серверной среды? Или, по крайней мере, можете ли вы поговорить с кем-нибудь, кто это знает?
Я бы начал изучать шлюз Azure и его перенаправление трафика.
Извините, я не совсем ясно выразился по поводу статуса. Статус: 403 Запрещено Microsoft-Azure-Application-Gateway/v2.
@oiradIta Приятно слышать. Однако, если быть придирчивым: код статуса — 403 Forbidden, а не 403 Forbidden Microsoft-Azure-Application-Gateway/v2. Кроме того, то, что вы только что написали, еще больше предполагает, что в шлюзе может быть конфигурация, которая соответствует регулярному выражению, например .*/v2/.* или, возможно, .*/v[0-9]*/.*, что делает ваш новый путь (содержащий точку и/или не дословно v2) отклоненным. Чтобы подтвердить эту теорию, попробуйте конечную точку с /v3/. В любом случае, похоже, что-то с конфигом шлюза. Можете ли вы поделиться более подробной информацией об этом?
@oiradIta Есть какие-нибудь новости о ситуации?
Извините за мое отсутствие, да, проблема решена. Я связался с администратором серверной среды Azure, и выяснилось, что для URL-адреса {{Baseurl}}/bookings/api/v2.1/checkout/nexi возникло исключение RequestLenght, чтобы запрос мог пройти. Мы также установили исключение для URL-адреса v3, и теперь оно работает отлично. Большое спасибо за помощь мне
Рад слышать. Так что, в конце концов, я не за горами ошибся в своих интуициях. Не стесняйтесь отметить ответ как принятый и/или проголосовать за него, если он вам понравился.
403 означает, что пользователь вошел в систему, но ему не разрешено выполнять определенные действия, как вы наверняка знаете. Что такое «Ко» в вашем вопросе (после ссылки)? Я также хотел бы выяснить, не начинают ли другие конечные точки выходить из строя таким же образом, когда вы меняете URL-адрес на версию 3. Возможно, у вас есть шлюз, балансировщик нагрузки или что-то подобное, которые каким-то образом не допускают этот шаблон.