Ajax
CSS
JavaScript
HTML
Comments 44
+11


Извините, но это всё, что надо знать о вашем шаблонизаторе на данный момент.


Переделывайте архитектуру — все подставляемые переменные должны экранироваться по умолчанию, как минимум.

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

Неверно (если речь действительно про конкретную модель, а не про включение глобального флага «экранировать всё везде»).
Так можно предотвратить только частный случай, но это не решает проблемы в целом — рано или поздно у вас в проекте окажется какая-то модель, где вы забыли поставить условную галочку «убрать xss» (как в этом примере).


Это та же самая причина, по которой никогда не стоит использовать ручную конкатенацию для построения SQL запросов — люди ошибаются, и в проекте больше хелловорлда у вас с достаточно большой вероятностью будет уязвимость.


Категорично — именно поэтому. Для реальных проектов это нельзя использовать как минимум пока не будет исправлена эта проблема (выше я написал, почему). «На данный момент» — потому что я всё-таки надеюсь, что вы проблему исправите =).


А по поводу архитектуры — в таких случая можно сделать opt-out из автоматического экранирования, например по коду шаблона или по типу передаваемой переменной (по-разному делают).

+4

И да — даже глобальная галочка будет являться проблемой для новичков, если экранирование будет по умолчанию выключено.
В допущении, что фреймворк станет популярным — появятся люди, которые будут забывать её включать в своём проекте и будут наступать на грабли.


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

0
Добавлен новый параметр [serialize] в колекцию параметров метода _patterns.get(). Пока заменяет экранирует только теги. Но расширить функционал — не проблема. По умолчанию в true. Еще раз спасибо за предложение.
ЗЫ
Документацию обновлю позже )
+3

Если вы про https://github.com/DmitryAstafyev/Patterns/commit/3cdd1ba89, то этого будет недостаточно — вы экранируете только < и >.


Ничто не мешает <input value="{{value}}" /> превратиться в <input value="" onmouseover="…">, если я правильно понимаю.


И ещё — этот коммит сломал поля ввода: когда я тут в поле набираю <3 и убираю фокус, видимое содержимое поля превращается в &lt;3.


Вы точно хорошо подумали над архитектурой?

0
Экранизацию я как-то из виду упустил. Но это не вопрос архитектуры.

Это вопрос именно архитектуры. Шаблонизатор, работающий строго через DOM в принципе не подвержен этой атаке.

0
Значит мы с вами по разному понимаем то, что есть архитектура. По мне, будь это вопрос архитектуры, я бы не добавил экранирование за 11 минут )
0

Есть еще вариант — не пришлось добавлять экранирование так как не требуется by design. Это тоже архитектура. Я ни в коем случае не пытаюсь покритиковать Ваш подход, просто напоминаю что есть и другие решения, если не Вам так тем кто будет это читать — может быть и полезно и интересно.

0
все подставляемые переменные должны экранироваться по умолчанию

Зачем же так строго? Программисты достаточно умны, чтобы понять какие переменные опасны в модели, а какие опасными быть не могут впринципе.
-1
— namespace example
— template helloWorld(name = 'world')
< .hello
Hello {name}!

буээээ

«зацените как мы извращаемся чтобы вывести Hello world! в div»
0
а он на что то еще годится?
чего же тогда нет примера реального приложения?
возможно потомучто слишком страшно получается?
+1
Документация SS написана как раз на самом языке. Вполне нормально выглядит)
+1
Спасибо за ссылку. Почитал, очень интересно. У нас с вами разное целеполагание. У вас более глобально, что ли. У меня же все приземленно )). Моя задача была – шаблонизатор только для front-end.

Да, есть возможность вставки шаблонов в HTML, но опять же и сборка шаблона, и вся работа по его анализу – все на клиенте.

