Yii Framework core developer
24,8
рейтинг
SilverFire
+1

Если у вас есть публичные проекты, в которых разрешены email'ы по всем канонам RFC — поделитесь, пожалуйста, количеством пользователей, адреса которых не проходят валидацию по регулярке из EmailValidator в Yii.

SilverFire
+3

Да, это так. В реальной повседневной жизни этот RFC интерпретируется всеми по-своему, что приводит к разным реализациям валидаторов.


Учитывая, что пользователей с вычурным адресом по RFC ничтожно мало, нам проще пожертвовать ими в пользу безопасности.

SilverFire
+2

Кроме того, название MultiLang мне не кажется само-описывающим. Пока не откроешь код, сложно однозначно сказать, что делает этот класс. Что-то про мультиязычность, но что именно?
Я бы его назвал LanguageSwitcher. Согласитесь, сразу понятно, что это переключатель языков, не так ли?


Если всё таки использовать composer и подключить оригинальное расширение, можно еще больше упростить себе жизнь. Структуру директорий можно свести до такой:


frontend\
    widgets\
        LanguageSwitcher.php
        views\
            languageSwitcher.php

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

SilverFire
+4

Спасибо за ваши старания, позвольте высказать свою критику по поводу архитектурных решений.


'frontend\widgets\MultiLang\components\UrlManager'

Предложенная иерархия директорий (и неймспейсов) не укладывается в хорошие практики. Виджеты — это виджеты, а компоненты — это компоненты. Если у вас есть компонент, а рядом с ним — виджет для работы с этим компонентом, при этом существует общая предметная область, с которой ведется работа — это больше похоже на расширение.


Я бы предложил выделить это в отдельный репозиторий, или (если не планируется переиспользование) — разместить код в вашем проекте таким образом:


frontend\
    extensions\
       MultiLang\
      Components\
        UrlManager.php
      Views\
        View.php
      Widgets\
            MultiLang.php

содержание файла взято отсюда, можно следовать инструкции разработчика и использовать composer, но мы то делаем виджет, по этому просто скопируем UrlManager.php в наш виджет

Копируя UrlManager.php в свой проект, вы лишаете себя чудесной возможности получать обновления с улучшениями и исправленными ошибками из оригинального репозитория. Отказ от использования composer в пользу копи-пасты — один из самых вредных советов для PHP разработчика в 2016 году.


Что касается кода виджета:


use yii\helpers\Html;

class MultiLang extends \yii\bootstrap\Widget
{
    public $cssClass;
    public function init(){}

    // ...
}

Класс \yii\bootstrap\Widget находится в отдельном репозитории yii2-bootstrap и наследуется от yii\base\Widget, добавляя некоторые методы для работы с Frontend-фреймворком Bootstarp. Вы не используете никаких возможностей этого класса, достаточно будет наследования от yii\base\Widget.
Кроме того, вы указали лишний use и без какого-либо смысла предопределили метод init().


В коде представления вы указали use Yii;, но каждый раз при обращении к Yii явно указываете namespace:


\Yii::$app->request->get()

Да и если следовать правилам распределения ответственности в MVC, представление не должно "добывать" данные самостоятельно — данные должен собрать тот, кто вызывает рендер представления. Было бы уместно избавится от обращения к компонентам request, controller и свойству language из представления, а перенести это в виджет.

SilverFire
+2

На уровне обработчиков событий XHR запросов. Код тут

SilverFire
0

На странице https://www.leakedsource.com/blog/vk в разделе Passwords написано следующее:


Passwords were stored in plaintext with no encryption or hashing. The methods VK used for storing passwords are not what internet standards propose because hackers can now see all 100 million passwords used on the site.

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

Не хочется верить что в таком крупном и относительно взрослом проекте применяются такие небезопасные подходы. Хотя все подробности указывают на то, что сказанное выше — правда. Как-то совсем тупо получается :(

SilverFire
0

То ли дело программировать ради решения задачи, забыв в том, что к коду еще придётся вернуться. Тогда гарантировано можно показать примеры своих работ, но главное — не показывать код :)

SilverFire
0

