Вопрос не относится на прямую к ИПБ, а скорее к логике

Зачем нужны ББ-коды?

 

Вот есть неплохой редактор: http://ckeditor.com/

Я его сейчас ковыряю. По умолчанию он все вставки через тулбар сразу же представляет в виде хтмл-разметки. Т.е., если я жму на смайлик, то в окне редактора я вижу не :smile: (как на форумах) а саму картинку (а если точнее, то я вижу <img src="ololo.gif">)

И так с любым форматированием. Выделил текст жирным - и тут же в редакторе, без всяких предварительных просмотров, видишь его жирным (на самом деле я вижу что-то типа <span style="text-style: bold">мой набраный текст</span>)

 

Ведь сами разработчики этого редактора CKEditor пишут:

It's a WYSIWYG editor, which means that the text being edited on it looks as similar as possible to the results users have when publishing it

 

И этот же редактор устроен так, что все вручную набраные теги он как бы экранирует, т.е. заменят всякие < > / - на соответсвующие хтмл-мнемоники. Т.е. вручну. пользователь не может писать любые хтмл-теги, которые ему вздумается. Точнее может, но они, после публикации, никак не повлияют на хтмл-разметку самой страницы. Они заэкранированы как-бэ.

Ведь это же отличная защита от внедрения своих скриптов на сайт, от калеченья разметки сайта.

 

И тут разработчики форумов решили, что правильные пацаны так не делают!!! Нужно вместо обычных хтмл-тегов вставлять какую-нибудь фигня, например [ b ] [ / b ] и уже на стороне серваре парсером разбирать всю эту байду (ее назвали бб-кодами) и заменять на обычные хтмл-теги. Внимание, вопрос: ЗАЧЕМ они все это делают, ЗАЧЕМ???

Если для защиты, то, как я писал выше, редактор CKEditor НЕ позволяет писать вручную какие угодно теги! Он их заэкранирует.

Если для защиты, то, как я писал выше, редактор CKEditor НЕ позволяет писать вручную какие угодно теги! Он их заэкранирует.

Бггг. Что, безусловно, помешает мне отключить в браузере JavaScript и понаписать в textarea любого HTML на свой вкус, включая скрипты и стили. Не говоря уже о формировании прямого POST-запроса с ними же. Полагаться в вопросах фильтрации контента на пользовательский JavaScript - прямой путь к взлому ресурса и забивке его посторонними скриптами и мусором.

 

1. Форумы появились значительно раньше всей этой ВЮСИВЮГни. IPB, например, появился в 2002 году - в год выхода Windows XP. Когда они существовали и развивались, у пользователей не было современных браузеров с повсеместно включенным JavaScript и стабильной поддержкой rte-ввода, и для набора постов был только один вариант - простое текстовое поле. Чтобы позволить форматировать текст, были придуманы BBCode, markdown и wiki-разметки. Чтобы упростить их применение, были придуманы панели с кнопками форматирования.

 

2. Эти три вида разметки позволяют 100% гарантировать, что пользователь сможет воспользоваться только теми видами html-конструкций, которые предусмотрел создатель ресурса, и ничего более. При этом разработчик сам выбирает, какие параметры и какое содержимое тегов может редактировать посетитель, а какие - нет. Так же с помощью данных разметок можно удобно реализовать сложные функции, вроде создания автоматического оглавления, боковых блоков, органичения прав доступа к контенту и т.д. Никакой визуальный HTML-редактор не позволит вам оформить всю википедию так аккуратно, как она оформлена с помощью викиразметки. Это вопросы надежности, аккуратности, удобства и безопасности.

 

3. С тех пор, как визуальные редакторы значительно развились, некоторые скрипты и ресурсы пробуют использовать чистый html для редактирования, написания, хранения и отображения пользовательских постов. Например, drupal последних версий по-умолчанию использует html-ввод и фильтрацию тегов в нем. Многие мало популярные CMS так же используют html. Но html - это всегда вопрос парсинга пользовательского ввода:

а) Практически невозможно создать такой парсер html, чтобы убирал все лишнее и опасное из html, быстро работал и при этом не портил разметку текста. И "CKEditor экранирует же" - не аргумент, когда мы говорим о ресурсе, доступ куда не ограничен строго домохозяками и далекими от IT людьми. Ярчайший пример - habrahabr.ru. У них используется html-ввод, и сайт несколько раз был взломан через обход фильтра html с внедрением JS, а в каждом 10-м комментарии поломаны ссылки или разметка и стоит примечание "парсер - олень с ушами".

б) Вторая проблема html - проблемы с кастомным функционалом. Если с bbcode все понятно - расширяем словарь кастомных тегов - и готово, то как добавить кастомный элемент в html-редакторе? Как должен выглядеть и отображаться в визуальном редакторе, например, блок для геренации автооглавления? Или для аттача? HTML-элемента для него нет, он сам превращается в кучу html-элементов уже на этапе отрисовки. Сделать какой-то "{%

%}"? Ну и о каком нативном html-вводе мы тогда говорим, если все равно придется учить теги и парсить коды постов на предмет этих тегов? Где упрощение-то? Наоборот, кроме как добавления лишней головной боли с фильтрацией, никаких серьезных изменений в обработке данных не получается: все равно придется искать и парсить словарик тегов и при вводе, и при отрисовке.

 

