Comments 49
Отправка сообщений через get запрос? Почему не post?
Этот чат можно рассматривать как некую вспомогательную систему для локальной сети.
Но мне интересны отзывы, если кто-то будет пользоваться. Мне так и не удалось потестировать этот чат, допсутим с тремя десятками пользователей.
Лимитировать можно и post запросы на бэке
Лимитировать можно и POST запросы на фронте.
До первого скрипт кидди, умеющего в DevTools
Не понял. И как вы это реализуете если будет проверка и на фронте и на бэке?
А смысл лимитировать дважды? Сделали на бэке, все, задача выполнена.
Делать одну и ту же задачу дважды - раздувать кодовую базу и ловить потом баги.
Чтобы лимитировать длину сообщения
Что мешает это в POST сделать?
Когда я начинал писать, то мне показось проще ипользовать GET.
Можно переделать, если это кому-нибудь вообще нужно.
Посмотрел вот эту тему:
stackoverflow.com/questions/1872965/get-vs-post-in-ajax
Тут пишут, что GET кешируется и что через него не рекмендуют отправлять персональные данные.
Но чат открытый и авторизации не предполагает.
А про кеширование у меня самого вопрос: на что это может влиять?!
А про кеширование у меня самого вопрос: на что это может влиять?!
Например, на то, что повторно отправленный GET может не достичь сервера вообще.
Если текст запроса не изменился!
Но в случае с чатом хорошо это или плохо — под вопросом!
В случае нахождения в чате товарищей с гипеактивностью, посылающих по 20 одинаковых сообщений, то, может быть, хорошо.
Плохо то, что вы это никак не контролируете. Если вам нужен тротлинг — его нужно делать осознанно и специально. А полагаться на неизвестное поведение неизвестного числа посредников — плохое решение.
Ну и да, то, что человек каждый день приходит и пишет "привет", а со второго дня эти сообщения никому не доходят (а он думает, что доходят) — это тоже так себе решение.
Сейчас подумал: такой вариант невозможен:
"Ну и да, то, что человек каждый день приходит и пишет "привет""
Запись все равно попапает в БД. И соответственно человек видит в чате то, что он сам отправил или не видит, если есть проблемы. Иначе, если в чате не появилось его сообщения, то и в БД его не будет, и человек это сразу заметит. А если сообщение есть в БД, то его увидять остальные участники. В целом чат работает с повторными сообщениями. Видимо, я не полностью описал механизм чата. Последние сообщения проверяются по ID. Сам текст соообщений не сравнивается.
Смотрите. Вы отправили сообщение GET запросом и браузер старательно сохранил это в истории. Через час опять зашли в чат, а браузер подставил сохранённый URL и то же сообщение отправлено повторно.
Ещё проблема, что в разных браузерах количество допустимых символов у GET разное и использовать его для этой цели просто неправильно.
В чате даже были роли, а модерация и администрирование работала через команды.
Ух! Ностальгия!
Шел 2022. Чаты на WebSockets уже делают ученики на курсах от всяких инфоцыган, а разворачиваются запуском пары команд (поставить nodejs, запустить скрипт).
Но зачем делать легко и просто, правда?)
Первый файл в репе при попытке открыть падает с ошибкой 500. Ну, это не к вам претензия, а к GitFlic, но возможно, там какая-то дичь и он это не может запроцессить.
Readme.txt надо бы переименовать в md. Тогда описание вашей репы начнет индексироваться поисковиками, а люди смогут сразу увидеть описание проекта, без необходимости проваливаться внутрь.
Держать ЗИП файлы в репе это моветон. Для этого есть раздел релизы
открытое ПО предусматривает соответствующую лицензию. Будьте любезны, потрудитесь выбрать одну из доступных и подгрузить её в репо
А почему в репозитории весь код в zip??
Жаль что не на GitHub....
Чат похоже уже все.... или на хроме из под андроида не работает.
Не уверен что эта статья в формате Хабра. В личном бложике, но уж не здесь.. Ведь есть вероятность, что начинающие будут смотреть, читать и использовать сиё...
Из-за финального абзаца («Данная система является открытым ПО, разработанным в России.») больше похоже на стёб. Понятно, что код рабочий или может быть рабочим. Но такое огромное количество ошибок начинающих: код не имеет стилевого оформления, используются устаревшие возможности браузеров для которых есть современная замена работающая с лохматых версий, сохранение реквизитов соединения с базой данных в репозитории, куча require вместо автозагрузки классов... Я устал искать. Не делайте так в 2022 году.
Спасибо за комментарий.
Вы же понимаете, что весь код, который вы пишите сейчас на всех этих свеженьких сегодня технологиях и практиках через лет 10 будет в таком же положении, как и у автора.
Если его не трогать — да, будет. Но зачем его через 10 лет таким кому-то показывать? (ну, кроме археологического интереса)
Непрерывно переписывать все проекты на все самое современное это очень дорогое удовольствие. При этом проект может прекрасно выполнять все свои функции и нуждаться лишь в поддержке и некоторых доработках.
Согласен. Но этому есть объяснение: программисты хотят кушать тоже, а опубликованное ПО вообще может не приносить заработка.
Вдобавок есть постоянное движение (конкуренция) в сфере, по принципу всё течет, всё изменяется.
На этапе "некоторые доработки" может внезапно выясниться, что аккуратно поддерживать проект разумно современным было дешевле, чем делать доработку к технологиям, которые больше никем не поддерживаются.
Так, конечно, не всегда бывает, и это решение, которое каждый для себя принимает сам. Но к публикации это все отношения не имеет.
При всех минусах — это, наверное, лучший скрипт чата такого типа.
Если подытожить все сказанное.
Поддержку "Server-Sent Events" будет?
А какие бывают другиетехнологии кроме ajax и SSE?
По поводу устаревания технологий: мне думается, что это не про Ajax на ближайшую перспективу. Как мне кажется, эту технологию можно отнести к "прижившейся" технологии.
Добавлена версия для установки на Windows XP с AppServ 2.6.0 (PHP 6).
Ссылка в конце статьи, в обновлении.
Добавлена версия для установки на Windows XP с AppServ 2.6.0 (PHP 6)
Актуальные версии ОС поддерживаете, я посмотрю...
Я считаю себя линуксоидом или пользователем Linux, но XP вечен. Мы все это знаем.
Дело в не системе, конечно. Я так написал для понимания того, что чат будет работать и на других платформах, так как PHP переносимый язык. На XP чат протестирован мной с AppServ 2.6.0.
В общем, вероятно, работать будет даже на платформе Эльбрус.
Вышел OpenChatPhp-1.1