Истину глаголите, сударь :) ORM — инструмент, а любой инструмент нужно использовать с умом

SilverFire
+10
Тогда мы вынесли этот функционал в виде глобальной фунцкции в отдельный файл includes/sms.php и спокойно использовали в разных модулях в таком виде

На дворе 2016 год, уже 5 лет как существует Composer. Тут вам и избавление от include 'sms.php', и запуск функционала по необходимости.


В вашем примере с СМС вместо глобальных функций неплохо было бы сделать Helper-класс со статическими методами. А еще лучше — компонент приложения, зарегистрирован в Service Locator и доступный из экземпляра приложения — тогда будет и действительная гибкость настройки, и возможности для тестирования. А если заглянуть еще глубже, то отправку SMS сообщений нужно делать отложено через очереди, чтобы пользователь не ждал, пока ваше приложение сходит в чужое АПИ.


В Diafan.CMS всего один шаблон для построения ссылок: /строковоеЧПУ/числовойпараметр3/другойчисловойпараметр25

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


Минимизируйте количество запросов к БД

А еще можно попробовать использовать ORM и решить многие описанные проблемы архитектурно. Кстати, все ваши примеры кода в этом блоке синтаксически неверны и жутко отформатированы (загляните в PSR).


Вещи говорите местами правильные, но пора переходить на следующий уровень. PHP уже давно не такой, каким вы его показываете ;)

SilverFire
0
Я тоже немного попараноил и пару дней после установки снифал весь трафик. Пролистал дампы, ничего интересного не нашел.
Все, что стоит на малине есть на GitHub в репозиториях организации: https://github.com/flightaware
SilverFire
+1
Нет, не пробовал. Согласно условиям FlightAware, я не имею права разбирать их коробку и что-либо делать с малинкой. Доступа по SSH нет, получить можно через Single user mode, но для этого нужно разобрать и достать флешку.
Все работает из коробки без каких-либо проблем, а софт Flightradar24 стоит на домашнем компе, получает по локальной сети RAW данные от dump1090 и рестримит их на fr24. Конфиг:
fr24feed.ini
receiver="avr-tcp"
fr24key="paste your key here"
host="192.168.1.2:30002"
bs="yes"
raw="yes"
logmode="1"
windowmode="1"
mpx="no"
mlat="no"
mlat-without-gps="no"
SilverFire
+2
Расход трафика мизерный
График с порта (5 кбайт)

SilverFire
0
Я свой комплект получил от FlightAware
SilverFire
+3
Отличный пост! Сам недавно стал принимать ADS-B данные. Хорошая антенна, будучи установленной на высоте около 30 метров, она дает 250+ морских миль покрытия (460+ км), что впечатляет.
Антенна на 1090 MHz, 200 кб


