ITCOD-DISK by Yuriy Vdovytchenko

itcod пишет: Если иной формат - то в задействовать JS на стороне клиента;

Гы! Развлекался однажды, экспериментируя с cross-origin и js , заодно готовя контент для блога... только я не от БД хотел самоустраниться, а от php. Типа зачем оно надо, на стороне клиента js ведь имеются... ежели кто из читателей форума пожелает опробовать этот путь, в помощь данная статья по ссылке, там же код и демка. Это так, минута рекламы.

serge пишет: Насколька я понял, предполагается создание ряда разноцветных шаблонов (skins, templates) чтобы удовлетворить все вкусы? Возможно, будет какой-то онлайн-конструктор, позволяющий собрать дизайн интернет-магазина из различных элементов?

Сергей добрый день!
Да всё именно так. Я исторически люблю шаблонные модели. При этом вечно ищу золотую серединку между жёсткой структурой и свободой творчества. Для ITCOD-DISK разработал упрощёную система шаблонизации. В папку кладём шаблон - это html-файл с именем .htindex и при обращении к этой папке UI у пользователя становится как в шаблоне. Шаблон рекурсивен вниз по дереву подпапок. То есть каждая папка и её подпапки может иметь свой собственный дизайн. Мы не ограничиваем разработчика и пользователя единственным или несколькими шаблонами сайта! Сколько нужно - столько и делайте! Ведь в папке может оказаться UI требующий всего экрана и чистого JS-окружения (например система документоооборота или конструктор UI, или ещё что-то "большое и вкусное").

Да при разработке перспектива конструктора и виджет-интерфейсов вертелась у меня в голове. Поэтому выбрал вставку в страницу документированых тегов <!-- --> которые идентифицируют для сервиса md5index какие данные в это место страницы загрузить. (Замечу что их совсем немного! Только важное и нужное.) Тем самым я реализовал возможность использовать практически любой, существующий на сегодня, шаблон из инета для создания шаблона для UI ITCOD-DISK. И c минимальными сложностями по адаптации. Интерфейс который вы видите на сайте - это всего-навсего интерфейс в папке верхнего уровня, который применяется для всех так как глубже (где вы ходите) пока нет других. Документация на UI в данный момент в разработке. Но если хочется сейчас поподробнее, то достаточно изучать имеющиеся записки и станет всё понятно. См. itcod.com/max/projects/itcod-disk/UI/templates/ . Конечно есть ещ исходный код md5index - но это уже для любителей вкуснятины:)))

PS: Конструктор imho конечно лучше всего писать на JS и оперировать div'ами в DOM, и в конце процесса просто сохранить результататы по div'ам. Ну... можно конечно написать и отдельный сервис в интернете... но городить сервис/сервер/моресофта... для такой задачи мне кажется излишне статичным, усложнёным и неэфективным решением. Вот только у меня руки до такого дойдут не скоро. Я считаю, что многое могут реализовать сторонние разработчики, если посчитают, что эта задача или интересна или финансово-перспективна.

Aleksej пишет:

itcod пишет: Если иной формат - то в задействовать JS на стороне клиента;

Гы! Развлекался однажды, экспериментируя с cross-origin и js , заодно готовя контент для блога... только я не от БД хотел самоустраниться, а от php. Типа зачем оно надо, на стороне клиента js ведь имеются... ежели кто из читателей форума пожелает опробовать этот путь, в помощь данная статья по ссылке, там же код и демка. Это так, минута рекламы.

Алексей так вы же использовали сайт источник как "сервис"! и при помощи JS визуализировали данные, так как вам требовалось на собственном ресурсе! Вы 100% правильно отделили DB и UI в парадигме SOA и для каждого элемента применили тот инструмент который был наиболее удобен и эффективен. В данном случае, как я понял, всё прекрасно сработало с кросдоменным htmlRequest и последующим парсингом и визуализацией данных. Именно это и есть правильный подход к разработке сервис-ориентированных решений.
Вот только сайт-источник не !!!сервис!!! и не идентифицирует данные на странице для АСУ и поэтому - когда он чтото изменит в своём шаблоне, то ваш парсинг развалится (и это грустно). В этом глобальное отличие обычного UI для пользователей и UI адаптированного также и для автоматизированного разбора данных внешними системами (сайтами/сервисами/толстыми клиентами).

PS
В SOA вы могли бы не отдавать эти данные сразу пользователю, а например прогнать их ещё через десяток различных сервисов для получения суперкрасочных аналитических отчётов с графиками итд... и только потом вывалить это счастье клиенту. То есть задействовать те сервисы для обработки - которых у Вас нет, но гдето они есть и доступны.

ДОбрый день! А есть уже какая демка товаров интернет-магазина? Интересно было бы посмотреть. Спасибо за ваш ответ.