Кроме того, все началось с простой и банальной задачи. Я опишу, если позволите. Было приложение, со множеством разных «окошек» (админка в общем). И там была куча разных контролов. Почти все создавалось на серверной стороне. Потом пришла в голову мысль – а не перенести ли нам все это на клиента – нехай он сам парится, а на сервере все почистить, минимизировать и в идеале оставить только API. Посчитали количество контролов, вышли на несколько десятков очень простых элементов, которые могут работать автономно (то есть не зависят от какой-либо библиотеки и/или фреймвока). Тогда и пришла в голову мысль, а не распихать ли эти контролы по папочкам с JS и CSS, которые к ним относятся. Ну а на клиенте просто их подключать по мере необходимости.

В результате всего этого сервер стал передавать лишь базовую разметку, а вся рутина по рендерингу ушла на клиента вместе с нагрузкой. Мне не удалось, безусловно, превратить серверную часть просто в API сервис, но представлений с серверной стороны было убрано очень много. Ну разве что базовая разметка осталась, как я уже отметил.

Потом была еще пара подобных проектов, где перенос представлений на клиента прошел довольно успешно.

Ну а потом я решил, что пора это все привести в достойный вид (более ли менее) и выложить, может кому и полезным будет.

Иными словами, вот эта штука, которую я тут на ваш суд выставил – это такой инструмент, который позволяет представления вытаскивать с back-end на front-end. И главное, это позволяет проводить отладку каждого шаблона в отрыве от всего проекта. И такого рода инструмент он не универсален, безусловно, он для определенного круга задач.
-1
Спасибо за комментарий. Я думаю, что сравнивать этот шаблонизатор с React нельзя — разные масштабы, да и React — это не шаблонизатор. Ну а то что сделал я — это для очень узкого круга задач — фактически это просто инструмент для создания не слишком сложных UI компонентов (по крайне мере я его так применяю). У React спект применения значительно, значительно шире.
Для меня (я могу судить только по себе :)) главное приимущество: это возможность открывать шаблоны в отрыве от проекта, отлаживать их, править стили. Мне это удобно. Даже если компонент стал сложный, с логикой какой-то, то на создание тестовой страницы (что бы открыть его отдельно) уходит 3-и минуты и все, я снова могу отлаживать копмонент в отрыве от всего приложения.
+4
Из официальной документации — «Lots of people use React as the V in MVC.»
На мой взгляд Javascript в данный момент времени не испытывает недостатка в самых разнообразных шаблонизаторах, ЗАЧЕМ нужен ваш и почему не использовали готовые?
+2

Ещё замечание: у вас в единственном файле исходника количество строчек почти дошло до 10 тысяч (9820).
Наверное, надо что-то разбить на более мелкие файлы и затем собирать их в один.

-3
Если посмотреть на код и свернуть блоки до 2-ой вложенности, то вы увидите 9-ть независимых друг от друга модулей (в том смысле, независимых, что они могут существовать отдельно). То что вы видите на github, да и на промо сайте — это уже результирующий файл.
+3
То что вы видите на github, да и на промо сайте — это уже результирующий файл.

Ну так выложите на гитхаб реальные исходники и скрипт для сборки из них тогда =).

-10
Поясните, пожалуйста, зачем выкладывать «расковырянную» версию и почему то, что лежит сейчас на github нереальные исходники? )

Просто я искренне полагал (и полагаю), что рабочий «мусор» на паблике ни к чему. Есть файл, есть история с которой видны изменения ну и так далее.

Если вам интересен какой-то отдельный модуль, то просто сверните код до второго уровня вложенности и вы увидите все девять модулей по отдельности. Да и станет очевидным то, как все это собирается.
+8
Поясните, пожалуйста, зачем выкладывать «расковырянную» версию и почему то, что лежит сейчас на github нереальные исходники? )

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


Следовательно, исходники — именно «расковырянная» версия.

0

Edit: промазал с ответом, извините. Переношу на нужный уровень.

+3

Сегодня на Хабре день велосипедов и неясных идей.


Автор — у вас страдает ясность изложения, в теории должно хватить одного абзаца, чтобы изложить суть проблемы и одного абзаца для описания решения.


И посмотрите на досуге Jade, например. Возможно, вам понравятся какие-нибудь идеи.

0

