Комментарии 20
Не используйте GET запросы для операций, изменяющих состояние. Многие веб-разработчики узнали это на собственном горьком опыте в 2005 году, когда был публично выпущен Google Web Accelerator. Это приложение прошло по всему контенту, для которого были назначены ссылки, что является законным для HTTP GET запросов, потому что они должны быть безопасными. К сожалению, многие веб-разработчики проигнорировали HTTP соглашение и разместили простые ссылки для «удалить» или «добавить в корзину» в своих приложениях. Начался хаос.
Одна из компаний посчитала, что их система управления контентом была целю повторяющихся атак, потому что все содержимое снова и снова удалялось. Позже они выяснили, что поисковой робот натолкнулся на URL административной страницы и прошел по всем ссылкам для удаления.
(цитирую по книге А.Фримена про ASP.NET MVC Framework)
Ох, кажется мне, могут прилететь минуса за довольно низкий технический уровень материала(
Ну например, что значит вот это?
"Просто не все бесплатные хосты пропускают Get запросы (Пару раз обжегся)."
Может быть не все бесплатные хостинг дают возможность использовать PHP? Без GET запроса то не запросить индексную страницу, а это в 95% случаев и требуется от хостингов.
Как уже правил но написали, лучше использовать POST для отправки данных, GET может иметь проблемы с кешированием.
Не никакой авторизации, тоже писали выше
Статья и подход на уровне, да нет тут никакого уровня, что-то склепали на коленке и оно заработало. На Хабре надо наоборот изучать качественные материалы, чтобы не городить подобное.
Зачем городить огород из костылей, если можно было использовать MQTT протокол с кучей проверенных реализаций, защитой канала, улучшенной работой в некачественных каналах, 2х сторонней связью и ещё кучей фишек?
Зачем городить огород из костылей, если можно было использовать MQTT протокол с кучей проверенных реализаций, защитой канала, улучшенной работой в некачественных каналах, 2х сторонней связью и ещё кучей фишек?
Я тоже очень люблю MQTT, но здесь похоже не тот случай. MQTT гораздо сложнее в реализации. Во-первых нужен брокер. Бесплатные все куда-то деваются и имеют кучу ограничений. Свой на бесплатном хостинге его не поднять, да и тоже требует каких то знаний. Во-вторых, сложность серверной части. Уж парой строк на PHP не обойтись.
С точки зрения быстрого старта новичка HTTP протокол совсем не плох. Хотя еще лучше какой ни будь Блинк использовать. За пять минут получаем красивое управление с телефона.
Бесплатные все куда-то деваются и имеют кучу ограничений.
Если вам не фильмы качать через него, а чисто для себя держать пару девайсов — амазоновский AWS IoT Core, кажись, выльется в пару баксов в год (на момент написания: 1 USD за миллион сообщений, 0.042 USD за одно устройство за календарный год круглосуточного онлайна, пинги бесплатно, реестр устройств, если нужен — 1.25 за миллион операций по килобайту).
cloud.yandex.ru/docs/iot-core/pricing
Но если сервис будет востребован, то в один прекрасный момент они поменяют тарифы. Или введут ограничение на размер, количество в час и пр.
А если не востребован, то прикроют лавочку.
Ну я бы сразу же смотрел в сторону ssl, так как могут был проблемы с его реализацией в esp
Далее, смотреть в сторону GET и POST, для поста есть несколько способов инкапсуляции данных, отправляемых на сервер (см. ContentType)
Можно локально поднять ngrok и настроить esp на отправку данных на него, а ngrok чтобы отправлял на сайт. Тогда можно будет посмотреть, что и как отправляет esp.
Здесь ужасно все, от реализации до безопасности. Почему этот пост имеет положительный рейтинг?
А потом мы удивляемся, чего это столько дыр и ботнетов на IoT устройствах.
Как-то не очень понимаю, зачем эта статья и нужна.
Открываем примеры к ESP 8266 в самой же Arduino IDE, там готовые примеры и Get, и Post, и не только HTTP.
Плюс не рекомендую использовать практику прямого указания параметров WiFi-точки, потому как код выложится куда-нибудь и пароль забудется внутри. Да и плюс если изменится точка доступа, придется перешивать. В качестве альтернативы предлагаю использовать WiFiManager.
То ли с модерацией что-то случилось, то ли весна близко…
А по теме — большая часть статьи — изобретение велосипеда и решение проблем, которых вообще бы не возникло, если бы взять одно из готовых решений. С т.з. железа — что-то со встроенным usb-uart типа NodeMCU, с т.з. прошивки — Tasmota, Espeasy или Esphome, с т.з. протоколоа — MQTT. Ну и совершенно непонятна конечная цель всех этих мучений.
Или не достигается?
ESP 8266: отправка данных на сайт методом Get запроса