хочется немного обсудить yii

[whirlwind]

grigori Ваши посты я "не читал", но я их и не обсуждаю. Я "осуждаю" yii, но я читал его код. И отвечал на твой первый пост, в котором тебе код гармоничен. Или это ты написал в беспамятстве? Я тебя не понимаю, извини.

 

[grigori]

ты пишешь про zii - виджеты, не про сам фреймворк
аналогия - jQueryUI и jQuery

первое - отстой, и фреймворки поощряют его, мне это не нравится, но ядро при этом неплохое
тут много дерьма, особенно если искать, я не спорю,
я смотрю на yii как на набор инструментов, одни я использую, другие - нет

а что ты посоветуешь?

 

[whirlwind]

Не в моих правилах давать советы не зная задачи. Могу только в общем описать свою ситуацию и рассказать почему нам не подходят известные мне готовые решения. У нас за многие годы сложились свои наработки, которые кочуют из проекта в проект. В основном это адаптеры и врапперы под недружественное ООП-окружение, которое PHP предоставляет as is. Сюда же относятся достаточно устойчивые интерфейсы типа фронт-контроллера, контроллеров, acl, различных фабрик, валидаторов, request/response, типовых реестров, базы persistent и тп. Все это у нас за устойчивыми интерфесами, нам без этого никак - мы их мокаем при тестах логики более высокого уровня иначе слишком тяжелые фикстуры получаются. У нас очень мало классов предметной области кочуют из проекта в проект. Во-первых это завязано на специфику наших проектов. Во-вторых, так как у нас TDD, нам все примочки в виде кодогенерации по базе или масса конфигов, увеличивающие порядок неподконтрольных инвариантов и все это без тестов просто не приемлимо. По одной простой причине - это трудно контролировать и все равно нуждается в тестировании. А охватить все инварианты тестами это ~ 80% от кода, так что нам любая кодогенерация - просто тьфу, по сравнению с надежным тестом. Последнее и самое весомое - все что я видел работает по принципу протокола. То есть, нам пытаются навязывать как делать, вместо того, что бы дать возможность выбирать где делать. Из-за этого практически все исследованные мною фв просто не поддаются тестированию прикладного уровня. На самом деле хороший фв - это просто набор реализаций паттернов и ничего большего не требуется. У нас так и получается на практике. Все остальное - частности, которые никакой фв не в силах удовлетворить.

 

[grigori]

тебе нужен не фреймворк, а библиотеки в стиле С

да, мир идет по пути навязывания протоколов
протоколы конкурируют и развиваются естественным отбором,
сейчас, кажется, 3е поколение фреймворков, вдохновленное успехом ROR с принципом "делай как я"

 

[MiksIr]

Я тут вернулся к Yii и сподобился разобраться как работает аутентификация у них. В общем, срочно проверить есть ли deny all, а у кого fpm - есть ли правила против доступа к protected. Раскрытие runtime/state.bin приведт к возможности подмены пользователя, если авторизация через куки.
Нужно в куки еще какой-нить пароль захешированный положить, что ли на всякий случай и его валидировать.

 

[grigori]

1. protected/ используется для примера, ее надо выносить из document_root вне web-доступа (у меня это папка app рядом с htdocs), никакой привязки к имени или путям нет
2. у меня нет файла runtime/state.bin

