DaNHell: нерабочая форма - это какой-то страшный сон.
Но всё равно не понимаю каким образом можно подделать цсрф. Этож надо найти уязвимость, которая позволит прочитать хттпонли куку (т.к. подобрать 32+ символьный ключик за время сессии и найти уязвимость, которая позволит из адресной строки пробросить её в кукисы - сложнее), т.е. фактически взломать сервер, но в таком случае ломать сервер ради обхода цсрф - как-то глупо.
При каждом запросе - это чушь какая-то, ибо можно открыть что-то на новой вкладке и тогда форма станет невалидной. Может вы имели ввиду "в течение одной сессии"?
Увидел в исходниках коммент:
/* usage:
* deplister.exe path\to\module.exe path\to\symbols\root
* */
Попробовал - очень похоже на то, что оно выводит список тех .dll, которые требуются в exe. Думаю вопрос закрыт.
@Fesor, неа. Как выяснилось гуглением - это немного другая очистка кеша, а именно всех данных, записанных с помощью методов класса Cache::* ( laravel.com/docs/cache ), так что нужна именно очистка директории ручками.
Вы правы, документация стрёмная. Потратил пол часа, что бы найти группы сериализации - не нашёл, есть вариант потыкать меня носом? Или исходники стоит смотреть?
З.Ы. Фрейм Laravel 4, но это думаю не существенно.
Насколько я понял он ориентируется по аннотациям класса сериализуемой модели, верно?
Функционал скрытия данных при сериализации модели уже присутствует внутри фреймворка, который я использую, но проблема в том что в разных местах требуется получать разные данные, используя одну и ту же модель, т.е. отвязаться от унификации данных и фильтровать их на ходу.
Пока набросал примерчик "в лоб": pastebin.com/AeuGMwET Но как понятно - он очень простой и не позволяет строить сложные структуры, т.е. на каждый чих придётся лезть в исходники и править их.
Я старательно пытаюсь поведать требования, которые исходили из возможности индексации страницы, что я и сообщил в вопросе (может немного иносказательно). То что это ria - очевидно, иначеб и вопроса подобного не возникало. Просто в результате я пришёл к идее, вместо разделения статики (с помощью указанного вами выше PhantomJS, например, или серверного шаблона) и клиентского (Knockout, Angluar, etc...) - просто их совместить в одном движке. А то что данные приходят из JSON ответа от сервера или из контроллера - волновать особо не должно. Данные они и в Африке данные.
На ресурсе происходит редзайн, вместе с этим решили переписать фронт-энд. Основная цель всего этого мероприятия, помимо более вменяемого кода — уменьшить траффик, который забивает канал хостинга, проблема пока только в поисковиках и в пользователях без js. По этому ищу наиболее вменяемое и простое решение для этой проблемы.
Ну на счёт моделек и контроллеров — это да. Кодогенерация — плохое решение всегда (если конечно это не специально заточенный DSL). Только контроллеры в любом случае будут отличаться — всё же логика разная — одно — просто передача данных и обработка гет\пост событий — другое — обработка пользовательских событий, анимашки всякие, финтифлюшки и прочее, общее — только указание аргументов шаблону. Чисто теоретически — от клиентских моделей при таком подходе — тоже можно отказаться — передавать данные сразу в контроллер, пусть это и повышение объёма загружаемых json данных за счёт дублирования повторяющихся данных, да и сам подход, прямо скажем — не очень, но уменьшение объёма работ и гарантированная актуализация данных. А если заиспользовать вебсокеты, то разницы практически не будет заметно, что 5 килобайт, что 10. В общем это довольно спорный вопрос — единственное что действительно будет дублироваться — это роуты.
Но всё равно не понимаю каким образом можно подделать цсрф. Этож надо найти уязвимость, которая позволит прочитать хттпонли куку (т.к. подобрать 32+ символьный ключик за время сессии и найти уязвимость, которая позволит из адресной строки пробросить её в кукисы - сложнее), т.е. фактически взломать сервер, но в таком случае ломать сервер ради обхода цсрф - как-то глупо.