Как стать автором
Обновить

Комментарии 19

Если про Retry-After я узнал далеко не сразу, то Authorization встречается довольно часто, и странно слышать, что про него может не знать миддл-бэкенд разраб. Даже если вы сами не пишете апи, то тот же Bearer-токен встречается относительно часто в сторонних апишках, который как раз в этом заголовке и передается

UPD: да Basic тоже встречается не то чтобы редко

И тем не менее, согласен с автором статьи, что многие API (в том числе и в банках), используют какие-то свои заголовки для передачи авторизационных параметров.

И в чем же это так ужасно?

Да, в целом, не сказал бы что это прям ужасно, но все-таки хочется видеть какое-то единообразие.
Плюс в некоторых языках (библиотеках) есть готовые хелперы для работы с заголовком Authorization (и не только), что упрощает код и минимизирует шанс ошибиться как в формате, так и в названии самого заголовка. Когда же работаем с кастомным заголовком, то ничего подобного, естественно, нет.

Ужасно это может быть только, если вы сохраняете трафик каким-нибудь HttpWatch для коллеги, и он увидит ваш пароль вместо звёздочек. Просто потому, что ваш инструмент не знал, какой заголовок оказался секретным.

Статья написана исключительно с целью прорекламировать свою контору. Ценность если и несёт, то для совсем зелёного джуна. Засилье корпоративных аккаунтов на Хабре в последние годы делает совершенно невозможным его чтение, всем нужно рекламировать и продавать какую-нибудь дрянь.

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

А ещё, видимо, мало кто знает что заголовки могут дублироваться по имени. Часто вижу как заголовки собирают в dict..

И иметь два заголовка Authorization - это нормально. Например, Basic может на nginx отсекать ботов, а в приложении уже логика проверяет пользователя по базе.

Коммент оказался для меня полезнее статьи. Не знал о таком трюке для отсекания ботов. Идея классная

IMO, веб-разработчики не знают про заголовки HTTP потому, что в принципе не понимают, что такое HTTP. Если изучить не отправление токенов в заголовках для решения тестовых заданий, а саму суть HTTP-протокола, зачем он нужен и с чем его едят, то большинство вопросов исчезнут (= эти вопросы будут выглядеть как гугл необходимых хедеров в твой запрос).

Т.е. вся статья рассказывает о 2х заголовках и помещаеться на лист А4?
Мощно однако..

Было бы неплохо услышать про полезность Cache-Control: public в современном вебе, где всё за tls...

До https может быть инфраструктура балансировщиков.

Только вот хедеры не работают с web-socket и приходится этот токен добавлять в параметры

У вебсокетов тоже есть хидеры.

О чем статья, если не секрет? Откровенно ожидал узнать для себя что то новое. Не вышло.

Заголовки авторизации используются сейчас очень часто. Кеш - аналогично гуглится первой ссылкой на какой нибудь so.

Единственное что хорошо - accept. С другой стороны - а как часто он на самом деле потребовался? При работе с некоторым апи мы точно знаем что нам для него надо и можем легко подстроиться под него заранее. Любой адекватный апи давно работает с джсоном и только с ним. Да даже всякие ардруины, которым заголовок может реально понадобится, например для какого нибудь XML(предположим) - умеют в json и с огромным успехом чудес перезагрузок операторов умеют в большое удобство при работе с json.

Про Retry-After давно не слышал. Хотя в университете про HTTP и его заголовки очень даже рассказывали (и даже просили написать HTTP-сервер).

А вот про Authorization не со всем соглашусь - бывает, что нужно всю информацию, требуемую для запроса, положить в URL. Например - токены доступа по ссылке (когда нужно что-то расшарить людям, которым известна ссылка, по типу документов в Google Drive). Потому в каждом случае надо отдельно разбираться.

А ещё, раз уж про авторизацию заговорили, можно вспомнить Basic HTTP Auth, для которого в частности имя пользователя и пароль можно задавать прямо в URL: <scheme>://<user>:<password>@<host>/<path>. И это даже вполне себе работает.

(там, где я учился, определённо, так и было)

Учился, ага. Автор оригинала — женщина.

Зря минусуете человека, я автору на день раньше отписался и по этому поводу тоже -- ноль реакции.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий