4 комментария

Опубликована документация по интеграции с приложением «Контакты»: http://www.webasyst.com/ru/framework/docs/dev/contacts-app-integration/

Интеграция позволяет любому приложению получить доступ к базе данных контактов и пользователей Вебасиста и, фактически, использовать всю инфраструктуру приложения «Контакты» вместо реализации собственной. Многие будущие приложения (в том числе приложение «Рассылки», которое сейчас находится в разработке, и новый Shop-Script) будут полностью интегрированы с «Контактами» согласно этой документации.

4 комментария

CSRF (англ. Сross Site Request Forgery — «Подделка межсайтовых запросов», также известен как XSRF) — вид атак на посетителей веб-сайтов, суть которого заключается в выполнении действий от имени пользователя без его ведома. Когда пользователья заходит на сайт, созданный злоумышленником, то от его имени на другой сервер тайно отправляется запрос на выполнение некоторого действия (чаще всего это запросы на популярные ресурсы вроде почтовых служб и соцсетей, на которых пользователь с наибольшей вероятностью будет авторизован). Подробнее об CSRF читайте на Википедии.

Основной метод защиты от атак CSRF заключается в следующем:

  1. Все важные действия пользователя (изменение или удаление данных) должны быть реализованы с помощью отправки формы методом POST.
  2. При отправке данных нужно сгенерировать случайную строку (подпись), сохранить ее значение в куках (cookies) и добавлять во все формы с помощью скрытого инпута <input type="hidden" name="_csrf" value="СОХРАНЁННАЯ_СЛУЧАЙНАЯ_СТРОКА">
  3. При получении запросов POST проверять значение из $_COOKIE['_csrf'] и $_POST['_csrf'] и выполнять действие только в том случае, если значения совпадают. Если это не так, то скорее всего форма была отправлена с другого сайта.

Чтобы сделать приложения на основе фреймворка Вебасист более безопасными, мы реализовали защиту от атак CSRF на уровне ядра фреймворка. Применить защиту в вашем приложении следует следующим образом:

  • В конфигурационном файле вашего приложения wa-apps/[APP_ID]/lib/config/app.php необходимо указать 'csrf' => true
  • В шаблонах во все формы с method=POST добавить {$wa->csrf()}
    Эта конструкция автоматически заменится на скрытый input с нужным значением.
  • Дальнейшая проверка будет осуществлена фреймворком автоматически. Если подписи не будут совпадать, то фреймворк вернет ответ с ошибкой 403 Forbidden на этапе инициализации приложения (управление приложению передано не будет).

AJAX: Если вы подключаете в своём приложении скрипт wa-content/js/jquery-wa/wa.core.js, то параметр _csrf также автоматически будет добавляться во все AJAX-запросы, отправляемые методом POST. Если этот скрипт не подключается, то для защиты от CSRF (при включенном 'csrf' => true в конфиге) вам необходимо во все запросы добавлять переменную '_csrf' = get_cookie('_csrf').

Описанный механизм требует от пользователя включенных куки (cookies), и поэтому в данный момент реализован только для бекенда Вебасиста. Реализацию защиты в коде можно посмотреть на примере приложения «Блог».

5 комментариев

Вместе с приложением «Блог» во фреймворке появилась поддержка OAuth-авторизации через внешние сервисы (соцсети). Реализуется этот функционал на системном уровне с помощью адаптеров авторизации. В базовый состав текущей версии фреймворка включены адаптеры для следующих платформ: Фейсбук, Твиттер, Гугл, Вконтакте.

Пример работы OAuth-авторизации вы можете видеть ниже в форме добавления комментария к записи блога. Во фронтендах будущих приложений подобная авторизация пользователей будет поддерживаться по умолчанию (например, в новом Shop-Script для авторизации покупателей при оформлении заказов).

Документация по подключению адаптеров авторизации в вашей установке: http://www.webasyst.com/ru/framework/docs/dev/auth-adapters/

17 комментариев

Приложение «Блог» доступно для установки через Инсталлер!

Приложение «Блог» позволяет вести открытые (доступные на сайте) и закрытые (доступные только пользователям бекенда) блоги, поддерживает управление правами доступа по блогам, календарь планирования будущих публикаций, отложенную публикацию записей, комментирование записей.

В приложении реализована гибкая плагиновая структура и внедрено много того, что будет использоваться в основе нового Shop-Script. Однако, в данный момент доступ к плагинам еще не открыт. Мы представим несколько интересных плагинов для «Блога» (теги, избранные записи, импорт из ЖЖ, анти-спам Akismet и другие) и документацию для разработчиков в течение ближайшего времени. Плагины можно будет устанавливать через Инсталлер аналогично приложениям.

7 комментариев

В приложении «Сайт» версии 1.1 обновился механизм работы со страницами: функционал страниц вынесен из приложения на системный уровень. В будущем это позволит внедрять функционал страниц в других приложениях без копипаста и написания заново. Первое применение обновленного механизма страниц будет в приложении «Блог»: приложение позволит создавать собственные информационные страницы (например, страницы «О блоге», «Об авторах») аналогично тому, как они создаются в приложении «Сайт». Позже аналогичное применение будет реализовано в «Фото», Shop-Script и других приложениях.

