Защита веб-приложения на Phalcon + AngularJS от CSRF атак

[akalend]

Интересно, человек предложил решение, а ему наставили минусов. За что?

[kimonniez]

Я не граммар наци, но, возможно, за это и подобное:

Ложим токен в meta данные

Или за:

А что делать если формы две? Идите на форум, ищите решение,

Я лично, надеялся увидеть решение проблем Phalcon'овских токенов, а меня либо отправляют обратно на форум, либо констатируют известные проблемы с перегенерацией токенов в новом окне и т.п.

А в целом, могу предложить автору (да и всем желающим) от себя редактуру текстов на общественных началах. Обращайтесь)

[chuikoffru]

Спасибо за фидбэк, не думал что тут всё так строго. Поправил текст.

[akalend]

Я не граммар наци, но, возможно, за это и подобное:

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

[chuikoffru]

Простите, ни разу не сталкивался с этими граблями.

[chuikoffru]

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

[chuikoffru]

Спасибо, поставил бы плюсик, да кармы не хватает.

[andrewnester]

1. Если человек захочет посмотреть исходный код страницы (не через firebug, а в отдельном окне), то при загрузке с генерируется новый токен, и вернувшись на страницу ни один запрос не будет обработан. Возможно это и хорошо, нечего лезть в исходный код.

да я думаю просто, если пользователь откроет ту же (а может даже и любую) страницу вашего приложения в новом табе, то в старом табе уже AJAX запросы работать не будут, верно?

[chuikoffru]

Да верно, токен хранится в сессии пользователя.

[kriptomen]

А вы не ошибаетесь? Сессия не зря так названа, это серия запросов от одного пользователя, неважно из какого количества вкладок одного браузера (не считая режима «инкогнито»). Если бы токен основывался на сессии, то он был бы идентичен на протяжении всего сеанса пользования приложения.
Поправьте, если ошибаюсь я.

[m00t]

Поправьте меня, пожалуйста, если я не прав. Мне кажется, что в AngularJS не спроста нету CSRF из коробки. Потому что когда вы делаете API, делать в нем аутентификацию при помощи кук это как-то странно ИМХО. Я думаю, лучше этот токен хранить где-то в Local Storage, например, и посылать его со всеми запросами в заголовках, тогда никакие CSRF будут не страшны.

[ramzes_yan]

меня давно интересует эта проблема (без привязки к фреймеворку или языку)
лучшее что я нашел auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

[hospect]

Немного оффтоп, но все же. У вас есть серьезные причины не использовать шаблонизатор? Просто

<?php echo $this->blablaObject->getBlablaId(); ?>

смотрится не очень в шаблоне.

[chuikoffru]

Да есть причина. У AngularJS и шаблонизатора Volt Phalcon одинаковый синтаксис. Они оба используют {{переменные}} в двойных скобках. На форуме было решение, но мне проще использовать чистый PHP, да и он побыстрее будет ;)

[franzose]

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

[student_ivan]

angular.module('application').config(function ($interpolateProvider) {
    $interpolateProvider.startSymbol('{[{');
    $interpolateProvider.endSymbol('}]}');
});

[kriptomen]

angular.module('application').config(function ($interpolateProvider) {
    $interpolateProvider.startSymbol('[[');
    $interpolateProvider.endSymbol(']]');
});

Делаю так, проще и приятнее глазу. Но это нюансы.

[lucky_libora]

а почему не рассматривается решение через стандартный метод AngularJS?

https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection