Mojolicious::Plugin::RenderFile для отдачи файлов

Стояла задача дать пользователю возможность скачать файл. Покопавшись в документации, я нашел 2 варианта - хелперы "render_data" и "render_static". Оба варианта мне не подошли. 
"render_data" - принимает строку, а я не хотел вычитывать весь файл в память.
"render_static" - отдает файлы с "public" директории.

render_file 

Интернет предложил различные варианты решения проблемы, но какого-то удобного я не нашел, решил написать свой хелпер. Хелпер должен был уметь отдавать файл по абсолютному пути с любой папки без вычитывания файла в память, и чтобы браузер предлагал пользователю файл сохранить, а не пытался рендерить. Так появился "render_file". Используется он так:

# Provide any file name
$self->render_file(
    filepath => '/tmp/files/file.pdf',  
    filename => 'report.pdf'
);

Дальше »

Валидация данных в Mojolicious

Написал небольшой плагин для Mojolicious  - Mojolicious::Plugin::ValidateTiny. По сути - это обертка над Validate::Tiny с дополнительными удобными плюшками.

Для валидации входящий параметров мы просто используем хелпер:

$self->do_validation($validate_rules);

$validate_rules - это описание проверок в формате Validate::Tiny.

По-умолчанию, включена опция "autofields", которая позволяет использовать сокращенный вариант правил проверки. И вместо:

  {  
     fields => ['user', 'pass'],
     checks => [user => is_required(), pass => is_required()] 
  }

можно писать:

 [ user => is_required(), pass => is_required() ]

и fields автоматически заполнятся исходя из описания проверок.

Также очень полезна опции "explicit", которая обязывает нас описать явно правила валидации для каждого поля. По-умолчанию, выключена, но в своих проекта я всегда ее включаю.

Кроме хелпера "validator_error", есть еще хелпер "validator_any_error".

  my $errors     = $self->validator_error;         # hashref with errors
  my $pass_error = $self->validator_error('pass'); # password error text
  my $any_error  = $self->validator_any_error;     # any error

Дальше »

Mojlicious: Использование роутов в javascript

Мне нравится, как реализованы роуты в Mojolicious и особенно мне нравится то, что их можно именовать. Именую я роуты всегда в соответствии с именем контроллера и метода.
Например,

$r->get('/messages/:id')->to('messages#show')->name('messages_show');
$r->post('/messages/:id/delete')->to('messages#delete')->name('messages_delete');

И затем в контроллере:

$self->redirect_to('messages_show', id =>123);

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

var some_id = 123;
$.getJSON('/messages/' + some_id, function(data){ ... });
$.post('/messages/' + some_id + '/delete', function(data){ ... });

Хотелось бы иметь возможность использовать имена роутов и на клиентской стороне. Для этой задачи и был написан плагин "Mojolicious::Plugin::JSUrlFor". Достаточно добавить в основной ваш лейаут:

<%= js_url_for %>

и в клиентском javascript-е будет доступна функция "url_for"( аналогична хелперу "url_for" с "Mojolicious::Plugin::DefaultHelpers"):

var some_id = 123;
$.getJSON( url_for('messages_show', {id:some_id}), function(data){  } );
$.post( url_for('messages_delete', {id:some_id}), function(data){  } );

Модуль "Mojolicious::Plugin::JSUrlFor" пока еще только на Github, но заброшу на CPAN сразу, как покрою тестами.

Mojolicious и защита от Cross Site Request Forgery (CSRF)

Немного теории

Я полагаю многие знают, что такое CSRF. Но для новичков озвучу. CSRF (Cross Site Request Forgery) - это межсайтовая подделка запросов. И происходит она следующим образом.

Допустим, на вашем сайте, назовем его "mysite.com", есть ссылка, которая удаляет сообщение. Ссылка вида - "http://mysite.com/myprofile/delete?message=123".

Злоумышленник может вставить эту ссылку на свой сайт "attackerssite.com", например,  в виде картинки -

<img src="http://mysite.com/delete?message=123" />

И если Вы зайдете на "attackerssite.com", то будет отправлен запрос на загрузку картинки с вашего сайта, но вместо загрузки картинки будет удалено сообщение. Проблем с авторизацией не будет, так как будет отправлена ваша кука, запрос же отправляется с вашего браузера.

Таким образом возможно подделать абсолютно любой запрос.
Есть разные методы борьбы с этим, но реально работает только один - необходимо с каждым запросом,  который изменяет данные, посылать секретную строку.
Эта строка должны быть уникальна для каждой сессии.

