Comments 13
Когда-то на хабре были хорошие технические статьи, а сейчас переводы статей для домохозяек.

А я понять не могу какую связь содержимое этой статьи имеет с её заголовком...

В http каждый запрос идеоматически не зависит от других. Это полезное во многих отношениях архитектурное свойство создает массу проблем при попытке отследить активности пользователей.

Время установки https соединения «на холодную» порядка 200ms, т.к. процесс обмена ключами не быстрый… Это довольно долго, по сравнению с http. Для того, чтобы уменьшить это время в ssl и tls был добавлен механизм сессионных ключей. Сайт.эффект в том, что теперь на сервере можно связвывать серию запросов гарантируя, что они пришли от одного клиента. h2 это способ решить ту же самую задачу, другим способом — завернуть всю сессию в одно соединение. На практике оба способа можно использовать вместе. Делает-ли это интернет более безопасным? Смотря для кого.
GET — идемпотентный метод, означающий, что независимо от того, сколько запросов вы отправите, вы не будете изменять состояние веб-сервера

Вы серьёзно?

На самом деле все примерно так и есть tools.ietf.org/html/rfc7231#section-4.2.2. Если сильно хочется можно придираться в цитируемой фразе к состоянию сервера. Так бывает, когда люди объясняют своими словами. Но на мой взгляд это больше похоже на придирку к словам.
Конечно, я докопался до «состояния» сервера и именно поэтому эту фразу и процитировал в своём комментарии. Нет, про состояние и идемпотентность всё ок, меня скорее зацепило, что это в абзаце про GET. В реальной жизни GET не более идемпотентный, чем тот же POST, и выкатывать в статье такие перлы обозначает сразу рассказывать людям определенную «полуправду». Оно то вроде и да… но нет. И кстати, это перевод и соответственно про «объясняют своими словами» здесь не уместно. Посмотрел в ориганале, там также. Просто надо такие моменты раскрывать шире, а не провозюкивать вилами по воде в статье про «безопасность» для самых маленьких. И да, основы HTTP настолько заезжены в этом мире, что я не понимаю зачем стоило брать и тащить на хабр вот эту статью, а не взять бы и не написать что-то свое с меньшим количеством воды и с большим количеством деталей и с разбором потенциальных инцендентов.
На заре карьеры сделал в админке удаление методом GET по ссылке ?action=delete. Мне казалось это решение безопасным. Через некоторое время клиент обнаружил отсутствие данных. Выяснилось, что какой то плагин браузера ходил по всем ссылкам, которые мог найти на странице. Поведение плагина было корректным. Так я открыл для себя удивительный мир архитектур http и rest. Рекомендую. Встречаются какие-то частные случаи, когда имплементация GET нарушает соглашения. Но это исключения, которые не заслуживают обобщений. В подавляющем большинстве случаев соглашения поддерживаются. Благодаря этому www продолжает функционировать.
Спасибо за рекомендации, но боюсь, что без них как-нибудь проживу. Давайте не размазывать тему и если идёт обсуждения протокола не переходить на частные случаи. HTTP это не архитектура, это протокол. В RFC про то, что он должен быть идемпотентным скорее указано в качестве рекомендации, потому что технически ограничить его использование по сабжу невозможно. Кроме страничек по HTTP в своременном мире отдают и различные API и встречаются даже публичные сервисы которые позволяют (в подавляющем большинстве) по GET менять состояние сервиса. Например, у меня сейчас открыта вкладка с бот-API Телеграма и в нём все действия можно осуществлять как POST'ом, так и (о боже!) GET'ом — как яркий пример — отправка сообщения. И даже если отправлять сообщения в Телеграме через POST, то это никак не повлияет на безопасность, так как в URL-секции указывается приватный TOKEN. И тут мы можем наблюдать, что и URL тоже может содержать приватные данные, да и вообще безопасность сервиса от выбора HTTP-метода никак не зависит. И я уж не буду упоминать всякие интернал-сервисы и всякие штуки, которые можно встретить в энтерпрайзных системах в которых то что не обязатольно, то точно не обязательно и все рекомендации отправляются лесом…
То, что вы описали про плагин это не атака и не недостаток GET'а, а скорее две столкнувшиеся беды — криворукая реализация и кривой плагин. То есть эта та ситуация где ты сам себе злой буратино и это скорее подтерждает мои слова, что фраза в этой статье некорректна и GET чего только не может. Про REST тут не имеет смысла ничего писать, потому что он не имеет отношения к статье и о его недостатках можно говорить не меньше чем о его достоинствах. Я ещё раз уточню раз вам не понятно, о том, что мне не понравилось в посте. Там написано описание метода протокола, а не рекомендации по его использованию и указано, что GET всегда идемпотентен, что не правда и это даже вы сами подтвердили своим опытом со страницей с delete-ссылками. И это не недостаток данного перевода, а недостаток статьи оригинала. И всё бы ничего, если бы не было указано в заголовке статьи слов «Web Security». А security как раз заканчивается там, где под её соусом подают недостоверную информацию и у людей появляется иллюзия её наличия. И если начинающий разработчик-домохазяйка начнёт юзать GET'ы, думая что они не могут менять состояния сервиса, прочитав информацию в данной статье-руководстве, то последствия могут быть самыми разными.

RFC дает рекомендации, чтобы не создавать и не наступать на грабли. Но это ни сколько не мешает их создавать или наступать на ровном месте. Незграмотность и самоуверенность это страшная сила.

В RFC самое важное это техническое описание протокола. Остальное там как правило подаётся в очень общих чертах и оставляет пространство для «творчества».
Вот в случае с Телеграм бот-апи это «неграмотность и самоуверенность»? Да и при чем тут грабли? Какие грабли? Аргументация какая-либо начнётся? Я вроде ещё в предыдущем комментарии старался вам объяснить, что выбор метода к безопасности не имеет отношения даже если один из них идемпотентный, а вы все про тоже, да потому же… И персональный мир с единорогами и ромашками заканчивается на этапе взаимодействия со сторонними сервисами в которых может встретиться всё что угодно. И кроме принятия на веру, что что-то плохо важно понимать почему и в каких ситуациях. Считаю диалог исчерпанным из-за отсутствия конструктивной критики.

Веб работает на соглашениях. Это вещи, которые подразумеваются по умолчанию. Идемпотентность дает такие плюшки как возможность выполнять запросы многократно без последствий и отдавать результаты из кеша. Это свойство используют браузеры, прокси серверы, поисковые системы и т.п. Оно позволяет обмениваться ссылками, так что каждый получит то же, что и вы.
Привычка смешивать GET и POST была популяризирована в php, что снижало порог входа. Позже подход многократно критиковался.
У разработчиков API, которое вы приводите в пример, вероятно были какие то свои мотивы для отклонения от стандартов, без объяснения которых я бы не стал тут показывать как эталон.

Да я же не против того, чтоб везде было как надо и хорошо. Я про то, что это не всегда так и иногда бывает даже наоборот, но при этом тоже не плохо :)
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

16 February 2002

Location

Россия

Employees

31–50 employees

Registered

14 September 2015