Тем, что автор последние пять лет просидел в танке и не знает про существующие решения.

-2
Спасибо за комментарий.
Потому что тег TEMPLATE часть стандарта, а мне не хотелось свое «нестандартное» решение смешивать со стандартами. Однако в patterns предусмотрена простая возможность переопределения корневого тега шаблона.

0
Хотелось бы посмотреть сравнительные тесты например с React Js.
«DOM. {{$name_of_reference}}. Указав с помощью этой метки на узел, вы получите возможность очень быстро обращаться к данному узлу, изменять его, прикреплять события и делать прочие рутинные вещи.»
Особенно при работе с DOM.
0
Спасибо за комментарий. На это уйдет какое-то время, чтобы создать сопоставимые и наглядные примеры и «красиво привинтить» их к документации. Думаю, что неделя или две и я что-то подобное выложу.
0
Спасибо всем за радужный прием)

Из всего спектра комментариев лишь одно дельное замечание, про экранирование (упущенное из виду). Спасибо.
На все остальное (там, где я проигнорировал) я могу ответить парой абзацев, потому как обсуждать, например, то, как проект выложен на github’е я смысла не вижу.

Я писал свое решение, не потому что других решений не существует, а потому что хотел разобраться как это работает. Для меня это здоровая (от слова здоровье) мотивация разработчика. И если собственник проекта не против экспериментов, то для программиста – это находка и глупость упускать подобный шанс; шанс понять, как оно работает изнутри; шанс проверить себя – смогу / не смогу сделать работящее самостоятельное решение. Не пригодится в будущем? Возможно. Кому-то не понравится? Конечно! Но, хвала Зевсу, для меня это не главное и практически не важно.

Видимо часть людей просто стала забывать, что разработка – это прежде всего творчество, искусство, возможность дать своей мысли форму. По крайне мере для меня – это именно так и именно по этой причине я пришел в эту профессию. Поэтому что я могу сказать? «Велосипедил» и буду «велосипедить» дальше, даже несмотря на то, что рядом лежит ReactJS, AngularJS, Jade, EJS и прочие тысячи инструментов.

Еще раз спасибо за Ваше время.

0
я на описании своих велосипедов тоже выгребаю подобные коменты — привыкайте.
0
Не очень понятна идея тащить разметку и данные на клиента и там рендерить, выслушивая матюки владельцев мобильных девайсов.
Гораздо логичнее рендерить класическим способом на сервере, пользуясь копеечной стоимостью облачных решений.
А если уже делать это на клиенте то гораздо эффективнее затащить всю разметку одним запросом — а там и старый добрый Mustache (с декларативной, кстати, разметкой без всяких for и if else) вполне справится.

0
Спасибо за ваш комментарий.

Чуть выше в комментарии я рассказал с чего все началось (как этот шаблонизатор был выделен в отдельное решение). Оба тех проекта, где всецело применено это решение – это админки. То есть по существу – это одинаковый набор элементов управления, где разница есть в их компоновке и данных. В такой ситуации перенос представлений на клиента дал хороший результат. Первая загрузка подольше будет, зато вторая и последующие ощутимо шустрее. В свою очередь разбиение разметки на компоненты дало возможность их отладки в отрыве от приложения, что было очень удобным. Кроме того, после реализации первого проекта к началу работы над вторым уже была хорошая коллекция контролов, которые просто брали и использовали.

Таким образом, идея переноса представлений на клиента состояла в том, чтобы очень большую часть разметки, банально повторяющуюся от страницы к странице перенести на клиента. Перенеся все это на клиента, уменьшили отклик от сервера. А разбив все по элементам управления добились переносимости между подобными проектами.

Требования к мобильным устройствам в данных проектах практически не выставлялись, хотя и на них работает (но не тестировалось так глубоко и основательно, как десктоп).
0
Идея любопытная.
Посмотрите на доступе hiccup
github.com/weavejester/hiccup
— В чем его плюсы. Фантастическая композабельность. Решение с вечными скобочками через paredit
Only those users with full accounts are able to leave comments. , please.