Unior82 пишет: ДОбрый день! А есть уже какая демка товаров интернет-магазина? Интересно было бы посмотреть. Спасибо за ваш ответ.

Добрый день!
Полноценная демка торговой площадки в облаке - это дело ближайших пары месяцев.
Есть прототипы UI ориентированные на продажи (хотя задача прототипа была немного иной при разработке).
Наиболее интересным с этой точки зрения наверное будет вот этот 2013 года:
itcod.com/.dir/AIST.html (сначало просто понаводите курсор на иконки, менюшки, кнопки - а уже потом пощёлкайте)
В UI нет связи с облаком - так как он создан до создания облака itcod-disk. UI не может полноценно работать если у вас включен для сайта ADS.
А так же - он притормаживает, так как сейчас не может использовать CDN и сервис ResizeIMAGE, которые прямо сейчас адаптируются для работы с облачным ресурсом itcod-disk.

Если будет интересна тема UI для облачных сайтов, то вот маленький списочек прототипов UI которые являлись вехами исследования и разработки.

UI для сервис-ориентированной системы электронных каталогов ITCOD
Основное свойство: работает на локальном ПК с любого носителя аналогично
как и на сайте(портале). Единый каталог для любого носителя(хранилища) данных.

2012-2013 г. ITCod-Web (itcodw.js)
Прототип информационной площадки из множества электронных каталогов (Статический интерфейс)
itcod.com/.dir/itcod-web.html (множество e-каталогов в одном интерфесе)

2013-2014 г. ITCodAPI (itcodAPI.js)
Прототипы инфо-сайтов (сайты со сменными рубашками/интерактивные/JS-виджеты)
itcod.com/.dir/hallo.html (первые сменные html-темплейты для e-каталогов)
itcod.com/.dir/reclama.html (развитие JS-виджетов html-темплейты e-каталогов)
itcod.com/.dir/AIST.html (интеракитивный интерфейс (выключите для сайта ADS!))

2014-2015 г. (itcod.js)
Прототип UI полностью масштабирующий каждый элемент DOM (согласно размеров экрана и точек привязки элементов)
itcod.com/.dir/rarev.html (масштабируемый интерактивный интерфейс)

2015 г.
разработка ITCOD-DISK (включая миниUI), а так же html-форм и JS для подключения на любом
сайте в любом хостинге. Рабочая модель сервисов и UI: itcod.com

Все перечисленные прототипы и каталоги доступны здесь: itcod.com/.dir/

PS
Сейчас идёт слияние всех наработок и элементов проекта в единый проект.
По факту - мы реализуем UI для управления товарами вручную, или реализуем с кем-либо автоматизированное решение (про 1С например я уже говорил). Или реализуем оба или более вариантов

itcod пишет: А плюшки, которые требуют PHPSQL и обработок на стороне сервера, могут представляться в инете отдельным сервисом.

Хорошо тебе, Юра.
Джумлаводы как раз сегодня празднуют zero-day , и "радостных волнений" выше крыши. Я, например, полночи копался в скриптах, пытаясь понять, почему, несмотря на все принятые меры безопасности, на сайт просачивается какая-то гадость.... потом плюнул и откатил сайт взад из резервной копии, последние несколько сообщений форума заливал уже вручную из базы, чтобы ни байта инфы не пропало... насколько понимаю, превратности написанных на пыхе и js движков и extensions некритичны для твоего проекта? Скажи честно, какие-либо случаи взлома уже бывали? Или твой проект в плане безопасности для джумлавода - все равно что linux для виндузятника, т.е. недостижмая вершина?

Aleksej пишет: ... чтобы ни байта инфы не пропало... насколько понимаю, превратности написанных на пыхе и js движков и extensions некритичны для твоего проекта? Скажи честно, какие-либо случаи взлома уже бывали? Или твой проект в плане безопасности для джумлавода - все равно что linux для виндузятника, т.е. недостижмая вершина?

Алексей, дорый день!
Так как это Open Source, то стучать пяткой в грудь, что система супер-бупер защищена не буду Маркетинг оставим менеджерам. А профессионалы оценят ниже сказаное. Ведь прекрасно знают, что безопасных систем не бывает, есть только удачно скрываемые от пользователей дыры)))
Наверное я был бы счастлив как удав! если бы всё было радужно в проекте, с точки зрения безопасности. Тема безопасности одна из приоритетных и постоянно её кручу в голове, с целью выявить определённые методы которые можно применять для атак. Конечно SQL-инъекции и атаки на PHP в связи с отсутствием такого софта отпадают. При этом есть ещё множество иных вариантов, которые зависят от стандартов, от разработчиков браузеров и разработчиков UI. Чтобы не быть голословным приведу маленькую выдержку из моей внутренней записки, чтобы стало понятно, насколько сильно процесс моделирования атак влияет на разработку элементов входящих в состав проекта.

