совет + .htaccess

[antonim]

совет + .htaccess

вкратце опишу вопросы:

1.
В лижайшие дни должны дать 1-й проект не сложный. Опыта пока почти нет. Так для тренировки делал сайт по динамическому созданию страничек + админка в которой создавать страницы ну сообтетственно работа с мускулем. А вот ООП не использовал т.к. не представлял даже зачем нужны объектыв таком примере. Хотел спросить когда соит применять ООП и для чего. Был бы рад ссылкам на толковые источники не сильно замные. как создавать классы и объекты я знаю... но в практике пока не использовал. Вот такая вот, наверно размытая, просьба.

2.
сделал в админке запрос логина и пароля через .htaccess ну создал .htpasswd все как пологается. Теперь хочу дать возможность админу менять логин и пароль соответственно раотать нужно с .htpasswd как это делать не нашел... подскажите плз.

 

[Alexandre]

Хотел спросить когда соит применять ООП и для чего.

ООП - это идеалогия.
самое простое использование, я бы сказал - первоночальное использование ООП, это сделать классы для доступа к БД, сессиям, форматированию изображений... ну и к тому, что имеет повторяющийся код.

Но, ООП - это прежде всего моделирование поведения твоей системы, по этому выделяются разные сущности модели и они реализуются как система взаимодействующих классов...

Если ты не понимашь, зачем тебе его использовать, то лучше его не использовать... Предварительно лучше почитать книги по основам ООП

 

[dimagolov]

2 - глупая идея. ты ограничиваешь доступ к скрипту сердствами веб-сервера, а потом позволяешь скрипту (не факт что твоему "авторизированному") менять права доступа. то есть создав такие условия, когда содержимое .htaccess может изменять скрипт php ты создаешь дырищу в безопастности.

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

 

[Фанат]

dimagolov, ой да ладно тебе, дырищами пугать.

 

[antonim]

Автор оригинала: Alexandre
ООП - это идеалогия.
самое простое использование, я бы сказал - первоночальное использование ООП, это сделать классы для доступа к БД, сессиям, форматированию изображений... ну и к тому, что имеет повторяющийся код.

Но, ООП - это прежде всего моделирование поведения твоей системы, по этому выделяются разные сущности модели и они реализуются как система взаимодействующих классов...

Если ты не понимашь, зачем тебе его использовать, то лучше его не использовать... Предварительно лучше почитать книги по основам ООП

На сегодняшний день повторяющийся код выношу в отдельные файлы и использую инклуды. Таким же образом и доступ к базам у меня реализован т.к. требуется он в нескольких файлах. Если я прально понял вы советуете в этом отделно файле, где реализуестя доступ к БД сделать класс и функцию доступа, затем занести в суперглобальный массив объектов и использовать в файлах или как-то подругому вы имели в виду? Если так то встает вопрос.. зачем это делать? Понятно что так получиться ПОО но кода больше в итоге... может так безопаснее?

-~{}~ 13.11.08 11:59:

Автор оригинала: dimagolov
2 - глупая идея. ты ограничиваешь доступ к скрипту сердствами веб-сервера, а потом позволяешь скрипту (не факт что твоему "авторизированному") менять права доступа. то есть создав такие условия, когда содержимое .htaccess может изменять скрипт php ты создаешь дырищу в безопастности.

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

каким образом это неавторизированный пользователь сможет поменять пароль? понятно что код сменыпароля буедет доступен только админу. Если злой сосед сможет взломать пароль .htaccess, то тогда какая разница сможет он все удалить или поменчть пароль в кайнем случае если это произойдет просто залью новый файл паролей... с БД это конечно проще сделать, но тогда не через .htaccess, а я через него хочу.

 

[Фанат]

Безопасность к ООП никакого отношения не имеет.

Что такое "суперглобальный массив объектов" мне неизвестно, но зачем делать класс работы с БД, я могу объяснить.

Работая с БД, быстро приходишь к выводу, что было бы удобно иметь три функциии - get_scalar(), get_row() и get_array()
В принципе, еще не причина класть в класс. Но мы можем захотеть логировать наши запросы, измерять время выполнения каждого, и иметь удобный доступ к этой статистике. Здесь уже будет удобно, если перечисленные функции будут пользоваться единым методом query внутри себя, при том, что никому снаружи он не нужен.
Вот так потихоньку класс у тебя и выстроится.

 

[zerkms]

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

ещё хороший аргумент: соединяться с несколькими базами

 

[Фанат]

Ну, это не сильно аргумент. Надо в 1 случае из тыщи, и реализуется в том скрипте, в котором это надо, совсем несложно.