Светлана PHP
Guest
Мы не собираемся скрывать то, что лучшие программисты нашли дыры которые были в одночасье исправлены. Хотя лично я думаю, что тему сотрут.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
betik
Новичок
Светлана ПеХеПе...
Собственно моя CMS работает, но до выкладывания демок мне (нам) ещё очень далеко...
Кстати, зачем вы включили отладчик в демке?
ИМХО всю инфу нужно пихать в логи за пределами веб-сервера, а пользователю отдавать страничку что всё нормально прошло... И пускай хакер думает что и без него всё поломано =))))
Собственно моя CMS работает, но до выкладывания демок мне (нам) ещё очень далеко...
Кстати, зачем вы включили отладчик в демке?
ИМХО всю инфу нужно пихать в логи за пределами веб-сервера, а пользователю отдавать страничку что всё нормально прошло... И пускай хакер думает что и без него всё поломано =))))
Светлана PHP
Guest
Бетик. Я даже не знаю как до тебя до нести... Ну отдали на растерзание, что-ли.
Удачи Вам в продвижении твоей CMS
Удачи Вам в продвижении твоей CMS
![t3[0one]](/talk/data/avatars/m/0/739.jpg?1507973220){kind=avatar}
Светлана PHP
Guest
ONK
http://www.a2c-cms.ru/news/more.phtml?com5=4
Любая попытка взлома будет воспринята с приветствием
-~{}~ 20.04.05 18:50:
Ой... А "продвинутым новичком" я, прости господи, наверное автоматом стала... Нафлеймила...
-~{}~ 20.04.05 18:50:
Извините.
http://www.a2c-cms.ru/news/more.phtml?com5=4
Любая попытка взлома будет воспринята с приветствием
-~{}~ 20.04.05 18:50:
Ой... А "продвинутым новичком" я, прости господи, наверное автоматом стала... Нафлеймила...
-~{}~ 20.04.05 18:50:
Извините.
Светлана PHP
Guest
Kelkos
Правда и только правда.
Правда и только правда.
Светлана PHP
Guest
t3[0one]
Да ладно тебе. Никто не "отнюкивается". Будь проще. А то тут был некий Чан: тоже накручивал себе да накручивал...
Да ладно тебе. Никто не "отнюкивается". Будь проще. А то тут был некий Чан: тоже накручивал себе да накручивал...
Светлана PHP
Guest
Повторюсь, открыт "демо" раздел. Добропожаловать.
И ещё раз... Это я автоматом продвинутм новичком стала... А то нигде тут в факах об этом не написано
И ещё раз... Это я автоматом продвинутм новичком стала... А то нигде тут в факах об этом не написано
chaan
Guest
Мысли на тему: какой функционал включать в ядро.
Чем в моем понимании отличается встраивание в ядро от запуска в виде модуля? А тем что, если модуль включен в ядро, то не происходит проверка его наличия в системе.
Пример 1 : модуль рекламы. Основная функция -- это показ баннеров. Дополнительная -- узконаправленная реклама. Соотв., показ осуществляется в любом случае, а узконаправленная реклама возможна лишь при наличии функционала. Короче, модуль рекламы НЕ СМОЖЕТ работать без получения данных, например, т.е. в базовый функционал(в ядро) должен входить модуль получения данных(пусть будет БД). Проверка на наличие модуля "БД" НЕ ПРОВОДИТСЯ. А узконаправленная реклама возможна лишь при наличии модуля сбора статистики, и, если модуль присутствует в системе, то используются его методы, если же модуль отсутствует, модуль рекламы продолжает свою работу, теряя в функционале.
Из примера можно резюмировать, что модули можно разделить(в данном конкретном примере, исключая модули управления и т.п.) на обеспечивающие базовый функционал и расширяющие функционал. Конечно, от проекта к проекту набор модулей разниться. Но все же хотелось бы определить базовый функционал для проектов среднего уровня, корпоративных.
Мое мнение, базовый функционал:
1. Класс Модули(Подключени, инсталяция и т.д.). Должен быть в любом проекте, возможно, где-то можно урезать функционал, например, удалить установку новых модулей, если система того не требует.
2. Класс Файлы(Создание, запись, чтение и т.д.). Т.к. в почти на всех сайтах есть админка, можно вывести, что изменение конфигов через интерфейс требует операций над файлами.
3. Класс ДБ. Опять же почти все современные сайты завязанны на БД, => без этого класса тоже трудно.
4. Класс Валидатор. Конечно, для ну очень простого проекта можно написать очень простые ограничения в самом скрипте, но в Классе все уже отработанно и протестированно.
5. Класс Обработчик(Убираем кавычки, обрабытываем пере БД). Функционал(почти весь) данного класса можно реализовать с помощью стандартных функций, но централизация страдает. Во множестве случаев, кстати, мне приходилось писать обработчик в самом модуле, т.к. обработка требовалась уникальная.
Дополнительные модули, расширяющие функционал: статистика, обработчик ошибок, реклама и т.д.
Управляющие(+отвечающие за вывод, например, комментарии): форум, голосование, авторизация пользователей(НЕ СТАТИСТИКА) и т.д.
Что думаете о таком разделении?
П.С. Сейчас пишу CMF систему. Там из описанных мною модулей в ядро встроен только Класс Модули. Т.е. ядро -- это лишь среда для работы всех модулей. Система делиться на несколько уровней. От проекта к проекту можно варьировать наличие модулей, т.е. функционал. У каждого модуля есть ТРЕБОВАНИЯ, они деляться на обязательные, без которых модуль работать не будет, и желательные, бех которых функционал модуля уменьшается.
Чем в моем понимании отличается встраивание в ядро от запуска в виде модуля? А тем что, если модуль включен в ядро, то не происходит проверка его наличия в системе.
Пример 1 : модуль рекламы. Основная функция -- это показ баннеров. Дополнительная -- узконаправленная реклама. Соотв., показ осуществляется в любом случае, а узконаправленная реклама возможна лишь при наличии функционала. Короче, модуль рекламы НЕ СМОЖЕТ работать без получения данных, например, т.е. в базовый функционал(в ядро) должен входить модуль получения данных(пусть будет БД). Проверка на наличие модуля "БД" НЕ ПРОВОДИТСЯ. А узконаправленная реклама возможна лишь при наличии модуля сбора статистики, и, если модуль присутствует в системе, то используются его методы, если же модуль отсутствует, модуль рекламы продолжает свою работу, теряя в функционале.
Из примера можно резюмировать, что модули можно разделить(в данном конкретном примере, исключая модули управления и т.п.) на обеспечивающие базовый функционал и расширяющие функционал. Конечно, от проекта к проекту набор модулей разниться. Но все же хотелось бы определить базовый функционал для проектов среднего уровня, корпоративных.
Мое мнение, базовый функционал:
1. Класс Модули(Подключени, инсталяция и т.д.). Должен быть в любом проекте, возможно, где-то можно урезать функционал, например, удалить установку новых модулей, если система того не требует.
2. Класс Файлы(Создание, запись, чтение и т.д.). Т.к. в почти на всех сайтах есть админка, можно вывести, что изменение конфигов через интерфейс требует операций над файлами.
3. Класс ДБ. Опять же почти все современные сайты завязанны на БД, => без этого класса тоже трудно.
4. Класс Валидатор. Конечно, для ну очень простого проекта можно написать очень простые ограничения в самом скрипте, но в Классе все уже отработанно и протестированно.
5. Класс Обработчик(Убираем кавычки, обрабытываем пере БД). Функционал(почти весь) данного класса можно реализовать с помощью стандартных функций, но централизация страдает. Во множестве случаев, кстати, мне приходилось писать обработчик в самом модуле, т.к. обработка требовалась уникальная.
Дополнительные модули, расширяющие функционал: статистика, обработчик ошибок, реклама и т.д.
Управляющие(+отвечающие за вывод, например, комментарии): форум, голосование, авторизация пользователей(НЕ СТАТИСТИКА) и т.д.
Что думаете о таком разделении?
П.С. Сейчас пишу CMF систему. Там из описанных мною модулей в ядро встроен только Класс Модули. Т.е. ядро -- это лишь среда для работы всех модулей. Система делиться на несколько уровней. От проекта к проекту можно варьировать наличие модулей, т.е. функционал. У каждого модуля есть ТРЕБОВАНИЯ, они деляться на обязательные, без которых модуль работать не будет, и желательные, бех которых функционал модуля уменьшается.
Светлана PHP
Guest
chaan
Ну вот смотри...
Допустим, у тебя есть модуль, который для администратора системы представлен определённым интерфейсом, сутью которого является совокупность ссылок, позволяющих совершать действия.
Я полагаю, ты желаешь включить в свою CMF систему распределённого пользовательского доступа... Ведь так? И согласись, что не все пользователи будут иметь возможность совершать определённые действия?
Именно поэтому, идентификация пользователя (браузера если хочешь) является неотъемлимой задачей ядра системы. Конечно ядро может записать определённые данные в сессию один раз... Но не факт, что пользователь будет пользоваться исключительно ссылкой ведущей на вход в систему, те постоянно придётся проверять, а есть ли эти данные, записаны ли они.
Куда ты в своей "структуре" дел базовое: разделение представления и логики? Спрятал в класс Файлы?
Понятие "Обработчик" довольно не двусмысленное - его привыкли связывать с понятием СОБЫТИЕ, но никак с набором функций.
И не путай классы с областями видимости.
-~{}~ 25.04.05 23:54:
chaan
Ядро - это тоже модуль. Самый главный модуль. Если оно у тебя не будет являться модулем, то ты его не сможешь обновлять...
Даже если судить из твоей схемы - подключение, инсталяция и пр.
Ну вот смотри...
Допустим, у тебя есть модуль, который для администратора системы представлен определённым интерфейсом, сутью которого является совокупность ссылок, позволяющих совершать действия.
Я полагаю, ты желаешь включить в свою CMF систему распределённого пользовательского доступа... Ведь так? И согласись, что не все пользователи будут иметь возможность совершать определённые действия?
Именно поэтому, идентификация пользователя (браузера если хочешь) является неотъемлимой задачей ядра системы. Конечно ядро может записать определённые данные в сессию один раз... Но не факт, что пользователь будет пользоваться исключительно ссылкой ведущей на вход в систему, те постоянно придётся проверять, а есть ли эти данные, записаны ли они.
Куда ты в своей "структуре" дел базовое: разделение представления и логики? Спрятал в класс Файлы?
Понятие "Обработчик" довольно не двусмысленное - его привыкли связывать с понятием СОБЫТИЕ, но никак с набором функций.
И не путай классы с областями видимости.
-~{}~ 25.04.05 23:54:
chaan
Ядро - это тоже модуль. Самый главный модуль. Если оно у тебя не будет являться модулем, то ты его не сможешь обновлять...
Даже если судить из твоей схемы - подключение, инсталяция и пр.
3BEP
Новичок
Пример:
Существует работающая система с хранением данных пользователя в БД. После перевода сайта на выделенный сервер, для повышения уровня защиты, принимается решение использовать Unix'овую систему хранения пароля (/etc/shadow).
Теперь для случая включения авторизации в ядро, возникает необходимость поддержки двух веток ядра. С хранением пароля в БД и с хранением пароля в /etc/shadow. Проблемы в поддержкой двух веток ядра мне расписывать?
В случае выделения авторизации в модуль - возникает всего лишь еще один модуль. Поддержка одного модуля уже отлажена на менне критичных для системы модулях, не так ли?
Существует работающая система с хранением данных пользователя в БД. После перевода сайта на выделенный сервер, для повышения уровня защиты, принимается решение использовать Unix'овую систему хранения пароля (/etc/shadow).
Теперь для случая включения авторизации в ядро, возникает необходимость поддержки двух веток ядра. С хранением пароля в БД и с хранением пароля в /etc/shadow. Проблемы в поддержкой двух веток ядра мне расписывать?
В случае выделения авторизации в модуль - возникает всего лишь еще один модуль. Поддержка одного модуля уже отлажена на менне критичных для системы модулях, не так ли?
chaan
Guest
На счет "путания" классов с пространством имен. Я просто использую клаассы, как namespaces, т.к. для другой цели их применение мне пока не требовалось.
С разделением прав. Как я понимаю, это касасется только admin area. Конечно, если использовать что-то вроде "drag-and-drop", то встраивание распознавания пользователя возможно. Может я не вижу в чем плюс встраивания в ядро распознования, тогда опиши плюсы.
Классы/Модули там, ессно, описанны не все. Есть шаблонизатор и др. Просто это я не описывал, т.к. это вторично, по крайней мере для этой темы.
Вообще, хотелось бы услышать мнение тех, кто уже имеет большой опыт разработки/проектирования подобных систем.
С разделением прав. Как я понимаю, это касасется только admin area. Конечно, если использовать что-то вроде "drag-and-drop", то встраивание распознавания пользователя возможно. Может я не вижу в чем плюс встраивания в ядро распознования, тогда опиши плюсы.
Классы/Модули там, ессно, описанны не все. Есть шаблонизатор и др. Просто это я не описывал, т.к. это вторично, по крайней мере для этой темы.
Вообще, хотелось бы услышать мнение тех, кто уже имеет большой опыт разработки/проектирования подобных систем.