Сейчас на flightradar24 идет кампания по расширению покрытия и есть возможность запросить ADS-B оборудование бесплатно. Присылают антенну для 1090 mHz, GPS антенну для синхронизации времени, коробку с электроникой (Plug and play), 5 метров кабеля для GPS, 5 метров Ethernet кабеля и 5-10 метров коаксиального для ADS-B антенны. Запрос удовлетворяется на основании необходимости организации дополнительного покрытия местности, где вы планируете установить антенну. Вам нужно будет хорошо это все дело установить с обзором в 360 градусов, дать круглосуточный интернет и питание. Подать запрос можно тут.
Кроме flightradar24 есть еще один похожий проект FlightAware. Сейчас они также заинтересованы в расширении сети сбора данных, потому готовы бесплатно прислать комплект очень хорошего оборудования, а именно: антенну для 1090 MHz; коробку с Raspberry PI и качественным ADS-B приемником (также Plug and play); 5-15 метров приличного коаксиального кабеля, 5 метров Ethernet, футболку и премиум на их сайте. Запросы принимаются тут.
Кроме того, FlightAware не против, если вы будете делиться получаемыми данными с любым другим сервисом. Это значит, что вы можете запустить клиент flightradar24, сливать данные и иметь премиум еще и на flightradar24. Политику flightradar24 по этому поводу не знаю, потому работает ли в обратную сторону — не скажу.
Так что если кто-то загорелся идеей и может установить антенну на хорошее место с отличным обзором без препятствий, накормить интернетом и электричеством — вы знаете что делать :)
SilverFire
+7
Yii первой версии (о котором вы пишете) уже очень отстал от современных трендов PHP, потому прием улучшений прекращен, а датой End of life объявлен конец 2018 года. Если вы пишете новый проект — обязательно посмотрите на Yii2, там вы найдете гораздо более гамотные и современные архитектурные решения.
SilverFire
+4
Точно есть бан для плохих дедушек. А для плохих внуков есть?
SilverFire
+13
Тогда просто ЛС, а не в трекер. Уведомления об ЛС падают на почту по умолчанию
SilverFire
+13
Хм, не ты ли мой дедушка? :) Мне дедушка написал перед НГ, что выбрал подарок, уточнил мой адрес и с тех пор не заходит :(

А по сути — идея рассылки очень правильная. Уведомления от приложений в Хабрацентре на почту то не приходят.
SilverFire
+18
Еще раз пожалуйста, внучек. Расскажи вкратце о впечатлениях, как сходишь, пожалуйста :)
SilverFire
+6
В любом крупном проекте найдется хорошая стопка issue или PR, которые висят месяцами или даже годами. Залипают обычно некритичные и часто сложновоспроиводимые проблемы, улучшения, сломы обратной совместимости, неоттестированные опасные PR. Рассматривая новый PR всегда перебираешь варианты: а нужны ли эти изменения, не дублируют ли они что-то существующее, не сломается ли чего, не зарыт ли тут слом обратной совместимости, придется ли менять документацию, и так далее.

Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?

Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
SilverFire
+2
Отличная статья, спасибо. От себя добавлю, что нормальные описания PR или Issue очень важны. Есть много статей о том, как правильно составлять баг-репорты, но я представляю идеальный баг-репорт так:

1. Суть проблемы;
2. Минимальный код для воспроизведения и описание окружения;
3. Текущий результат;
4. Ожидаемый результат.

Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
SilverFire
+1
В смысле уже есть и можно писать в ЛС? Или будет какая-то специальная процедура?
SilverFire
+3
О черезмерно толстых моделях писал nepster09 в своей недавней статье Разработка приложений на Yii2 без опыта — прямой путь в АД, но по моему мнению, проблема сводится к сугубо архитектурной и решается очень аккуратно, хороший пример Tairesh и показал.

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

Что касается практики, я бы добавил, что создание объектов базового класса Car не всегда хорошая идея. Я вижу две стратегии:

1) Car — суперкласс. Есть базовые правила валидации того, что есть у всех, типа
[['type', 'name'], 'required']
, но создание машин через этот класс невозможно, обязательно использовать уточненные классы. Это хорошо, когда каждый тип гарантированно имеет что-то свое, чего принципиально не может быть у базового и не пересекается с другими. Например, у спортивной машины, наверняка, не будет сцепного устройства для прицепа :)

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

Открытым может оставаться вопрос о правильном наследовании правил валидации и возможностям комбинирования похожих свойств, но
это может сильно отличатся в разных предметных областях.
SilverFire
+3
Новая Почта феерически прошрафилась. Прошел квест по получения подарка — пройди квест-подарок! Рад, что тебе понравилось! С НГ, внучек! :)
SilverFire
+6
Софт такого рода — отличная вещь для дебага веб-запросов. Но Charles — не мой выбор. Мне больше понравился бесплатный аналог Fiddler.

Работал с ним хоть и не очень долго, но в нем есть все что нужно — есть те же фильтры, можно подменять ответы, поддерживает HTTPS, может перехватить запрос и ответить на него, не обращаясь к реальному серверу. На Linux работает под Mono, но с периодическими вылетами и мелкими глюками. Не нашел ничего нативного для линукса, что умеет все то же и работает лучше (посоветуете?).

P.S.: Redmadrobot, почему вы отдали предпочтение Charles?
SilverFire
+3
Нет, скорее:

