CMS на Javascript

[namikiri]

А сразу рассказать не судьба?

[surething]

Минусы => интереса нет.

[robertkein]

Уже придумал несколько интересных применений такой системе в рамках своих задач.
А оптимизированы ли получающиеся страницы под поисковые системы? Метатэги, ключи и прочая магия…

[namikiri]

Скорее всего, нет. Поисковики же, вроде, не выполняют JS.

[inossidabile]

Вот поэтому вас и минусуют. Вы же не разбираетесь в теме :). Во-первых – выполняют, если он синхронный. Во-вторых – есть разные способы их этому все-таки научить. А еще вы, помоему, не знаете о такой штуке как Backend as a Service.

Короче, идея здравая, но:

1. Она на поверхности. Любой нормальный MVC-фреймворк позволит такое сделать без особых проблем.
2. Вы не похожи на человека, который сможет сделать в этой области адекватное решение.

[namikiri]

Я не автор темы.
За BaaS не знал, загуглил.
2. Как вы это узнали?

[inossidabile]

Если вы не автор темы, то никак. Я просто сложил то, что написано в статье и ваш комментарий. Вместе это создает КРАЙНЕ стойкое впечатление решателя теоремы Ферма без понимания азов математики.

[namikiri]

А насчёт выполнения поисковиками JS я и правда не знал и рассуждал так потому, что мой сайт (с как-раз таки асинхронным AJAX-запросом) был не совсем правильно проиндексирован. Спасибо, теперь знаю, что они всё-таки запускают скрипты.

[inossidabile]

Недавно даже запустили SaaS-сервис, который позволяет индексировать такие сайты. А я пару лет назад сделал это: github.com/inossidabile/hashbang. Но это убивает в щи ранжирование. Так что индексируют поисковики такой контент или нет в настоящее время вопрос философский. Зависит от того, что мы хотим индексировать.

[LimeOrange]

Зря вы так наехали на левого человека. Хоть бы извинились, что ли.

[nazarpc]

Google очень даже выполняет, и достаточно давно

[surething]

Описанная CMS генерирует статические страницы. Поисковая оптимизация, использование JS — все зависит от вас.

[newdya]

First CMS written in Javascript.

[surething]

Несмотря на название, это не CMS. Там нет инструментов управления содержанием.

[newdya]

И ещё есть code.google.com/p/showdown-blog/

[DjOnline]

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

[LimeOrange]

Если на управляющий скрипт нет прямой ссылки где-либо и его нельзя подобрать простым перебором в духе /admin/index.html, то никто к ним и не доберется. Естественно, это в случае если админ не пользуется Яндекс.браузером или браузером с яндекс/мейл панелью. Эти сволочи всё проиндексируют. И выложат ссылку в открытый доступ. :)

[LLIypLLIuk]

думается мне, что надеяться на «авось никто не найдёт» как минимум не благоразумно

[LimeOrange]

Отлично, давайте допустим что есть сайт с подобной CMS по адресу example.com, путь к управляющему файлу сгенерирован рандомно и название файла состоит из 20..240 абсолютно случайных символов. Вопрос: как вы найдете этот файл?
Добавлю, что имя файла, состоящее из 140 (например) букв латинского алфавита и цифр имеет оччень немаленькое количество вариантов.

[LLIypLLIuk]

всё зависит от ценности ресурса. одностраничный сайт Васи Пупкина никому не нужен, зато, например, сайт вроде хабра — был бы уже давным давно взломан.

[LimeOrange]

Хорошо, я уточню. Имя файла состоит из 200 букв латинского алфавита и цифр. Длинна числа, содержащего количество вариантов — 0.1821797716e+312, т.е. число длинной 312 символов. При переборе со скоростью, допустим, миллион запросов в секунду, количество лет, необходимых для полного перебора, составит примерно 3.4e+295 ( 36**200/1_000_000_000/60/24/365/5 ), конечно это в случае если найдется хостер, способный выдержать перебор с такой скоростью. В конце я ещё поделил на 5 из расчета что нужная комбинация будет примерно в первых 20% перепробованных вариантов.

Вы всё ещё уверены что перебором вы найдете админку?..

[LLIypLLIuk]

и всё у Вас вроде бы должно быть хорошо… пока однажды где-нибудь не засветится url…
А также не забывайте о возможности взлома ftp и т.д. А также взлома соседнего аккаунта хостера и через какую-либо уязвимость посмотреть Ваш url, ведь для осуществления данного взлома даже не надо изменять никаких файлов, не надо смотреть бд — что значительно упрощает несанкционированный доступ.

[demark]

Всё проще: кафе, WiFi, сниффер.

И ещё проще: хистори браузера.

Или вы предполагаете, что этой CMS будут пользоваться исключительно спецы по компьютерной безопастности? :)

[homm]

Если вы куда-то заходили браузером, скорее всего, Гугл уже знает адрес.

[LLIypLLIuk]