Дальше »

Запускаем Mojolicious/PSGI приложение: мини-тест производительности.

Решил провести небольшое тестирование производительности Mojolicious  в разных режимах:

1. Mojo::Server::Daemon (Epoll/Poll)
2. Mojo::Server::Hypnotoad (Epoll/Poll)
3. Mojo::Server::PSGI + Corona
4. Mojo::Server::PSGI + Starman
5. Mojo::Server::PSGI + Starlet
6. Mojo::Server::PSGI + Plack::FCGI::Handler

Хотелось еще протестировать nginx+uwsgi, но не сложилось. Возможно в следующий раз.

Как проводилось тестирование 

Тестировалось приложение, которое просто возвращает строку "OK". Также, в тех же условиях, тестировалось минимальное PSGI приложение. Основной задачей было узнать наиболее производительный режим запуска. 
Все запросы к приложению проксировались через nginx - 4 воркера по 1024 конекшенов максимум. Тестировалось при помощи утилиты "ab". Результат считался как среднее арифметическое по 3 запускам теста. 10000 запросов на тест.

Дальше »

Развертываем Perl приложение на DotCloud

Немного про PSGI

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

Как выглядит PSGI приложение?

PSGI приложение это просто ссылка на функцию. Эта функция принимает ссылку на хеш с описанием окружения и возращает ссылку на массив с трех элементов(статус, хидеры, боди)

sub app {
    my $env = shift;
    return [
        '200', 
        [ 'Content-Type' => 'text/plain' ],
        [ "Hello World" ], # or IO::Handle-like object
    ];
}

Если хотите попробовать, то установите себе Plack c cpan и запустите:

plackup  -e 'sub {my $env=shift; return [200, [Content-Type => "text/plain"], ["Welcome home, $env->{QUERY_STRING}"]] }'

Затем откройте в браузере http://localhost:5000/?Dude

Приложения на базе Mojolicious и Dancer  умеют работают в режиме PSGI.

Теперь ближе к сабжу - разворачиваем наше приложение

Dotcloud - это платформа для развертывания ваших приложений. C Dotcloud Вы можете забыть про настройку веб-сервера. Просто выполняем "dotcloud deploy myapp" и приложение готово к использованию :). Для примера,  возьмем приложение c поста - "Пример приложения на Mojolicious ( не Lite )". ( Предварительно необходимо завести себе аккаунт на dotcloud.com и установить клиент - sudo easy_install dotcloud. )

Дальше »

Mojo::JSON для сессий в Mojolicious

Сейчас Mojolicious использует Storable для сериализации сессий, но Себастьян решил перейти на Mojo::JSON и мне нравится эта идея :). Я приверженец формата JSON и уже упоминал его преимущества в посте "Как устроены сессии в Mojolicious?!". Проблемы могут возникнуть только у пользователей, которые хранят в сессии блесснутые(blessed) ссылки.

Тикет с обсуждением на гитхабе.

Mojolicious 1.16: Экстренный релиз, Всем обновляться!!!

Час назад стало известно про серьезную уязвимость в Mojolicious, которая позволяет вычитать любой файл с файловой системы.
Баг уже исправлен, к сожалению баг был опубликовал в твиттере перед тем как передан Себастьяну.
Все срочно обновляемся!!!! Но учтите, что новый релиз не сразу попадет на все зеркала CPAN, лучше качайте прямо с официального сайта.

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

Дополнительная информация:

• Ссылка на описание бага
• Сообщение от Себастьяна

Mojoliciuos - Производительность Mojo::JSON

Mojo::JSON VS JSON::PP

Решил проверить производительность Mojo::JSON
Интересовала, естественно, производительность в сравнении с JSON::PP.
Колоссальная производительность JSON::XS лишает смысла сравнивать его с перловыми реализациями.

Результаты

Тестирование показало, что Mojo::JSON в 1.5 раза быстрее чем JSON::PP при сериализации и в почти в 3 раза быстрее при десериализации. Очень даже неплохо.
Естественно, JSON::XS вне конкуренции, он в 40 раз быстрее чем Mojo::JSON при сериализации и в 30 раз быстрее при десериализации.

Если мы посмотрим на абсолютные цифры производительности Mojo::JSON, то 3-5 тыс вызовов в секунду хватит для большинства проектов. Кроме того, в тесте использовалась достаточно сложная структура данных.  Ну и всегда можно переключится на JSON::XS

Дальше »