ВАЖНО: Если ваш сайт работает на основе приложения «Сайт», обратите внимание на следующее:

  1. Если у вас только одно поселение приложения «Сайт» на домене (одно правило роутинга для «Сайта»), то ничего делать не надо. Страницы будут продолжать работать, как есть.
  2. Если поселений два или более, то необходимо пересохранить страницы, обновив их адреса (URL). В обновленном приложении «Сайт» страницу нельзя прикрепить к определенному поселению. Теперь страница доступна во всех поселениях приложения за исключением выбранных явно.
  3. Если у вас есть страницы «Сайта», которые прикреплены к поселениям внешних приложений (например, приложений вашей собственной разработки), то после обновления эти страницы перестанут отображаться. Вам необходимо внедрить механизм работы со страницами в ваше приложение (документация для разработчиков в разработке) или добавить адреса выбранных страниц в общий роутинг сайта, «направив» их на приложение «Сайт».

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

1 комментарий

Во фреймворке Вебасист появился новый механизм (обработчик) для выполнения действий по расписанию — cli.php. Приложения могут использовать этот механизм для интеграции с планировщиками задач типа Cron и выполнения задач без участия пользователя. Например, для проверки почты, загрузки новостей с внешних сайтов и пр.

Документация для разработчиков приложений: http://www.webasyst.com/ru/framework/docs/dev/cli/
Пример настройки Cron в cPanel: http://www.webasyst.com/ru/framework/docs/server/cron/

В приложении «Блог», которое будет выпущено в ближайшее время, новый механизм используется для отложенной публикации записей.

24 комментария

Долгожданное приложение «Сайт» доступно для установки через «Инсталлер». Для работы приложения необходимо обновить всю установку Вебасиста, в том числе приложения «Инсталлер» и «Контакты».

«Сайт» предоставляет все необходимые инструменты для создания несложных сайтов, поддерживает многосайтовость, управление маршрутизацией (роутингом), редактор шаблонов дизайна и информационных страниц. Основы создания сайтов с помощью приложения «Сайт» описаны в пошаговом примере создания сайта.

Без использования других приложений «Сайт» позволяет создавать относительно несложные сайты, состоящие только из статических информационных страниц. Вся гибкость и мощь «Сайта» раскроются, когда будут выпущены интегрированные с ним приложения: «Блог», «Фото», «Магазин» и прочие. Тогда на основе «Сайта» можно будет построить действительно многофункциональный сайт. Документация по интеграции своего приложения с «Сайтом» для разработчиков: http://www.webasyst.com/ru/framework/docs/dev/site-app-integration/

Вместе с этим обновлением в «Инсталлере» появилось два новых раздела: «Плагины» и «Темы». В данный момент эти разделы пустые, и мы будем развивать их в ближайших обновлениях.

16 комментариев

Ольга Митрофанова
Интернет-магазин «Мега Подарки»

В августе мы провели рекламную кампанию в купон-сервисе «КупиКупон»: на «КупиКупоне» можно было получить купон, который давал 50%-скидку на любой продукт в нашем интернет-магазине. Вкратце расскажу о результатах акции.

В отличие от стандартных акций, которые предлагают купон-сервисы — покупатель приобретает купон за реальные деньги, и купон дает ему право на скидку (например, покупаешь за 500 рублей купон, и можешь на него поесть на сумму 2000 рублей; другими словами, получаешь 75% скидку), — в нашем случае покупатель получал купон за внутренние бонусы сервиса «КупиКупон». Бонусы накапливаются при участии в других акциях, поэтому получается, что покупатель не платил реальные деньги за наши купоны.

Бонусные акции, в отличие от стандартных, не публикуются на главной странице купон-сервисов, и рассчитаны только на постоянных пользователей купон-сервиса. Интерес «КупиКупона» в бонусных акциях (ведь он за них не получает реальные деньги) — представить разнообразное, качественно отличное от «шиномонтажей» и «салонов красоты» предложение. Мы решили, что для пробы это будет самым подходящим вариантом акции. Плюс, в случае бонусной акции наши затраты были минимальными: мы не платим «КупиКупону» никакой комиссии и просто получаем новых посетителей, которым должны предоставить скидку. Скидка по купонам была установлена в размере 50% — меньшую скидку нельзя поставить по правилам «КупиКупона», а при большей скидке мы бы полностью работали в убыток. Со скидкой в 50% получалось, что в среднем мы продаем продукты по их себестоимости: некоторые продукты выходили «в минус», некоторые — «в плюс».

Итак, мы заключили договор с «КупиКупоном», и на их сайте появилась статья о нашей акции. Статья полностью написана сотрудниками «КупиКупона»: http://www.kupikupon.ru/deal/megapodarki_3872

Реализация на стороне магазина