Для понимания приведёной выдержки из записки термин "ресурс" означает - пространство пользователя на портале itcod.com, а НЕ на выделеном в хостинг облачном сайте. Это важное замечание!!! так как для сайтов(доменов) в браузерах существуют кросс-доменные костыли безопасности предотвращающие часть атак (ну или по крайней мере сообщество так считает для собственного успокоения).

---

Размышления о безопасности ITCOD-DISK
2015 max(c)itcod.com

ITCOD-DISK это многопользовательский диск позволяющий в одном окружении браузера при переходе с ресурса на ресурс запускать UI любых пользователей (включая скрипты и запросы к внешним сервисам). Это аналогия корпоративной среды, где якобы мы доверяем "своим". Только в любом стаде найдётся хакер. Отсюда вывод доверять никому нельзя! и любая среда, будь она корпоративной или интернет является по сути враждебной для пользователя (или админа старающегося обезопасить и сохранить данные).

UI ITCOD-DISK при переходе с ресурса на ресурс пользователей - страница полностью перечитывается. С одной стороны - это НЕ позволяет вредоносному ПО вырваться за пределы ресурса пользователя, где UI хакера был загружен, так как при переходе в другой ресурс UI будет удалён браузером и весть код JS попадёт под деструктор. Но с другой - сохраняется сессионый доступ к ресурсам в которых пользователь авторизовался ранее, а так же к небезопасным хранилищам браузера css localStorage sessionStorage.

Итого...
1. localStorage и sessionStorage являются полностью небезопасными в среде многопользовательского портала, так как они не обнуляются, и я пока не планирую делать их очистку при переходе внутри сайта с ресурса на ресурс пользователей. При всей своей незащищёности эти хранилища предоставляют очень перспективный буфер данных в пределах портала (например закриптованых данных).

2. Если пользователь авторизовался в своём ресурсе, а потом зашёл на ресурс хакера с атакующим UI, то хакер может использовать XSS-атаку и получить доступ к данным на облачном ресурсе пользователя через его браузер, так как браузер уже помнит логин-пароль пользовательского ресурса и автоматически добавит его в get/put/etc запрос с запароленому ресурсу (тут ещё вопрос про перехват отсылаемого на сервер). Последствия могут быть плачевны для пользователя - их данные на диске могут быть или украдены или скомпрометированы хакером даже не знающим пароль.
Конечно радует что хакер не может их удалить... но и компрометация вызывает бурю возмущения даже у меня (мало ли что я пишу в аферте не хранить конфеденциальщины! я и сам её там храню как и все)))
ЭТО ОПАСНЫЙ МЕТОД АТАКИ ДЛЯ КОТОРОГО НЕОБОДИМО СРОЧНО НАЙТИ ЗАЩИТУ

3. HTML-иньекция. Хакер вполне лигитимно меняет в стандартном шаблоне портала ссылку авторизации и подделывает запрос браузера о аторизации. При этом ловит любопытных лохов(чайников) и собирает логины и пароли. И вот потихоньку все чайники слились в базу хакера.
ОПАСНЫЙ НЕ МЕНЕЕ ЧЕМ XSS.

......

Если ты думаеш, что всё перечисленное это "детские болезни" ITCOD-DISK, то сильно заюлуждаешся! это болезни любого корпоративного портала с множеством "лигитимных" пользователей. И прятать тут нечего... "это геморой батенька!"(c)хтото


А теперь будем моделировать, анализировать, делать выводы и искать решения.

(1)Storage
Обнуление lS и sS не вариант. Хотелось бы иметь буфер для неприватных данных не представляющих ценности для хакера. Другое дело защитить его! криптой как то.... или ещё как.... синхра с storage в облаке.... думать надо....
Сейчас пока УТВЕРЖДАЕМ! что ничего ценного разработчики туда ложить не будут или не смогут! (по закону мерфи БУДУТ! блин тоже мне америка!).

(2)XSS
При этом учитываем, что шаблон UI-ресурса хакера выглядит вполне легально и безобидно. Пользователь имеет право загружать свой UI и скрипты и работать в своем UI с различнми ресурсами. То есть его JS-атака на данные другого пользователя на вид выглядит вполне лигитимно!!! бред конечно!!! но отключать JS или как либо ограничивать свободу пользователя ещё больший бред.
СЛЕДОВАТЕЛЬНО ТРЕБУЕТСЯ? ЧТО! ИЩЕМ ВАРИАНТЫ ИССЛеДУеМ ПОСЛЕДСТВИЯ

