1) В том, что люди — не машины. Кто-то при каком-то изменении может забыть добавить что-то в исключения, и все полетит.
2.1) И что? Вы гарантируете, что в Вашем коде никогда не обнаружится подобного бага? Чем?
2.2) Бывает не только апач, особенно на высоконагруженной системе. Да и его можно сконфигурировать на регекспы, а не на расширения.
1) KISS. Зачем делать что-то сложно, добавлять excludes, менять их при изменении скрипта, порождая возможные ошибки, если можно просто вести одну папку в SVN и бекапить другую?
Про то, при чем тут ДокРут — не понял. Смысл в том, чтобы была специальная папка, которую нельзя поменять запросом из вебсервера, и чтобы только она могла исполняться.
2.1) Тем не менее, люди — не роботы, ошибки встречаются. Лучше уж «железно» застраховаться от них, чем надеяться на то, что код — без ошибок.
2.2) Веб-сервер смотрит на URI-запроса и решает, что же с ним делать — отдать пхп, отдать статикой или еще что-то.
1) Разделяем скрипты и контент. Удобнее бекапить, удобнее использовать svn для скриптов. В папку со скриптами может писать только отличный от вебсервера/php пользователь, что гарантирует невозможность переписать скрипт в случае обнаружения дыры в нем.
2) В папке upload он может оказаться опять же в виде какой-нибудь ошибки, приводящей к заливке файла upload.php или upload.php.jpg. В основном, php матчат по регекспу \.php, а не \.php(\/|$), что позволит злоумышленнику выполнить upload.php.jpg как скрипт. Да и то, в данном случае, если злоумышленник сможет создать папку с именем что-то.php, и положить в нее свой jpeg, то он обработается.
Эм, а кто предлагает его панацеей? Как и любое другое средство, оно имеет свои границы применимости, и перед решением, использовать его, тоже надо думать.
Вы частично не правы. Конечно, всё это накипело очень сильно, но форма была выбрана в основном для привлечения внимания.
На очередную сухую статью о том, как правильно писать приложение, никто не обратил бы внимания, она не возымела бы эффекта — ведь таких написаны уже десятки, а все равно, ими никто не пользуется. А эта статья могла отложить больший отпечаток в памяти прочитавшего программиста, и, возможно, когда он будет писать следующее приложение, он задумается.
Да. Суть — в том, что из вебсервера, который не знает ничего о php, структуре его файла сессии/записи в memcached, и вообще, может располагаться на другой машине, чем сессии, намного сложнее проверить авторизованность по сессии, чем самому скрипту.
Нет. При успешной авторизации мы записываем об авторизации в сессию, а так же выдаем новую куку с любым значением, например, логином вошедшего пользователя. Авторизованность по ней проверяться не должна, по ее присутствию определяется только возможность кеширования.
Получается, у Вас еще один «бонус» — можно разнести разные базы по разным серверам, а не мучиться с разнесением таблицы по серверам. А насколько это удобно управляется? Ведь какой-нибудь alter table на 1000 баз будет выполняться достаточно долго.
Плохо — то, что (скорее всего) скрипт начинается с session_start(), и кука выдается клиенту сразу. Когда встанет проблема увеличения посещаемости, понадобится отдавать страницы из кеша вместо генерации их для каждого запроса.
В самом простом случае выбирается схема: авторизованные пользователи всегда получают сгенерированный ответ, незарегистрированные — получают страницу из кеша. Этих пользователей надо каким-то образом различать. Если у каждого пользователя будет только по сессионной куке, то для того, чтобы определить, авторизовался он, или нет, надо лезть в хранилище сессий php. Намного удобнее — при успешной авторизации проставлять какую-нибудь куку authiorised-as, и снимать ее после выхода.
Ссылок накидать вряд ли смогу, можете попробовать прочитать статью о кешировании на dklab.
Честно говоря, это — один из самых легкоисправимых пунктов этой статьи :)
И забили на Virtuozzo, хотя могли бы развивать так же, как раньше.
У Вас google apps?! :)
2.1) И что? Вы гарантируете, что в Вашем коде никогда не обнаружится подобного бага? Чем?
2.2) Бывает не только апач, особенно на высоконагруженной системе. Да и его можно сконфигурировать на регекспы, а не на расширения.
Про то, при чем тут ДокРут — не понял. Смысл в том, чтобы была специальная папка, которую нельзя поменять запросом из вебсервера, и чтобы только она могла исполняться.
2.1) Тем не менее, люди — не роботы, ошибки встречаются. Лучше уж «железно» застраховаться от них, чем надеяться на то, что код — без ошибок.
2.2) Веб-сервер смотрит на URI-запроса и решает, что же с ним делать — отдать пхп, отдать статикой или еще что-то.
2) В папке upload он может оказаться опять же в виде какой-нибудь ошибки, приводящей к заливке файла upload.php или upload.php.jpg. В основном, php матчат по регекспу \.php, а не \.php(\/|$), что позволит злоумышленнику выполнить upload.php.jpg как скрипт. Да и то, в данном случае, если злоумышленник сможет создать папку с именем что-то.php, и положить в нее свой jpeg, то он обработается.
Но неужели у Вас не было мест, которые можно было бы упростить, добавив ООП?
На очередную сухую статью о том, как правильно писать приложение, никто не обратил бы внимания, она не возымела бы эффекта — ведь таких написаны уже десятки, а все равно, ими никто не пользуется. А эта статья могла отложить больший отпечаток в памяти прочитавшего программиста, и, возможно, когда он будет писать следующее приложение, он задумается.
Получается, у Вас еще один «бонус» — можно разнести разные базы по разным серверам, а не мучиться с разнесением таблицы по серверам. А насколько это удобно управляется? Ведь какой-нибудь alter table на 1000 баз будет выполняться достаточно долго.
В самом простом случае выбирается схема: авторизованные пользователи всегда получают сгенерированный ответ, незарегистрированные — получают страницу из кеша. Этих пользователей надо каким-то образом различать. Если у каждого пользователя будет только по сессионной куке, то для того, чтобы определить, авторизовался он, или нет, надо лезть в хранилище сессий php. Намного удобнее — при успешной авторизации проставлять какую-нибудь куку authiorised-as, и снимать ее после выхода.
Ссылок накидать вряд ли смогу, можете попробовать прочитать статью о кешировании на dklab.
Честно говоря, это — один из самых легкоисправимых пунктов этой статьи :)
class Obj1 { public: virtual void move_right(); } class Obj2 : Obj1 { public: virtual void move_right(); } void do(Obj1* o) { o->move_right(); } int main() { vector<Obj1*> v; /* положить в v экземпляры Obj1 и Obj2 */ for(typeof(v.begin()) it = v.begin(); it != v.end(); ++it) do(it); }