Правильное поведение общедоступного ресурса api, запрошенного с использованием просроченного токена авторизации
Я знаю, что уже есть много вопросов 401 против 403, но в моем случае это нет.
Я спрашиваю:, что в идеале должен делать сервер, если запрошенный ресурс api общедоступен (без авторизации требовать), но запрос включает заголовок авторизации с токеном, который либо неверен, либо просрочен?
Мои рассуждения таковы: теоретически сервер может проигнорировать его и ответить, но это кажется очень плохой идеей. Например, бизнес-логика обработки запроса может отличаться в зависимости от аутентификации или нет. Клиентское приложение также должно получать мгновенную обратную связь, что оно должно повторно аутентифицироваться, и не только тогда и когда оно достигает закрытой конечной точки.
Я думаю, что быть "плохо аутентифицированным" и, следовательно, неявно рассматриваться как анонимное, является неопределенным и сбивающим с толку поведением.
Итак, подведем итоги. Оправдано ли использование 400 в данном конкретном случае или существует какая-то другая общепринятая практика?
Ответы 1
Если сам этот API общедоступен, а под общедоступным вы имеете в виду, что он не требует какой-либо аутентификации для пользователя, почему вы вернете пользователю ответ с неверным запросом? Подумайте, имеет ли это смысл, если он общедоступен, вы можете обойти любые проверки и сохранить некоторую обработку на сервере.
Связанные с этим:
«но это кажется очень плохой идеей. Например, бизнес-логика обработки запроса может отличаться в зависимости от аутентификации или нет».
Я думаю, что в этом случае вам следует изменить сам API, чтобы он требовал аутентификации и не принимал любого неавторизованного пользователя или пользователя с просроченным токеном.
Извините, если я не сильно помог, но это мое мнение по этому поводу. Если он плохо аутентифицирован, значит, это не публичный API, верно? Общедоступный API будет отвечать в любом сценарии, может иметь только некоторые ограничения на запросы по секундам.
В любом случае, я хотел сказать, что запрос с недействительной авторизацией действительно плохой / неработающий. Например, клиент предполагает, что он аутентифицирован как администратор, но api не может ответить так, как предполагает клиент, потому что на этом этапе авторизация недействительна. Но ответ только общедоступными данными может быть (и, вероятно, это) чем-то совершенно отличным от того, что ожидает клиент. Вот почему я думаю, что api должен отвечать 400 (или другим плохим типом кода).
Я бы не согласился. Скажем, у меня есть CMS, в которой и интерфейс, и сервер являются SPA. Если у вас нет каких-либо конкретных требований, которых у меня нет, имеет смысл создать один api, обслуживающий оба приложения. Вот и все - для некоторых конечных точек требуется авторизация, для некоторых - нет, а некоторые различаются по поведению в зависимости от авторизации. Например, если вы аутентифицированы как администратор, вы получаете некоторые закрытые данные о сообщениях, пользователях, которых анонимные пользователи никогда не должны видеть.