$array = [1,2,3,4,5];
next($array);
var_dump(current($array)); // 2

foreach ($array as $item) {
    continue; // iterate over array
}

var_dump(current($array)); // 2. В PHP 5.5 будет FALSE


3v4l.org/nf3Cg
SilverFire
+3
Для проверки, является ли переменная — функцией, которую можно вызвать, предпочитаю использовать instanceof

$x = function () { 
    print(1); 
};

if ($x instanceof \Closure) {
    call_user_func($x);
}
SilverFire
+1
Присоединяюсь к вопросу. Вы будете знать HTTP referer, где была размещена ссылка (какой-то форум) и IP жертвы.
Кого вы сможете привлечь к ответственности? Пользователя форума, который опубликовал ссылку, сидя за китайской прокси?

ИМХО, жертве реальнее привлечь вас к ответственности, так как данные были слиты в следствие выполнения вредоносного кода на вашем сайте.
SilverFire
+3
mao1985, действительно, тут можно маневрировать с термином «уязвимость». Нужно еще чуток заморочиться, чтобы загнать жертву на страницу оплаты, где она доведет транзакцию до конца, но как proof-of-concept — очень даже хорошо.

при подмене ресурса фишинговым сайтом

Ведь речь идет не о подмене iPay фишинговым сайтом. Достаточно отправить к вам пользователя с определенными данными.
SilverFire
+4
Тогда мне непонятно, почему уязвимости, которые очевидно угрожают безопасности платежных карт болтаются 3 недели в очереди?
SilverFire
+6
проведена оценка потенциальной угрозы

Потенциальная угроза очевидна — слив номера карты, срока действия, cvv кода.

Вы говорите, что:
методов их эксплуатации не выявили

Как по мне, метод — это последовательность шагов, которые нужно выполнить, чтобы добиться результата. Результат — угон данных карточки. Шаги со скринами в статье. Вы хотите сказать, что поле комментарий не было подвержено уязвимости XSS?
SilverFire
+14
Уважаемый mao1985! По моему мнению, ваш ответ наполнен вежливым текстом, но лишен здравого смысла.

dinikin очень детально и наглядно продемонстрировал использование уязвимости, но мне не понятно что вы имели ввиду под
Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили

SilverFire
+5
Я привык к PostgreSQL, где реализована транзакционность DDL операций. Потому ничего зверского в деянии я не видел :)
Ну если уж нельзя делать DDL в транзакции — так поругайся и скажи, что нельзя. Это — адекватное-ожидаемое поведение, в отличие от безусловного коммита.
SilverFire
+2
А у меня был один очень неприятный случай с MySQL

CREATE TABLE user_bak LIKE user;
BEGIN; -- начинаю транзакцию
UPDATE user_bak SET msg_disabled = 0;
DROP TABLE user;


И на моменте DROP TABLE я внезапно получаю коммит транзакции! Оказывается в мане написано:
DROP TABLE automatically commits the current active transaction, unless you use the TEMPORARY keyword.


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

Мне прислали письмо с PDF авиабилетами в аттаче, при это в заголовке было написано «Arrival», и теле письма не было никаких конкретных упоминаний о рейсе. За 3 часа до начала регистрации мне Android пиликает уведомление, что скоро начинается регистрация на рейс, пора собираться. Предложил построить маршрут, рассказал откуда и куда рейс, из какого терминала.



Билет был не из пункта «А» в пункт «Б», а с пересадкой, о чем гугл тоже знал благодаря отпарсенному PDF из письма.
Я вообще сначала был в полном замешательстве и не понимал, откуда у него такая информация. Потом заметил, что он пишет «От: Имя отправителя письма»…

Как-то неуютно понимать, насколько глубоко проникают в твою приватность на каждом углу.
SilverFire
0
Просто еще не везде расползлось. На корневых зоны .RU уже есть
SilverFire
+17
А может и обыск в ЯД пришел случайно? Проезжали мимо и решили зайти в гости? :)
SilverFire
+2
В смысле сменить Россию? Я из Украины и провайдер тут не при чем. Домен не выпускают дальше корневых серверов зоны .ru