Теоретически, начав переход на CKEditor, IPS может пойти дальше, и перевести ввод и хранение тоже в HTML, но зачем?

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

б) Этот шаг не принесет никакой практической пользы - уже сейчас есть визуальный редактор, который конвертирует html + bbcode bbcode "на лету", что позволяет сочетать безопасность и расширяемость bbcode с удобством WYSIWYG.

 

Да, это сложнее, чем просто HTML, но программистам не впервой писать что-то более сложное, чтобы создавать удобный и практичный функционал. Это только двоечники и далекие от IT люди говорят "зачем заморачиваться, и так сойдет", и вкручивают простой html-ввод и хранение, а потом городят велосипеды для доп.функицонала и мучаются с дырами. Любой грамотный специалист смотрит куда глубже, и если взять всю систему в совокупности, то BBCode с опциональным WYSIWG вводом значительно превосходит HTML.

 

P.S. И, кстати, я, например, никогда не пользуюсь визуальным редактором и везде его отключаю, т.к. мне удобнее, проще и быстрее писать коды без этой ВЮСИВЮГуйни, и результат получается чистым и ожидаемым. Никакой ВЮСИВЮГ такого не даст.

Ок, вам не нравится CKEditor (вполне обосновано, как я понял).

 

Бггг. Что, безусловно, помешает мне отключить в браузере JavaScript

Точно, совсем забыл про это)

 

1)

Так же с помощью данных разметок можно удобно реализовать сложные функции, вроде создания автоматического оглавления, боковых блоков, органичения прав доступа к контенту

Что такое автоматическое оглавление?:) Может я с ним и сталкивался, но не знал, что это "автоматическое оглавление")

 

органичения прав доступа к контенту - даже не представляю как это делают средствами бб-тегов и вики-разметки)

 

2)

Практически невозможно создать такой парсер html, чтобы убирал все лишнее и опасное из html, быстро работал и при этом не портил разметку текста

Ок, поверю вам на слово. Но как ВЮСИВЮГ может портить разметку? Вы имеете ввиду то, что он добавляет инлайновые стили (инлайновые стили - это не комильфо) в свои хтмл-теги?

И сразу же вопрос. Получается, на стороне сервера бб-парсер должен экранировать ВСЕ пришедшие от пользователя хтмл теги (может что-то еще?), так ведь? Такой подход может на 100% гарантировать защиту от такого типа взлома?

 

3)Получается, ребята из ИПБ переписали работу (не полностью конечно) всех (почти всех) стандартных кнопок в CKEditor?

 

4)

Это только двоечники и далекие от IT люди говорят "зачем заморачиваться, и так сойдет"

Я такого не говорил:)

 

5)

уже сейчас есть визуальный редактор, который конвертирует html + bbcode <> bbcode "на лету", что позволяет сочетать безопасность и расширяемость bbcode с удобством WYSIWYG

Посоветуйте мне для изучения этот крутой редактор, про который вы пишете)

Изменено 20 сентября 201213 г пользователем stud

Получается, на стороне сервера бб-парсер должен экранировать ВСЕ пришедшие от пользователя хтмл теги (может что-то еще?), так ведь? Такой подход может на 100% гарантировать защиту от такого типа взлома?

Да. htmlspecialchar'сить хтмл символы в сущности, и распарсить ббкоды. В принципе может защитить на 99,9%, но тут встают ббкод'ы, через которые иногда просачивается нечисть (недостаточная их фильтрация)

 

@stud, вы сейчас конкретно лолите. Вы бы почитали сначала что такое ббкоды. Потом вспомнили что JS это клиентский язык. А первое правило гласит - никогда не доверяй данным поступающим от клиента, каким бы образом на его стороне они небыли обработаны. Вам, вроде как человеку с наклонностями программиста это должно быть известно как никому другому.

stud, вы сейчас конкретно лолите

Если вы про

р: "Бггг. Что, безусловно, помешает мне отключить в браузере JavaScript"

с: "Точно, совсем забыл про это"

Да, согласен:)

А то, что JS - это клиентский язык, я помню)

Получается, ребята из ИПБ переписали работу (не полностью конечно) всех (почти всех) стандартных кнопок в CKEditor?

Ребята из IPS написали промежуточный парсер, который получает html и конвертирует его BBCode, и, да, таки вмешались во многие "кнопки". То, что приводится к стандартным BBCode - остается. Все остальное экранируется.

 

Что такое автоматическое оглавление

Один из wiki-тегов.

 

органичения прав доступа к контенту

Про широко известный в узких кругах тег [hide] никогда не слышали?

 

Посоветуйте мне для изучения этот крутой редактор, про который вы пишете

Он у вас перед глазами, в вашем 3.3.х дистрибутиве. Созданный в CKEditor HTML перед записью в базу транслируется в BBCode.

 

Если вас интересует вариант именно на JS, чтобы преобразование шло в браузере, то вот, например: http://www.wysibb.com/

 

Но как ВЮСИВЮГ может портить разметку?

Начнем с того, что пустой документ в textarea имеет код:

А пустой документ в CKEditor имеет код:

<p>
 </p>

 

Дальше объяснять?