Comments 54
А сразу рассказать не судьба?
Уже придумал несколько интересных применений такой системе в рамках своих задач.
А оптимизированы ли получающиеся страницы под поисковые системы? Метатэги, ключи и прочая магия…
А оптимизированы ли получающиеся страницы под поисковые системы? Метатэги, ключи и прочая магия…
Скорее всего, нет. Поисковики же, вроде, не выполняют JS.
Вот поэтому вас и минусуют. Вы же не разбираетесь в теме :). Во-первых – выполняют, если он синхронный. Во-вторых – есть разные способы их этому все-таки научить. А еще вы, помоему, не знаете о такой штуке как Backend as a Service.
Короче, идея здравая, но:
1. Она на поверхности. Любой нормальный MVC-фреймворк позволит такое сделать без особых проблем.
2. Вы не похожи на человека, который сможет сделать в этой области адекватное решение.
Короче, идея здравая, но:
1. Она на поверхности. Любой нормальный MVC-фреймворк позволит такое сделать без особых проблем.
2. Вы не похожи на человека, который сможет сделать в этой области адекватное решение.
Я не автор темы.
За BaaS не знал, загуглил.
2. Как вы это узнали?
За BaaS не знал, загуглил.
2. Как вы это узнали?
Если вы не автор темы, то никак. Я просто сложил то, что написано в статье и ваш комментарий. Вместе это создает КРАЙНЕ стойкое впечатление решателя теоремы Ферма без понимания азов математики.
А насчёт выполнения поисковиками JS я и правда не знал и рассуждал так потому, что мой сайт (с как-раз таки асинхронным AJAX-запросом) был не совсем правильно проиндексирован. Спасибо, теперь знаю, что они всё-таки запускают скрипты.
Недавно даже запустили SaaS-сервис, который позволяет индексировать такие сайты. А я пару лет назад сделал это: github.com/inossidabile/hashbang. Но это убивает в щи ранжирование. Так что индексируют поисковики такой контент или нет в настоящее время вопрос философский. Зависит от того, что мы хотим индексировать.
Зря вы так наехали на левого человека. Хоть бы извинились, что ли.
Google очень даже выполняет, и достаточно давно
Описанная CMS генерирует статические страницы. Поисковая оптимизация, использование JS — все зависит от вас.
Несмотря на название, это не CMS. Там нет инструментов управления содержанием.
И ещё есть code.google.com/p/showdown-blog/
CMS подразумевает множество информации, которая не видна каждому посетителю, например админку, права доступа.
Такие вещи обязательно должен контроллировать бэкэнд, на фронтенде в браузере эти данные держать небезопасно, так как у любого есть к ним доступ.
Такие вещи обязательно должен контроллировать бэкэнд, на фронтенде в браузере эти данные держать небезопасно, так как у любого есть к ним доступ.
Если на управляющий скрипт нет прямой ссылки где-либо и его нельзя подобрать простым перебором в духе /admin/index.html, то никто к ним и не доберется. Естественно, это в случае если админ не пользуется Яндекс.браузером или браузером с яндекс/мейл панелью. Эти сволочи всё проиндексируют. И выложат ссылку в открытый доступ. :)
думается мне, что надеяться на «авось никто не найдёт» как минимум не благоразумно
Отлично, давайте допустим что есть сайт с подобной CMS по адресу example.com, путь к управляющему файлу сгенерирован рандомно и название файла состоит из 20..240 абсолютно случайных символов. Вопрос: как вы найдете этот файл?
Добавлю, что имя файла, состоящее из 140 (например) букв латинского алфавита и цифр имеет оччень немаленькое количество вариантов.
Добавлю, что имя файла, состоящее из 140 (например) букв латинского алфавита и цифр имеет оччень немаленькое количество вариантов.
всё зависит от ценности ресурса. одностраничный сайт Васи Пупкина никому не нужен, зато, например, сайт вроде хабра — был бы уже давным давно взломан.
Хорошо, я уточню. Имя файла состоит из 200 букв латинского алфавита и цифр. Длинна числа, содержащего количество вариантов — 0.1821797716e+312, т.е. число длинной 312 символов. При переборе со скоростью, допустим, миллион запросов в секунду, количество лет, необходимых для полного перебора, составит примерно 3.4e+295 ( 36**200/1_000_000_000/60/24/365/5 ), конечно это в случае если найдется хостер, способный выдержать перебор с такой скоростью. В конце я ещё поделил на 5 из расчета что нужная комбинация будет примерно в первых 20% перепробованных вариантов.
Вы всё ещё уверены что перебором вы найдете админку?..
Вы всё ещё уверены что перебором вы найдете админку?..
и всё у Вас вроде бы должно быть хорошо… пока однажды где-нибудь не засветится url…
А также не забывайте о возможности взлома ftp и т.д. А также взлома соседнего аккаунта хостера и через какую-либо уязвимость посмотреть Ваш url, ведь для осуществления данного взлома даже не надо изменять никаких файлов, не надо смотреть бд — что значительно упрощает несанкционированный доступ.
А также не забывайте о возможности взлома ftp и т.д. А также взлома соседнего аккаунта хостера и через какую-либо уязвимость посмотреть Ваш url, ведь для осуществления данного взлома даже не надо изменять никаких файлов, не надо смотреть бд — что значительно упрощает несанкционированный доступ.
Всё проще: кафе, WiFi, сниффер.
И ещё проще: хистори браузера.
Или вы предполагаете, что этой CMS будут пользоваться исключительно спецы по компьютерной безопастности? :)
И ещё проще: хистори браузера.
Или вы предполагаете, что этой CMS будут пользоваться исключительно спецы по компьютерной безопастности? :)
Если вы куда-то заходили браузером, скорее всего, Гугл уже знает адрес.
В статье же говорим о полностью построенном на JS сайте, это означает что у него единая точка входа и весь код в браузере, со всеми возможными путями и роутингами. Какие такие пути к админке?
UFO just landed and posted this here
в такой ситуации связка логин/пароль всё-таки будет использоваться, а также использование кросс-доменный ajax — само по себе не является фактором, повышающим безопасность, а скорее даже наоборот, т.к. ограничить по-дефолту фильтрацию по ip не представляется возможным, ввиду отсутствия у многих пользователей «белого» ip.
Авторизация и общение с хранилищем идет по https. Это общепринятая практика.
Даже в случае дефейса, восстановление из бэкапа элементарно, т.к. это статический сайт.
Даже в случае дефейса, восстановление из бэкапа элементарно, т.к. это статический сайт.
Даже в случае дефейса, восстановление из бэкапа элементарно
Всегда считал, что создавать сайты нужно таким образом, чтобы тот самый «случай дефейса» не произошёл.
Чью систему авторизации проще обойти — OpenStack Keystone или вашу самописную на похапэ?
погуглите на тему уязвимостей OpenStack Keystone
соответственно самописная авторизация используется на меньших количествах сервисов, соответственно меньше желающих её сломать, но логично предположить, что выбор методов авторизации прямо зависит от задач и бюджета. Так кассу в маленьком ларьке не будет охранять взвод охраны, тогда как в в крупном банке такие меры предосторожности удивления совсем не вызывают.
соответственно самописная авторизация используется на меньших количествах сервисов, соответственно меньше желающих её сломать, но логично предположить, что выбор методов авторизации прямо зависит от задач и бюджета. Так кассу в маленьком ларьке не будет охранять взвод охраны, тогда как в в крупном банке такие меры предосторожности удивления совсем не вызывают.
UFO just landed and posted this here
Вспомнил TiddlyWiki, ухмыльнулся.
Для затравки — громкое заявление: эта статья способна оставить без работы тех backend-разработчиков, которые еще не познали дао Javascript.эммм… А где, собственно, статья?
Был у меня знакомый который писал магазин на css, может вас познакомить? :)
Являясь начинающим веб-разработчиком, так же интересуюсь js (вижу в нем огромный потенциал), такая новость не может не понравится, такая низкая стоимость хостинга, просто радует, что возможно «жаба» душить не будет, платить за хостинг более 100 руб/мес, при том, что проекты мои нуждаются в доработке, а поделиться ссылочкой с друзьями, или продемонстрировать сайт (не нося его на флешке постоянно) к примеру заказчику, хочется. :)
Считаю, что новичкам, таким как я, будет тоже в радость такая новость. Так как 3 руб\мес, это копейки. :) А похвастаться так же хочется.
Считаю, что новичкам, таким как я, будет тоже в радость такая новость. Так как 3 руб\мес, это копейки. :) А похвастаться так же хочется.
если нужны только клиентские штуки и только что бы показать друзьям, то проще всего заюзать pages.github.com/, и это будет стоить вам 0 руб/месяц
Вы будете писать об этой CMS или нет?
UFO just landed and posted this here
Автор давай пиши! Все хотят.
Теоретически, можно. Но тут несколько важных моментов. Если заказчик имеет столь скромные средства, что не может оплатить хостинг — что собственно получит с такого заказчика разработчик? Далее — захотел заказчик банальную форму заказа или что-то другое, более специфическое, что из готового кода не взять. Да, можно опять-же исхитриться и написать все на клиентском JS. Но эта задача будет в разы сложнее, чем на привычном стеке технологий. А так как заказчик не может оплатить нормальный хостинг, адекватную сумму за эту задачу мы не получим. Даже если заказчик к этому моменту уже разжился средствами, все-равно объем работы на расширение функционала будет гораздо больше. Да и имея приличный опыт использования и расширения такой системы разработчик скорее переквалифицируется в обычного front-end разработчика, где зарплаты намного выше а проблем намного меньше.
Хотя, есть обратная сторона. Из такого проекта может вырасти что-нибудь интересное, применимое на практике, но очень далекое от изначальной цели, ну и опыт бесценный никуда не денется. Если у Вас получится и вы напишете про эту статью, будет интересно почитать. Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений. Такой проект, описанный изначально как jsut for fun будет воспринят намного позитивнее.
Хотя, есть обратная сторона. Из такого проекта может вырасти что-нибудь интересное, применимое на практике, но очень далекое от изначальной цели, ну и опыт бесценный никуда не денется. Если у Вас получится и вы напишете про эту статью, будет интересно почитать. Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений. Такой проект, описанный изначально как jsut for fun будет воспринят намного позитивнее.
Вы старую парадигму веб-разработки описали: «нужно оплатить хостинг», «форма заказа» должна иметь бэкенд на этом оплаченном сервере и т.д. Если мыслить категориями облачных сервисов, SaaS и PaaS, то все встает на свои места. Если клиенту выгоднее ценообразование облака, то он найдет того разработчика, который владеет этими технологиями.
Троллинг ригидности мышления — неблагодарное занятие, но это должен кто-то делать. В конце концов минусы на хабре — это не костер инквизиции.
Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений.
Троллинг ригидности мышления — неблагодарное занятие, но это должен кто-то делать. В конце концов минусы на хабре — это не костер инквизиции.
Sign up to leave a comment.
CMS на Javascript