В любом крупном проекте найдется хорошая стопка issue или PR, которые висят месяцами или даже годами. Залипают обычно некритичные и часто сложновоспроиводимые проблемы, улучшения, сломы обратной совместимости, неоттестированные опасные PR. Рассматривая новый PR всегда перебираешь варианты: а нужны ли эти изменения, не дублируют ли они что-то существующее, не сломается ли чего, не зарыт ли тут слом обратной совместимости, придется ли менять документацию, и так далее.
Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?
Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
Отличная статья, спасибо. От себя добавлю, что нормальные описания PR или Issue очень важны. Есть много статей о том, как правильно составлять баг-репорты, но я представляю идеальный баг-репорт так:
1. Суть проблемы;
2. Минимальный код для воспроизведения и описание окружения;
3. Текущий результат;
4. Ожидаемый результат.
Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
Такая структура моделей может быть особенно полезной, когда разные типы одного объекта требуют разных правил валидации или специфического поведения. Описывание особенностей разных типов одной модели в одном классе быстро превращает его в сложноподдерживаемое месиво. А если еще и добавить сценарии — можно плакать. Проверено :)
Что касается практики, я бы добавил, что создание объектов базового класса Car не всегда хорошая идея. Я вижу две стратегии:
1) Car — суперкласс. Есть базовые правила валидации того, что есть у всех, типа
[['type', 'name'], 'required']
, но создание машин через этот класс невозможно, обязательно использовать уточненные классы. Это хорошо, когда каждый тип гарантированно имеет что-то свое, чего принципиально не может быть у базового и не пересекается с другими. Например, у спортивной машины, наверняка, не будет сцепного устройства для прицепа :)
2) Car — общий класс машины. Применим, когда удовлетворяет требованиям для создания большинства записей, но лишь некоторые типы содержат что-то специфической и требуют отдельных правил, которые будут вынесены в отдельный класс.
Открытым может оставаться вопрос о правильном наследовании правил валидации и возможностям комбинирования похожих свойств, но
это может сильно отличатся в разных предметных областях.
Софт такого рода — отличная вещь для дебага веб-запросов. Но Charles — не мой выбор. Мне больше понравился бесплатный аналог Fiddler.
Работал с ним хоть и не очень долго, но в нем есть все что нужно — есть те же фильтры, можно подменять ответы, поддерживает HTTPS, может перехватить запрос и ответить на него, не обращаясь к реальному серверу. На Linux работает под Mono, но с периодическими вылетами и мелкими глюками. Не нашел ничего нативного для линукса, что умеет все то же и работает лучше (посоветуете?).
P.S.: Redmadrobot, почему вы отдали предпочтение Charles?
Присоединяюсь к вопросу. Вы будете знать HTTP referer, где была размещена ссылка (какой-то форум) и IP жертвы.
Кого вы сможете привлечь к ответственности? Пользователя форума, который опубликовал ссылку, сидя за китайской прокси?
ИМХО, жертве реальнее привлечь вас к ответственности, так как данные были слиты в следствие выполнения вредоносного кода на вашем сайте.
mao1985, действительно, тут можно маневрировать с термином «уязвимость». Нужно еще чуток заморочиться, чтобы загнать жертву на страницу оплаты, где она доведет транзакцию до конца, но как proof-of-concept — очень даже хорошо.
при подмене ресурса фишинговым сайтом
Ведь речь идет не о подмене iPay фишинговым сайтом. Достаточно отправить к вам пользователя с определенными данными.
Как по мне, метод — это последовательность шагов, которые нужно выполнить, чтобы добиться результата. Результат — угон данных карточки. Шаги со скринами в статье. Вы хотите сказать, что поле комментарий не было подвержено уязвимости XSS?
А по сути — идея рассылки очень правильная. Уведомления от приложений в Хабрацентре на почту то не приходят.
Я раньше этого всего до конца не осознавал и сам думал «Блин, ну не уже ли нельзя смёржить то, ничего сложно нет», но после присоединения к Core-team начал невольно смотреть на это немного иначе. Каждый день — это поток изменений, комментариев, новых задач и PR. Случайные люди не видят этого, ведь кто захочет просто так получать 50+ уведомлений каждый день, и вчитываться в них и от всей души стараться решить чью-то проблему?
Я однажды услышал версию, что это происходит из-за плохо организованной работы в команде и если принудительно раздавать задачи и контролировать их исполнение — все будет чётко и быстро. Утверждение толковое, но в Open-source оно не будет работать. Какую бы задачу я не взял, займет она у меня 10 минут или 5 часов, я это буду делать добровольно, с удовольствием, целью помочь сообществу и за идею. Такое принудительно не работает.
1. Суть проблемы;
2. Минимальный код для воспроизведения и описание окружения;
3. Текущий результат;
4. Ожидаемый результат.
Навскидку несколько свежих примеров неудачных репортов: 1, 2, 3. В одних информации слишком мало и приходится догадываться, а в других она не помещается на 3 экрана и желание вчитаться быстро пропадает. В действительности, чтобы найти золотую середину, достаточно задать себе несколько вопросов: «Этой информации достаточно для воспроизведения проблемы без фантазирования?», «Я оставил только тот минимум кода, который относится к проблеме и необходим для воспроизведения?».
Такая структура моделей может быть особенно полезной, когда разные типы одного объекта требуют разных правил валидации или специфического поведения. Описывание особенностей разных типов одной модели в одном классе быстро превращает его в сложноподдерживаемое месиво. А если еще и добавить сценарии — можно плакать. Проверено :)
Что касается практики, я бы добавил, что создание объектов базового класса
Carне всегда хорошая идея. Я вижу две стратегии:1)
Car— суперкласс. Есть базовые правила валидации того, что есть у всех, типа , но создание машин через этот класс невозможно, обязательно использовать уточненные классы. Это хорошо, когда каждый тип гарантированно имеет что-то свое, чего принципиально не может быть у базового и не пересекается с другими. Например, у спортивной машины, наверняка, не будет сцепного устройства для прицепа :)2)
Car— общий класс машины. Применим, когда удовлетворяет требованиям для создания большинства записей, но лишь некоторые типы содержат что-то специфической и требуют отдельных правил, которые будут вынесены в отдельный класс.Открытым может оставаться вопрос о правильном наследовании правил валидации и возможностям комбинирования похожих свойств, но
это может сильно отличатся в разных предметных областях.
Работал с ним хоть и не очень долго, но в нем есть все что нужно — есть те же фильтры, можно подменять ответы, поддерживает HTTPS, может перехватить запрос и ответить на него, не обращаясь к реальному серверу. На Linux работает под Mono, но с периодическими вылетами и мелкими глюками. Не нашел ничего нативного для линукса, что умеет все то же и работает лучше (посоветуете?).
P.S.: Redmadrobot, почему вы отдали предпочтение Charles?
3v4l.org/nf3Cg
Кого вы сможете привлечь к ответственности? Пользователя форума, который опубликовал ссылку, сидя за китайской прокси?
ИМХО, жертве реальнее привлечь вас к ответственности, так как данные были слиты в следствие выполнения вредоносного кода на вашем сайте.
Ведь речь идет не о подмене iPay фишинговым сайтом. Достаточно отправить к вам пользователя с определенными данными.
Потенциальная угроза очевидна — слив номера карты, срока действия, cvv кода.
Вы говорите, что:
Как по мне, метод — это последовательность шагов, которые нужно выполнить, чтобы добиться результата. Результат — угон данных карточки. Шаги со скринами в статье. Вы хотите сказать, что поле комментарий не было подвержено уязвимости XSS?
dinikin очень детально и наглядно продемонстрировал использование уязвимости, но мне не понятно что вы имели ввиду под
Вон еще одно подтверждение.
Уверен, что приличная часть паролей все еще жива.