Наш магазин работает на основе веб-сервиса Shop-Script, и для организации предоставления скидок по акции мы ничего не программировали — просто использовали стандартный механизм купонов на скидку, который предоставляет Shop-Script. «КупиКупон» предоставил нам приобретенные пользователями коды купонов в виде XLS-файла, и купоны из этого файла мы вручную создавали в магазине в режиме администрирования. Было, конечно, не очень удобно вручную добавить полторы тысячи купонов, зато все заказы уже автоматически рассчитывались со скидкой. Впрочем, на добавление купонов ушло всего около часа-полутора (в новой версии Shop-Script будет возможность импорта купонов из файлов — прим. ред.).

Результаты

О результатах акции лучше скажут цифры и графики.

Читать далее →

22 комментария

Работа над приложением «Сайт» близится к завершению.

Несмотря на то, что мы сами уже давно пользуемся этим приложением (например, сайт webasyst.com был открыт на основе «Сайта» еще в июне), для того, чтобы довести приложение до выпуска, потребовалось довольно много времени: было разработано несколько новых системных механизмов во фреймворке, которые будут использоваться другими приложениями для построения сайтов.

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

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

Например, «Блог» можно поселить по адресу /blog/*, а основной сайт — в корневой директории (/*). Все будущие приложения — Shop-Script, «Фото», «Форум» и прочие — будут легко добавляться в уже работающий сайт. Для этого нужно будет после установки приложения через «Инсталлер» поселить его: указать, по какому адресу оно должно открываться.

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

Во-вторых, это единый дизайн-редактор, который позволит через браузер редактировать шаблоны дизайна всех приложений, интегрированных с «Сайтом». Выглядит это примерно так:
Читать далее →

7 комментариев

Пока фреймворк находится в альфа-версии, и готовых полезных приложений всего одно-два, процесс разработки приложений для фреймворка имеет характер исследовательской дейтельности. Работа очень увлекательна, но в определенном смысле мучительна. Решение большинства текущих задач по фреймворку сводится к поиску паттернов, которые впоследствии будут применятся или рекомендоваться к применению в других приложениях. Например, приложение «Сайт» с дизайн-редактором, который должен подойти и для «Блога», и для шаблонов email-уведомлений, и для будущего Shop-Script; приложение «Блог» с плагин-структурой, архитектура которой должна подойти для многих других приложений; приложение «Поддержка», на котором отрабатывается системный механизм рабочих процессов (workflow); API, актуальный практически для любого приложения Вебасиста и т.п. Требуется много пробовать и принимать довольно ответственные решения, поэтому выпускать новые приложение не получается так быстро, как бы нам этого хотелось (например, как были сделаны «Списки дел»).

Расскажу немного о том, как мы разрабатываем приложения, из каких этапов состоит разработка. Опыт нашей команды в разработке веб-приложений насчитывает уже более десяти лет. В разное время мы пробовали всяческие подходы к веб-проектам: и писали с нуля, и на основе готовых решений, делали проекты для хостирования у себя, для хостирования где бы то ни было, и с подробными техзаданиями, и с зарисовками только на листочках. При разработке мы никогда жестко не придерживались каких-либо методологий разработки, таких как agile или waterfall, и не придерживаемся сейчас. Процесс у нас ближе, пожалуй, к agile, но не является таковым в чистом виде. Это отдельная тема, и о ней как-нибудь в другой раз — сейчас же расскажу о этапах, из которых состоит разработка каждого приложения на основе фреймворка Вебасист.

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


  1. Проектирование и дизайн.

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



    Мы не пишем никаких подробных техзаданий. Иногда делаем короткие PDF-файлы с описанием отдельных мыслей, но стараемся обходится и без этих файлов. Техзадание, фактически, готовится в виде макета интерфейса, по которому потом сразу ведется программирование. HTML-макет сделать быстрее, чем описывать то же самое словами. На макете сразу можно опробовать разные варианты оформления, затраты на корректировки минимальны. Также удобно коллективно обсудить, как будет выглядеть приложение.

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


  2. Программирование и тестирование.

    
Тут ничего нового: разработка структуры БД, программирование, трекер заданий, задачи, тестирование, задачи, тестирование.


  3. Внедрение.

    

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

    На самом деле, вообще мало кто из разработчиков отводит время на то, чтобы внедрить свой продукт для себя и попробовать попользоваться им — вместо этого стараются побыстрее выпуститься, а уж пользователи потестируют. Я с таким подходом не согласен принципиально, и поэтому считаю третий этап внутреннего внедрения нашим «секретным оружием».



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

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

Так чего особенного и нового в таком делении на этапы разработки? Нового, пожалуй, ничего. Особенного — тут стоит выделить два ключевых момента: это наличие всех трех этапов и их независимость.

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

Этапы проектирования и внедрения — такие же необходимые, как этап программирования. Уделив больше внимания изначальному проектированию, гораздо дешевле обойдется этап программирования: на этапе проектирования проще попробовать реализовать один интерфейс, другой, посмотреть, где сделать, например, с перезагрузкой страницы, где с AJAX, как придуманный интерфейс будет воспринят сотрудниками, которые будут работать с приложением и т.д. Если четко определен результат первого этапа, второй можно сделать очень и очень быстро. Поторопившись же с первом этапом, можно просто увести весь проект не в ту сторону. Не попробовать потом продукт на себе — заниматься после выпуска сбором жалоб и выпуском ненужных патчей.

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

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