2.1. Например запретить авторизованные запросы из одного ресурса к другому?
А возможно ли это? А какие последствия?
Даже если возможно то - это очень похоже на запрет кроссдоменных htmlRequest. Не лучшый вариант даже для инета, если проводить параллели. И совершенно тупиковый путь для SOA решений к которым относится ITCOD-DISK.

2.2. Запретить деструктивные действия - обеспечит только защиту от удаления (которых и так нет), но не исключит воровства данных.

2.3. Как то потверждать легитимность выполняемой операции, без каких либо идентификаторов.
кодировать... подписывать.... а ключи где хранить откуда брать как защитить....
!!!!!!!!!!!!!! "ДУМАЙ! НОМЕР ГАЛАКТИКИ В ТЕНТУРЕ!"(с)КинДзаДза

2.4. Легитимность скриптов и их право на действия в данной области ресурса.
То есть.... в гетах и путах итд мы не видим реально что вызвало запрос... то есть анриал....
Лигитимность работающих скриптов в DOM.... кто будет контролировать контролёра... его же можно купить убить заменить... и невозможно защитить. то есть тоже анриал.... Это всё похоже на область видения для JS в браузерах... только там это на уровне доменов встроено. а нам нужен уровень ресурсов в одном домене... и даже на уровне доменов там тоже всё корявыми костылями через пеньколоду сделано разработчиками браузеров...

2.5. При переходе с ресурса на ресурс заставить браузер удалить из кэша открытые сессионые доступы (имена и пароли)... Блин знать бы где браузер эту хрень хранит и чем и что ему сказать чтобы обнулил... JS или сервер... какойто код надо дать браузеру... надо глубже погружаться в тему этих глюкодромов которых расплодилось как менеджеров у сетевого маркетинга....

(3)HTML
Подделка страницы.... необходимо например:
3.1. как то уведомить клиента в браузере, что он находится вне безопасного интерфейса портала!
3.2. или запретить смену шаблона портала в юзеров
3.3. или как то контролировать UIшки пользователей
3.4. или разрешать смену UI каким то избранным клиентам а не всем кому попало...

реально пока 1 и 4
2 и 3 это из разряда фантастики.. 2 глупо... 3 сложно и ненадёжно.
1 не обеспечивает защиты от слепого дурня и мгновенной xss-атаки....
4 а на каком основании разрешать.... купить доступ может и хакер... а если дорого, то сервис и нормальному юзеру будет не нужен - дешевле тогда купить домен.... и опять же xss-атака

......

Надеюсь выдержка была полезной

>>> Скажи честно, какие-либо случаи взлома уже бывали?
чего то такого опасного и деструктивного не было слава богу... сам потихоньку играюсь в песошнице и плюшками балуюсь.... периодически наваляю JS-ку в ресурсе какомнибудь, суну в шаблон и смотрю результат "украла-неукрала видит-невидит", чтобы определить насколько реальна пришедшая в голову идея взлома Очень удобно с точки зрения моделирования реальных скрытых атак на данные... они же реальны и работают с реальным софтом и данными Но как ты понимаеш чтото сломать в ресурсе пользователя это надо выкрасть пароли к ресурсу... а птом задействовать WEBDAV... так как через браузер управления данными нет и в ближайшей перспективе не планирую.... В перспективе на отдельном домене без возможности менять UI редактирования появится какой нить конструктор UI с редактором содержания. Кстати это может сделать любой желающий и продавать как сервис CMS для облачных сайтов.... Вот Вам и полноценные облачные CMS (названия придумывайте сами) )))

itcod пишет: localStorage и sessionStorage являются полностью небезопасными в среде многопользовательского портала, так как они не обнуляются, и я пока не планирую делать их очистку при переходе внутри сайта с ресурса на ресурс пользователей. При всей своей незащищёности эти хранилища предоставляют очень перспективный буфер данных в пределах портала (например закриптованых данных).

Данная ремарка предназначена не для Юрия, разумеется... а для тех читателей форума, которые пока что плохо представляет себе, что же такое это самое пресловутое Local Storage.
Значение слова "кэш" понимают уже многие пользователи, "даже "очистить кэш" сумеют многие (я, разумеется, использую данный термин в контексте веба только, а не как сленговый американизм, означающий наличные деньги). Но вот каковы современные спецификации уже совсем ненового HTML5 Local Storage, что это вообще такое - понимают немногие пользователи интернета. Я позволю себе продемонстрировать простенький пример, иллюстрирующий интересную эту тему... откройте Sticky Notes , создайте стикер с любым текстовым содержанием, после чего почистите кэш своего браузера и перезагрузите страничку... сумеете вы таким образом убить ваш стикер? - наглядные примеры порой гораздо более впечатляют, чем горы текстовой информации.

эффектно... сервиса резервного копирования 1С баз не предоставляете, Юрий?