четверг, июля 23, 2009

PHP DataGrid: ну ё-моё

Набрёл в инете на универсальное решение по работе с табличными данными: PHP DataGrid. С досады озвучил заголовок. Буквально в прошлом месяце по неведению изобрёл велосипед... ну ладно, велосипедик, трёхколёсный такой:



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

Подумал... решил оставить. Во-первых, труда жалко. Во-вторых, построение более-менее сложного запроса в DataGrid — процесс многословный, а главное — трудноохватываемый глазом; в моих функциях извлечения-сохранения данных всё гораздо более очевидно. В общем, Мерседес — это хорошо, но иногда Марч уместнее. И главное: в своих функциях я знаю все входы-выходы и могу шить там любыми нитками. А просто на доскональное изучение DataGrid надо потратить много часов.

Однако, надо как-то своё велосипедное КБ прикрывать. Все наши проблемы чаще всего уже решены, надо почаще вспоминать эту истину.

3 комментария:

Mixa комментирует...

Cудя по результатам поиска, Вы единственный, кто написал о PhpDataGrid на русском. Поэтому спросить больше не у кого...

Я начинающий в порграммировании. Сделал на примерах свою базу данных. И вот теперь думаю как сделать так чтобы защитить данные от правки. Ведь даже если я могу сделать так что кнопки добавления/редактирования будут появляться только для залогиненного админа, то простой модификайцией в адресе запроса на ?f_mode=add или ?f_mode=edit поиграться с моей базой сможет любой желающий. Что-то я не нашел на сайте разработчика мануалов по данному поводу. Может, Вы подскажете?
Зараннее спасибо!

Сергей комментирует...

Включать админский режим в строке запроса - это не защита даже, это заходи кто хошь, бери что хошь.

Не буду сильно вдаваться в детали по понятным причинам, но в моих проектах админский режим включается посещением запаролированного каталога, где посетитель (залогинившись) получает cookie с хешированным ключом и возвращается откуда пришёл. В дальнейшем присутствие этого cookie в запросе управляет режимом доступа. Все обработчики операций изменения данных также лежат в том же каталоге, то есть даже если стырить валидный ключ из залогиненного браузера, то увидеть админские опции можно, но при попытке сохранить изменения выскочит окошко логина, т. е. для таких операций браузер должен предоставить не только cookie, но и реквизиты аутентификации пользователя.

Такая схема удобна тем, что некритичные обработчики можно вынести в незащищённую область. Например, cookie обычного зарегистрированного посетителя сайта может быть достаточно, чтобы запостить какой-нибудь комментарий, а, например, для изменения текста страницы обработчик находится в auth-realm, и хоть головой бейся.

Это вообще никак не относится к PhpDataGrid, но как подход к управлению доступом - удобно и проверено.

Сергей комментирует...

Для действительно критичных применений, когда надо исключить "человека посередине" (например, слушающего трафик в локальной сети), просто меняется протокол с http на https. Практически все провайдеры хостинга предоставляют https, однако далеко не все позволяют использовать собственный сертификат (приобретённый официально), а просто используют свой самодельный сертификат. На практике это означает, что пользователю, вошедшему по https, придётся явно разрешить браузеру принять этот сертификат как подлинный. Поскольку чаще всего админов на сайте единицы, это не такая уж проблема. Если по https должны работать все посетители (денежные операции, например), это большая проблема.

Поиск по этому блогу