Встречайте Mojolicious::Plugin::Gravatar

Написал небольшой плагин для Mojolicious - Mojolicious::Plugin::Gravatar . Добавляет хелперы для работы с Gravatar.com.  Думаю многие знакомы с этим сервисом( его используют cpan и github ), но кто не знаком - обратите внимание.

Для отображения аватарки  - <%= gravatar $email %>
Для получения url аватарки - <%= gravatar_url $email %>

Плагин уже на GitHub и на CPAN 

Mojolicious - интервью с Себастьяном Риделем( Sebastian Riedel )

Мой перевод интервью ActiveState с Себастьяном Риделем( Sebastian Riedel ), создателем веб-фреймворка Mojolicious. Это достаточно свободный перевод, но я старался не потерять суть.

14.02.2011 Себаcтьян зарелизил Mojolicious 1.1 - Perl веб-фреймворк следующего поколения. В связи с этим и состоялось интервью.

Tara: Почему ты занялся созданием Mojolicious?

Sebastian: По большому счету это случилось случайно. Стартовал Mojolicious в конце 2008 под названием Mojo, как фреймворк для  разработчиков веб-фреймворков. Он должен был решить многие проблемы архитектуры Catalyst и подразумевался как замена для его устаревающих внутренностей. Но когда текущие мейнтейнеры Catalyst отказались от использования Mojo, то я решил показать его ценность, создав но его основе пример  веб-фреймворка.
Затем этот пример под названием Mojolicious превысил все ожидания, и я никогда не пожалел о случившемся.

Tara: Какие уроки приобретенные во время работы над Catalyst, оказались полезными при создании Mojolicious?

Sebastian: Я полагаю, что наиболее важным уроком, который я выучил, было искусство построения сообщества. Активное сообщество является наиболее ценным активом для любого фреймворка и является основной его популярности. И хотя  Mojolicious очень молодой проект, но у нас уже второе по размеру сообщество среди всех веб-фреймворков на Perl, мы идем сразу за Catalyst.

Tara: Есть ли какие-то примеры действующий проектов на Mojolicious? Какого рода проекты создаются при помощи Mojolicious?

Дальше »

Как устроены сессии в Mojolicious?!

В этом посте я не буду рассказывать про API для работы с сессиями, это можно найти в документации к Mojolicious, а постараюсь объяснить как устроены сессии внутри.

Mojolicious использует сookies для хранения сессий. И это достаточно важный момент. Такой подход позволяет нам следовать REST идеологии. Мы можем отказаться от лишних состояний на стороне сервера, нам не нужно обеспечивать общего пространства для доступа к сессиям с разных серверов.

Но имеется несколько важных нюансов:

1. Старайтесь не делать сессии большими, поскольку эти данные будут передаваться при каждом запросе, а максимально безопасный размер cookie - 4кб.
2. Вопрос авторства данных.

С первым пунктом все ясно, а относительно второго, то это решается либо шифрованием либо подписью cookies. Mojolicious использует подписанные(signed) cookies.

Что должна обеспечивать подпись?

Начнем с того, что любая подпись (включая подпись ручкой на бумаге) должна обеспечить следующие две вещи:

1. Идентифицировать автора подписи.
2. Гарантировать, что после того, как документ подписали, он не изменялся.

Подписанный документ не подразумевает того, что он должен быть зашифрован. Соответственно подписанные cookies не обязаны быть зашифрованными.
Мы оставляем документ в открытом виде и лишь добавляем к нему подпись(цифровую или ручкой на бумаге)

Дальше »

Ура, товарищи. Вышел Mojolicious 1.0

Список изменений по этой ссылке

Хотя в твиттере Себастьяна видим:
"#mojolicious 1.0 is scheduled for december 26! #perl"

Пример приложения на Mojolicious ( не Lite )

Пример приложения на Mojolicious ( не Lite )

В интернете много всего уже сказано про Mojolicious::Lite, но сегодня про Mojolicious (не Lite). С фреймворком я только начал знакомится, поэтому смело критикуйте в комментариях. Для изучения фреймворака я решил написать прототип сервиса заметок. Сразу прошу не писать про XSRF,  я в курсе и это лишь прототип. Расписывать все я не буду, только ключевые моменты. Основную информацию Вы сможете почерпнуть непосредственно из кода.

Почему Mojolicious?

Mojolicious - очередной MVC веб-фрейворк. "Очередной велосипед, хоть и с более круглыми колесами", как кто-то он нем отозвался на одном из форумов.

Дальше »