Форум → Программирование → PHP для идиотов → Контролируемое скачивание файлов и всякое такое
Контролируемое скачивание файлов и всякое такое
Страницы: ← Следующая страница →
-
10 февраля 2009 г. 18:23, спустя 3 часа 24 минуты 58 секунд
весьма косвенным образом. код становится более структурированным, и допустить любого рода ошибку тяжелее.
а вообще не надо путать ооп с логикой приложения - это принципиально разные вещи. -
11 февраля 2009 г. 4:11, спустя 9 часов 47 минут 45 секунд
О, спасибо. Подходит! А путать одно с другим мне пока "положено" ))
Интересно, тема безопасности ООП исчерпана? Есть ли какие-то особые советы в эту тему?
(хотя я сам видимо не знаю и обычных). -
11 февраля 2009 г. 4:16, спустя 4 минуты 54 секунды
ООП - стиль программирования, основанный на объектах и абстракции. Также популярен процедурный метод. никаким образом они не влияют на безопасность скрипта. -
11 февраля 2009 г. 10:09, спустя 5 часов 53 минуты 35 секунд
О, спасибо. Подходит! А путать одно с другим мне пока "положено" ))
Интересно, тема безопасности ООП исчерпана? Есть ли какие-то особые советы в эту тему?
(хотя я сам видимо не знаю и обычных).
Если не говорить о безопасности, то в ООП не решено много проблем. Для их решения служат всякого рода паттерны, которые пришли из языка Java(полностью объектно-ориентированный язык), но и паттерны - не есть панацея от всех бед.
Уточни, что ты имеешь ввиду безопасность? -
11 февраля 2009 г. 11:26, спустя 1 час 16 минут 51 секунду
Мне показалось что помимо удобства, еще и … я ща представил начнется разговор что я не понимаю … короче говоря, безопаснее вижу хотя бы тем, что скрипт не вызывается напрямую, а через … ну как функция (?). Правда мозгом ощупываю, не может ли … извините если скажу глупость, ну короче через наследственность (?) появиться дыра, примерно как с GLOBALS-ON. Т.е. через дыру в каком-то модуле вызвать какой-то более ответственный и более разрушительный функционал, или прочитать значения переменных … чтоли …
В общем, хотелось бы знать, не несет ли эта универсальность негативных моментов. Потому как оптимала в реальности похоже что не бывает … -
11 февраля 2009 г. 11:35, спустя 8 минут 37 секунд
Мне показалось что помимо удобства, еще и … я ща представил начнется разговор что я не понимаю … короче говоря, безопаснее вижу хотя бы тем, что скрипт не вызывается напрямую, а через … ну как функция (?). Правда мозгом ощупываю, не может ли … извините если скажу глупость, ну короче через наследственность (?) появиться дыра, примерно как с GLOBALS-ON. Т.е. через дыру в каком-то модуле вызвать какой-то более ответственный и более разрушительный функционал, или прочитать значения переменных … чтоли …
В общем, хотелось бы знать, не несет ли эта универсальность негативных моментов. Потому как оптимала в реальности похоже что не бывает …
Такую погрешность можно допустить и без ООП. -
11 февраля 2009 г. 20:05, спустя 8 часов 29 минут 46 секунд
Не про PHP, а в мировом масштабе: один из "факторов риска" — неконтролируемая свалка глобальных имен. При иcпользовании неймспейсов и классов порядка становится больше.
т.е. ООП косвенно повышает безопасность :)ιιlllιlllι унц-унц -
11 февраля 2009 г. 20:08, спустя 3 минуты 42 секунды
каждому программисту по ООП! чтобы ХУЙ СТОЯЛ!Сапожник без сапог -
-
-
12 февраля 2009 г. 4:59, спустя 8 часов 37 минут 42 секунды
Хорошо, спрошу более конкретно. А пароль доступа к базе хранить следует прямо в классе с функциями БД? Или всектаки выносить?
Означает ли что такие пароли нельзя хранить в константах?
Может покажете что почитать? -
12 февраля 2009 г. 5:01, спустя 1 минуту 26 секунд
Хорошо, спрошу более конкретно. А пароль доступа к базе хранить следует прямо в классе с функциями БД? Или всектаки выносить?
куда его выносить в бд?)
хранить в классе в приватном свойстве. -
12 февраля 2009 г. 5:02, спустя 1 минуту 19 секунд
Нет, выносить в инклюд, или вообще "вверх" за паблик (где хост позволяет) -
12 февраля 2009 г. 5:05, спустя 3 минуты 24 секунды
Malenkiy, какой смысл? Если получат доступ к хосту то вытянут оттуда где паблик позволяет.
Страницы: ← Следующая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!