allow_url_fopen на виртуальном хостинге: добро или зло?

[news29]

А какаие противоречия у них есть? У одного потенциальная дыра открыта, у другого прикрыта. Выбирайте что вам нужнее :)

[malaka]

>> У одного потенциальная дыра открыта, у другого прикрыта.
эх, мне бы вашу уверенность...:) вот с чего вы взяли, что она у одного открыта, а у другого закрыта? а может, один эту дыру за дыру не считает? или другой, наоборот, видит дыру там, где её нету?

[news29]

Потенциально (!) это однозначно дыра, зависит исключительно от скриптов, которые реализуют некий функционал.

[Be3]

Ввод данных пользователем это тоже дыра?
Это не «Потенциальная дыра(!)», это функция языка. Дырой ее могут сделать только кривые руки программиста.

[news29]

То что я называю потенциальной дырой вы называете кривыми руками программиста. Не вижу повода для дискуссии…

[Barttos]

Давненько я не встречал платный виртуальный хостинг с отключенным allow_url_fopen.

[Be3]

Не понимаю сути вопроса. У вас есть задача и вам нужно ее решить, значит используйте allow_url_fopen. Вся проблема заключается в том как использовать, больше внимания защите приложения и все будет нормально.

[malaka]

суть вопроса: включённый allow_url_fopen это дыра или нет, если да, как эффективно закрывается и почему первый хостер предпочитает не позволять, чем закрывать дыру.

[grdigger]

потенциально дыра, но использовать ее можно только через ваши скрипты, если скрипты безопасны (возмем идеальный вариант) 100%, то это не дыра.

[malaka]

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

[news29]

А ему, скорее всего, пофиг, вас же хакнут если что, не его…

[malaka]

хакнут меня – хакнут всех, кто со мной на одном сервере, или не так? ip-адрес в blacklist загонят… ему это надо?

[grdigger]

с чего это вдруг? если сервер настроен правильно, то вынесут только ваши файлы и вашу БД. и ip в блист не загонят из-за этого 100%.

[malaka]

ага, очень похоже на правду. если ломанут ТОЛЬКО меня, то тут не технический момент решающий, а отношение к клиенту. один опекает и не позволяет, другой позволяет, но под личную ответственность.

[grdigger]

не совсем так, у того, кто «опекает» просто более серьезная стадия Паранойи :) либо опыта больше.

[malaka]

с одной стороны – ваша правда. он действительно параноик тот ещё, знаю его лет 5 уж. а с другой – ломали меня именно у него :)

[grdigger]

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

[Roxis]

Странная CMS, если требует cURL и allow_url_fopen одновременно.

[malaka]

это не CMS. она у меня неприхотливая, ничего не требует. требует только скриптик, который автоапдейт делает.

[AHDPEu]

Если скриптик писали вы, то думаю стоит его переписать под курл.
Как то нелогично использовать курл в связки с опеном.

[AHDPEu]

Извиняюсь. Прочитал внимательно суть вопроса.
Считаю, что allow_url_fopen это не дыра, а приятная работа с удалёнными данными :)

[postdig]

«приятная работа с удалёнными данными» — скорее чуть проще.
но ведь на curl не многим сложнее…

на мой взгляд использование curl вместо url_fopen просто один из небольших штрихов в общей массе факторов «правильного» стиля программирования

[nerezus]

Не стоит путать опен и инклюд.
Если второе зло, то первое очень даже полезно.

> потенциально дыра
как и половина функций. Но функции нужны ;)