3. аутентификация есть 2х видов: ACL и так называемый фильтр (массив правил)
все стандартное можно реализовать через фильтр
например, в config/main.php в 'params' задать список админов 'admins'=>array('admin',),
и можно писать правило для действий админов

    public function accessRules(){
        return array(
            array('allow',
                'users'=>yii::app()->params['admins'],

а вот проверка на принадлежность пользователю редактируемой записи с лямбда-функцией

			array('allow', // allow author to perform actions
				'actions'=>array('update','delete','updateProcess'),
				'users'=>array('@'),
				'expression'=>function() use ($Post){
			            return $Post->Model->user_id == yii::app()->user->id;
				    },
			),

 

[MiksIr]

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

 

[grigori]

я имел ввиду авторизацию

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

да, yii не для новичков, конечно ... вынесение приложения из docroot-а в нем подразумевается как очевидное и даже не документировано,
ну, вот дока:
в index.php вместо $config=dirname(__FILE__).'/protected/config/main.php';
пишешь $config=__DIR__.'/../my_application_path/config/main.php';

строчкой выше пишешь свой путь к папке с файлами фреймворка
у меня это $yii=__DIR__.'/../yii/yii.php';

 

[MiksIr]

Выносить полезно, но не критично, если уж устраивать холивар, так устраивать. В большинстве случаев никакого вреда от этого нет, даже если не делать блокировку доступа вебсервером.
Просто Yii для аутентификации использует подписанные куки, а ключ для подписи хранится в так называемом globalState - это и есть этот файлик.
То, что у тебя его нет говорит, скорее всего, что ты используешь свою аутентификацию... ну или не используешь автологин. CWebUser->login() делает как раз этот сейв.

 

[grigori]

еще нельзя в docroot-е размещать файлы sqlite

я в своей работе подразумеваю размещение приложения вне docroot-а всегда, когда нет причин делать иначе, чтобы не зависеть от настроек сервера

 

[Redjik]

не холивара ради, а справедливости для, я отдаю свой голос за xPDO

 

[grigori]

и каким боком некая java-подобная обертка с xml-маппингом относится к фреймворку yii?
за обсуждением разного мусора идите на хабр

 

[Ragazzo]

grigori
чем тебе не нравится использование регулярок в Yii, кроме пресловутого переполнения?вся суть претензий в том что в filter_* нет такого, а в регулярках есть?

 

[grigori]

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

 

[Ragazzo]

grigori
Какие-то невесомые аргументы...если посмотреть как там реализовано, то что-то я сомневаюсь что "веб-сервис можно положить скриптом из 5ти строк без затрат вообще"
фильтры тоже хорошо, но регулярки гибкие...во всех почти фрейм-х реализовано через регулярки...
P.S не холивара ради - "на вкус и цвет..."

 

[grigori]

я сделаю тесткейз и, если он будет работать, запощу багрепорт на форум yii
твое мнение неинтересно

 

[grigori]

чтобы не быть голословным, возьму стандартный валидатор URL в классе CUrlValidator
вот его регулярка:
$pattern='/^(http|https):\/\/(([A-Z0-9][A-Z0-9_-]*)(\.[A-Z0-9][A-Z0-9_-]*)+)/i';

передача скрипту, в котором используется этот валидатор, вот такой строки длиной 4 килобайта вызывает сегфолт:
$str = 'http://w'.str_repeat('.a',4000).'.ru';

подобную строку можно составить для валидатора email, который используется при регистрации на всех сайтах

а вот интересно, насколько тяжел рестарт php-процессов после сегфолта со всеми логами - если, например, в 30 соединений одновременно положить всех воркеров

 

[Активист]

> $pattern='/^(http|https):\/\/(([A-Z0-9][A-Z0-9_-]*)(\.[A-Z0-9][A-Z0-9_-]*)+)/i';
Нда. И на PHP 5.3.7-dev валится в кору.

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

<?php
$pattern='/^https?:\\/\\/([a-z0-9][a-z0-9\\-\\.]*\\.[a-z]{2,10})/i';
$subject = 'http://w'.str_repeat('.a', 1*1024*1024*60/2).'.ru';
var_dump(preg_match($pattern, $subject, $matchs));
?>

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

Ну на крайняк (double dots dismatch) можно что-нибудь подобное сделать, провда работать будет медленнее, но падать не будет.

<?php
$pattern='/^https?\\:\\/\\/([a-z0-9][a-z0-9\\-\\.]*\\.[a-z]{2,10})/i';
$subject = 'http://w'.str_repeat('.a', 1*1024*1024*60/2).'.ru';
var_dump(
	preg_match($pattern, $subject, $matchs) && !preg_match("/(\\.)\\1/", $matchs[1])
	);
?>

Вообще крайне интересная тема хакинга через реги.

 

[grigori]

Активист речь о дырке во фреймворке
легко валятся регулярки, в которых есть субпаттерны с модификатором неограниченной повторяемости ()* или ()+
регулярки - это не плохо, это инструмент с документированными ограничениями, они создавались для других целей
http://phpclub.ru/talk/threads/Почему-у-меня-падает-сервер.66410/#post-590975

email и url надо проверять не регуляркой, а конечным автоматом

все стандартные проверки нормально реализованы в filter_var() - функции, которая для этого создана
использование тут регулярок считаю неправильным
но аффторы yii в обсуждении перехода на filter решили, что его регулярка лучше, чем та, что используется в filter
(и уже добавили проверку на размер данных)

 

[grigori]

>Вот аналог выше реги, попробуйте отправить в кору.
это не аналог, это неправильная регулярка
$subject = 'http://y.--.ru123' -> корректно
на регулярке ты нормальную проверку URL/email без сегфолта и очевидных недочетов если и напишешь, то намучаешься