Туннель поможет, если на один php-fpm будет один разработчик. В случае же когда на один php-fpm несколько разработчиков, Xdebug не будет знать, в какой туннель ему идти. Xdebug proxy позволяет определить нужный туннель по `idekey`.
Да, видел этот репозиторий.
Совсем не похоже на официальный репозиторий, нет никакой связи с komodo и ActiveState. Так же судя по звёздочкам и инструкциям в интернете не похоже что pydbgpproxy скачивается из этого репозитория. Соответственно делать pull request в этот репозиторий смысла нет.
Если абстрагироваться от деталей, то это действительно похоже на то, что добавляется новая глобальная соль, которая находится на отдельном сервисе. В случае Facebook's password Onion, это было именно так.
Но не равносильно это потому что в случае Pythia и PHE ключ (который вы назвали солью) можно менять не зная ничего о пароле.
Соль поменять нельзя не имея пароля.
Причем, если я правильно понял принцип работы, в случае компрометации ключей хэши даже перебирать не придется — они просто расшифровываются ключом. Разве нет?
Как я понимаю нет. Оно работает в одну сторону, т.е. имея пароль, данные из БД и приватные ключи бэкенда и сервиса можно понять, правильный ли пароль. Но имея данные из БД и приватные ключи бэкенда и сервиса пароль можно только подобрать.
PS Справедливости ради, для каждого клиента может быть свой комплект ключей. Тогда проблема решается достаточно просто.
Не могу сказать за докладчика, но думаю было бы вполне логично для каждого клиента, и даже для каждого приложения клиента иметь свой комплект ключей и в сервисе и на бекэнде.
Правда, все равно клиент должен быть в курсе что его взломали.
Согласен. Здесь наверное поможет профилактика — периодически полностью переустанавливать сервера и обновлять ключи.
Здесь имеется ввиду, что если хакер получит хеш пароля, то он сможет подобрать пароль вычисляя хеши возможных паролей на видеокартах.
Затрудняюсь ответить, есть ли разница между «подберет» и «переберет».
От себя добавлю, инструмент написан на php и расширяем, что позволяет вносить правки на знакомом языке.
Из любопытного, под капотом асинхронный фреймворк amphp.
Во-первых: mysqli морально устарел и мне кажется, что лучше использовать PDO.
См таблицу «Сравнение опций MySQL API в PHP» на http://php.net/manual/ru/mysqli.overview.php: Рекомендовано MySQL для разработки новых проектов: Расширение PHP mysqli: Да — отдается предпочтение.
Mysqli не устарел морально и нужно смотреть, что для своей задачи использовать лучше.
Первая alpha-версия инструмента разрабатывалась 2-мя разработчиками где-то в течение месяца. После этого инструмент использовался и параллельно дорабатывался и продолжает дорабатываться одним разработчиком не full-time.
Становится понятно, что так можно тестировать только веб-сайты и html-based мобильные приложения
Нативный код который может в AppStore ревьювится до 2х недель так тестировать не получится...
Мы проводим тесты как на web и мобильном web, так и на мобильных приложениях. Для того, чтобы закончить тест, не нужно менять код. По окончании теста выбирается итоговый вариант и если мобильное приложение нам присылает, что оно поддерживает этот тест, то сервер ему будет всегда отвечать итоговым вариантом. Но т.к. после окончания тест в коде больше не нужен, то хорошим тоном является поставить задачу на то, чтобы подчистить код.
тестировать какие то фичи новые, которые меняют логику хранения данных на бекенде например нельзя, потому что после завершения теста не получится привести данные к виду "как было без теста с учетом множественного пересечения с другими тестами"
Пересечения теста с другими тестами считаются с целью, чтобы менеджер мог посмотреть на них и решить, стоит ли запускать тест с такими пересечениями. Например, тестирование кнопки в мобильном приложении никак не влияет на тестирование страницы профиля пользователя на web-е. Такое пересечение можно просто игнорировать. Если же в пересекаемом тесте проводится тестирование связанного функционала, то нужно, либо провести тестирование в другой стране, либо сделать его позже.
Что же касается изменения логики хранения данных, можно привести пример, когда это будет проблемой?
Совсем не похоже на официальный репозиторий, нет никакой связи с komodo и ActiveState. Так же судя по звёздочкам и инструкциям в интернете не похоже что pydbgpproxy скачивается из этого репозитория. Соответственно делать pull request в этот репозиторий смысла нет.
Но не равносильно это потому что в случае Pythia и PHE ключ (который вы назвали солью) можно менять не зная ничего о пароле.
Соль поменять нельзя не имея пароля.
Вечером добавлю их в конспект, так будет гораздо красивее:)
Как я понимаю нет. Оно работает в одну сторону, т.е. имея пароль, данные из БД и приватные ключи бэкенда и сервиса можно понять, правильный ли пароль. Но имея данные из БД и приватные ключи бэкенда и сервиса пароль можно только подобрать.
Не могу сказать за докладчика, но думаю было бы вполне логично для каждого клиента, и даже для каждого приложения клиента иметь свой комплект ключей и в сервисе и на бекэнде.
Согласен. Здесь наверное поможет профилактика — периодически полностью переустанавливать сервера и обновлять ключи.
Затрудняюсь ответить, есть ли разница между «подберет» и «переберет».
От себя добавлю, инструмент написан на php и расширяем, что позволяет вносить правки на знакомом языке.
Из любопытного, под капотом асинхронный фреймворк amphp.
Насчет подхода согласен, а вот про библиотеку, см. комментарий выше
См таблицу «Сравнение опций MySQL API в PHP» на http://php.net/manual/ru/mysqli.overview.php: Рекомендовано MySQL для разработки новых проектов: Расширение PHP mysqli: Да — отдается предпочтение.
Mysqli не устарел морально и нужно смотреть, что для своей задачи использовать лучше.
Мы проводим тесты как на web и мобильном web, так и на мобильных приложениях. Для того, чтобы закончить тест, не нужно менять код. По окончании теста выбирается итоговый вариант и если мобильное приложение нам присылает, что оно поддерживает этот тест, то сервер ему будет всегда отвечать итоговым вариантом. Но т.к. после окончания тест в коде больше не нужен, то хорошим тоном является поставить задачу на то, чтобы подчистить код.
Пересечения теста с другими тестами считаются с целью, чтобы менеджер мог посмотреть на них и решить, стоит ли запускать тест с такими пересечениями. Например, тестирование кнопки в мобильном приложении никак не влияет на тестирование страницы профиля пользователя на web-е. Такое пересечение можно просто игнорировать. Если же в пересекаемом тесте проводится тестирование связанного функционала, то нужно, либо провести тестирование в другой стране, либо сделать его позже.
Что же касается изменения логики хранения данных, можно привести пример, когда это будет проблемой?
Не 3 месяца, а полгода. :)
Это пока не обсуждалось, но в целом есть много идей, что доделывать.