а также если сразу и админки куда-то заходили браузером, то этот сайт уже знает url, а значит что адрес скомпрометирован, и сайт может быть потенциально взломан в это же мгновение.

[DjOnline]

В статье же говорим о полностью построенном на JS сайте, это означает что у него единая точка входа и весь код в браузере, со всеми возможными путями и роутингами. Какие такие пути к админке?

[boolive]

Тут только вопрос, где контроль доступа осуществляется

[LLIypLLIuk]

в такой ситуации связка логин/пароль всё-таки будет использоваться, а также использование кросс-доменный ajax — само по себе не является фактором, повышающим безопасность, а скорее даже наоборот, т.к. ограничить по-дефолту фильтрацию по ip не представляется возможным, ввиду отсутствия у многих пользователей «белого» ip.

[surething]

Авторизация и общение с хранилищем идет по https. Это общепринятая практика.
Даже в случае дефейса, восстановление из бэкапа элементарно, т.к. это статический сайт.

[LLIypLLIuk]

Даже в случае дефейса, восстановление из бэкапа элементарно

Всегда считал, что создавать сайты нужно таким образом, чтобы тот самый «случай дефейса» не произошёл.

[surething]

Чью систему авторизации проще обойти — OpenStack Keystone или вашу самописную на похапэ?

[LLIypLLIuk]

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

[Mithgol]

Вспомнил TiddlyWiki, ухмыльнулся.

[surething]

Кстати, да. Нужно только дописать сохранение в облако.

[Theo_from_Sed]

Для затравки — громкое заявление: эта статья способна оставить без работы тех backend-разработчиков, которые еще не познали дао Javascript.

эммм… А где, собственно, статья?

[zxcabs]

Был у меня знакомый который писал магазин на css, может вас познакомить? :)

[surething]

simplecartjs.org

[newdya]

Ссылку не дадите?

[zxcabs]

Ссылку на что?
Как вы себе представляете полностью инет магазин на чистом css? :) Это ж было из серии: «вау! с помощью css можно менять стиль элемента под мышкой, а напишука я инет магазин на чистом css»

[homm]

> Ссылку на что?
На магазин вашего знакомого, или статью о том, как он его делал.

[newdya]

Потому и спрашиваю, что не представляю.

[slavikse]

Являясь начинающим веб-разработчиком, так же интересуюсь js (вижу в нем огромный потенциал), такая новость не может не понравится, такая низкая стоимость хостинга, просто радует, что возможно «жаба» душить не будет, платить за хостинг более 100 руб/мес, при том, что проекты мои нуждаются в доработке, а поделиться ссылочкой с друзьями, или продемонстрировать сайт (не нося его на флешке постоянно) к примеру заказчику, хочется. :)
Считаю, что новичкам, таким как я, будет тоже в радость такая новость. Так как 3 руб\мес, это копейки. :) А похвастаться так же хочется.

[zxcabs]

если нужны только клиентские штуки и только что бы показать друзьям, то проще всего заюзать pages.github.com/, и это будет стоить вам 0 руб/месяц

[slavikse]

Благодарю Вас, обязательно затестирую. :)

[DjOnline]

Или «захостить» на jsfiddle :)

[boolive]

Вы будете писать об этой CMS или нет?

[surething]

Конечно.

[sergeypid]

Автор давай пиши! Все хотят.

[megahertz]

Теоретически, можно. Но тут несколько важных моментов. Если заказчик имеет столь скромные средства, что не может оплатить хостинг — что собственно получит с такого заказчика разработчик? Далее — захотел заказчик банальную форму заказа или что-то другое, более специфическое, что из готового кода не взять. Да, можно опять-же исхитриться и написать все на клиентском JS. Но эта задача будет в разы сложнее, чем на привычном стеке технологий. А так как заказчик не может оплатить нормальный хостинг, адекватную сумму за эту задачу мы не получим. Даже если заказчик к этому моменту уже разжился средствами, все-равно объем работы на расширение функционала будет гораздо больше. Да и имея приличный опыт использования и расширения такой системы разработчик скорее переквалифицируется в обычного front-end разработчика, где зарплаты намного выше а проблем намного меньше.



Хотя, есть обратная сторона. Из такого проекта может вырасти что-нибудь интересное, применимое на практике, но очень далекое от изначальной цели, ну и опыт бесценный никуда не денется. Если у Вас получится и вы напишете про эту статью, будет интересно почитать. Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений. Такой проект, описанный изначально как jsut for fun будет воспринят намного позитивнее.

[surething]

Вы старую парадигму веб-разработки описали: «нужно оплатить хостинг», «форма заказа» должна иметь бэкенд на этом оплаченном сервере и т.д. Если мыслить категориями облачных сервисов, SaaS и PaaS, то все встает на свои места. Если клиенту выгоднее ценообразование облака, то он найдет того разработчика, который владеет этими технологиями.

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

Троллинг ригидности мышления — неблагодарное занятие, но это должен кто-то делать. В конце концов минусы на хабре — это не костер инквизиции.