Постоянно падает с exception'ами и по сути только webkit-семья, а фаервокса, оперы и IE в нем нету.
Я вообще за старый добрый селениум с дровами под все нужные браузеры, который параллельно идёт на ИКС машинках и писать на котором в любом IDE можно на множестве языков с блэкджеком и code-completion'ом.
А изучение очередного my-own-bicycle-xml'я мало интересно ))
В исходном примере innerHtml подряд в один проход изменяется, поэтому под капотом ничего и не видно. А в реальных приложениях всё чуть менее чем полностью асинхронно. Вот я о чём пытаюсь донести мысль.
A treatment attempts to improve or remove a problem, but treatments may not produce permanent cures, especially in chronic diseases. Cures are a subset of treatments that reverse diseases completely or end medical problems permanently. Many diseases that cannot be completely cured are still treatable.
Снятие симптомов не есть излечение. Вот я о чём. Понятия попутаны в этом мифе, а попутали их скорее всего маркетологи лекарств, которые симптомы снимают.
<?php
// auto_prepend_file by php-fpm's php_admin_value
$secure = getenv('WTF');
putenv('WTF=***********');
unset($_SERVER['WTF']);
unset($_ENV['WTF']);
// your file
phpinfo();
Это стандартный способ:
* не хранить логин/пароль в исходниках
* не хранить логин/пароль в коде в принципе
В любом случае, имея доступ к куску кода, который откуда-то получает логин/пароль, его можно добыть. Но он точно не на ладони будет. И в случае утечки исходников, он также не улетит вместе с ними.
PS: Опять же для стандартного окружения, на которое расчитаны овер100500 CMS'ок это не вариант в любом случае.
Никак нет. В любом движке есть конфиг. В том же WP это wp-config.php.
В нём вам рекомендуется делать заместо:
// define('DB_PASSWORD', 'masha'); // BAD BAD BAD!!!
define('DB_PASSWORD', $_ENV['DB_PASSWORD']); // Good.
Как попадают в ENV значения DB_PASSWORD уже дело десятое. Напр. их можно прохардкодить в конфигах php-fpm'а, которые только руту для чтения доступны, а уже сайты запускаются под www-blabla, который даже хоть всё поламает — не прочитает тот конфиг через шельные вызовы.
Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Ps: Вариант хорош, когда у вас есть доступ к способу запуска php под разными правами. Для стандартных shared серверов под cPanel'ями не подходит.
Если у нас какой-нибудь типовой движок, что скорее всего в 99.999% случаев, то заместо директивы «исполняй *.php» надо сделать директиву «исполняй webroot/index.php». Т.е. запретить всё везде и разрешить только в одном месте.
Без возможностей изменения ниже через .htaccess или иные варианты.
Вообще это правда. Ещё нормальной модели учёные не нашли о причинах. Только научились лекарствами снижать частоту приступов и подавлять их. Т.е. причины ещё до сих пор неизвестны.
Любой невролог на любой конференции это подтвердит.
5. Окей… Переименовываю его в *.js.
6. Тыкаю два раза
7. И ничего не происходит
8. Тыкаю правой кнопкой и «Запустить»
9. И я взломан gyazo.com/8a33ca345d00d874d40b72d1dbf92958
Допустим я — блондинка. Придумайте мне кейс когда у меня на машинке вдруг шифровальщик запустится. Возьмем для примера матрицу 2 на 2:
* винда с адекватными настройками (где админы истинно бородаты и урезают права всем)
* винда с дефолтными настройками ленивых админов, когда всем все можно
* линукс с дефолтными настройками
* линукс с ужасными настройками, когда sudo отключено почему-то ))
Я вообще за старый добрый селениум с дровами под все нужные браузеры, который параллельно идёт на ИКС машинках и писать на котором в любом IDE можно на множестве языков с блэкджеком и code-completion'ом.
А изучение очередного my-own-bicycle-xml'я мало интересно ))
Про очередь то да. Вы просто взгляните на него, как он прыгает иногда (именно в переходе с мелкого на крупный).
В исходном примере innerHtml подряд в один проход изменяется, поэтому под капотом ничего и не видно. А в реальных приложениях всё чуть менее чем полностью асинхронно. Вот я о чём пытаюсь донести мысль.
Но я всё равно за innerHtml.
PS: В примере всё делается синхронно. А вы попробуйте асинхронно — уже интереснее становится ))
Пойдем по ВОЗу:
Значит, что в 30% случаев — нет. Значит она неизлечима для всех случаев.
en.wikipedia.org/wiki/Disease#Treatments
Снятие симптомов не есть излечение. Вот я о чём. Понятия попутаны в этом мифе, а попутали их скорее всего маркетологи лекарств, которые симптомы снимают.
Это стандартный способ:
* не хранить логин/пароль в исходниках
* не хранить логин/пароль в коде в принципе
В любом случае, имея доступ к куску кода, который откуда-то получает логин/пароль, его можно добыть. Но он точно не на ладони будет. И в случае утечки исходников, он также не улетит вместе с ними.
PS: Опять же для стандартного окружения, на которое расчитаны овер100500 CMS'ок это не вариант в любом случае.
В нём вам рекомендуется делать заместо:
Как попадают в ENV значения DB_PASSWORD уже дело десятое. Напр. их можно прохардкодить в конфигах php-fpm'а, которые только руту для чтения доступны, а уже сайты запускаются под www-blabla, который даже хоть всё поламает — не прочитает тот конфиг через шельные вызовы.
Вот только он точно также сможет прочитать $_ENV['DB_PASSWORD'], если будет использоваться маска "*.php" для запуска.
Ps: Вариант хорош, когда у вас есть доступ к способу запуска php под разными правами. Для стандартных shared серверов под cPanel'ями не подходит.
"credentials environment"
Если у нас какой-нибудь типовой движок, что скорее всего в 99.999% случаев, то заместо директивы «исполняй *.php» надо сделать директиву «исполняй webroot/index.php». Т.е. запретить всё везде и разрешить только в одном месте.
Без возможностей изменения ниже через .htaccess или иные варианты.
Вообще это правда. Ещё нормальной модели учёные не нашли о причинах. Только научились лекарствами снижать частоту приступов и подавлять их. Т.е. причины ещё до сих пор неизвестны.
Любой невролог на любой конференции это подтвердит.
Proxy-pass здесь по-мойму лишний, хотя сходу красиво смотрится.
Щас все лежит — добавьте скринов что ли.
* Как плохой-код окажется в системе?
* Как он запустится?
Что я пробовал сделать, но у меня не получатеся.
1. Я создал файл bad-code.doc gist.github.com/garex/13418746bf34abc9dbc6
2. Добавил ему исполнения
3. Тыкаю на него
4. И вижу: gyazo.com/120e6115f03730083061cc3d9c730d97
5. Окей… Переименовываю его в *.js.
6. Тыкаю два раза
7. И ничего не происходит
8. Тыкаю правой кнопкой и «Запустить»
9. И я взломан gyazo.com/8a33ca345d00d874d40b72d1dbf92958
ps: 8 пункт нереален в условиях блондинки
Допустим я — блондинка. Придумайте мне кейс когда у меня на машинке вдруг шифровальщик запустится. Возьмем для примера матрицу 2 на 2:
* винда с адекватными настройками (где админы истинно бородаты и урезают права всем)
* винда с дефолтными настройками ленивых админов, когда всем все можно
* линукс с дефолтными настройками
* линукс с ужасными настройками, когда sudo отключено почему-то ))
Ток по-мойму убунта/мак спрашивает перед тем как запустить тот-же исполняемый файл — нет?
ps: Хотя если я блондинка, то мне ничего не поможет
Риск накрытия волосатой дата-центра в 100500 меньше чем риск блондинки заразиться на несекурной из коробки ОС.