Авторизация, скрипты

[ekkl]

Вопрос скорее философский.

Пишу CMS возникает вопрос системы авторизации.

Лучше писать свою с нуля, или переделывать какую-нибудь готовую под свои нужды. Кто как делает?

[wwt]

это более глобальный вопрос тогда уж ))

 

"Писать свою CMS с нуля, или использовать какую-нибудь готовую"

 

))Написать систему авторизации не так сложно как кажется, но вот обеспечить большой уровень безопасности, привентить всякие фичи типо ролей и тд уже не так легко как кажется.

 

Так что делайте как сами считаете нужным ) Я бы написал сам раз уж начал писать сам CMS

[ekkl]

Ну если уж совсем честно, то пишу не с нуля, а на базе Коханы. Имеющаяся система авторизации мне не подходит.

Просто не встречал более-мение готового модуля авторизации, чтобы подошёл. Смотрел на hotscript. Систем авторизации там, конечно хватает, но есть платные, есть старые, еще с 2008 года, есть заумные. Порой кажется, проще действительно написать свою, чем, как кто-то сказал: "рыться в чужих кишках".

[wwt]

  On 11/28/2013 at 3:27 PM, ekkl said:

Ну если уж совсем честно, то пишу не с нуля, а на базе Коханы. Имеющаяся система авторизации мне не подходит.

Просто не встречал более-мение готового модуля авторизации, чтобы подошёл. Смотрел на hotscript. Систем авторизации там, конечно хватает, но есть платные, есть старые, еще с 2008 года, есть заумные. Порой кажется, проще действительно написать свою, чем, как кто-то сказал: "рыться в чужих кишках".

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

Edited November 29, 2013 by wwt

[Radiocity]

  On 11/29/2013 at 5:40 AM, wwt said:

Чем конкретно не устраивает модуль коханы?

 

Присоединяюсь к вопросу

Edited November 29, 2013 by Radiocity

[ekkl]

Малый функционал.

Не хочу с ORM связываться.

Права доступа хочу сделать немного не так.

[wwt]

  On 11/30/2013 at 3:43 PM, ekkl said:

Малый функционал.

Не хочу с ORM связываться.

Права доступа хочу сделать немного не так.

Вы видимо не поняли идеологии фреймворков. И в частности коханы. Весь её функционал можно изменить не трогая ядра системы. И использовать ORM не обязательно, в кохане работа с БД организована 3-мя способами. Кроме обычной работы с БД там есть Query Builder и ORM. Что использовать вы можете выбирать сами. Плюс можно использовать всё сразу или по отдельности.

Так же дополнить или изменить функционал модуля авторизации так же можно как угодно. Кстати сказать про права. В модуле авторизации вы можете просто добавлять пользователей в группы, это реализовано ролями. Но при этом самого описания ролей там нет. Это отдано на откуп программисту. К любой роли вы можете прикрутить всё что угодно.

Edited December 1, 2013 by wwt

[ekkl]

Согласен на все 100% Работу фреймворка я понял и его предназначение. Вопрос в был в том: писать свой функционал полностью, или есть что-то готовое, которое можно подправить под свои нужды (не трогая ядра)

  On 12/1/2013 at 10:25 AM, wwt said:

Так же дополнить или изменить функционал модуля авторизации так же можно как угодно

Вот тут я и искал "что-то дополненое"

[wwt]

  On 12/3/2013 at 2:46 PM, ekkl said:

под свои нужды (не трогая ядра)

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

[ekkl]

Спасибо. Я знаю как переопределять классы. Достаточно создать одноименный класс в папке application

Вопрос стоял только о готовом классе авторизации (или модуле)

Буду, значит, писать свой с нужным мне уровнем привилегий. И т.д

--

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

  On 12/3/2013 at 5:25 PM, wwt said:

свой класс наследующий класс Auth

Можно и так, а можно и полностью свое. Дело в том, что Auth то абстрактный, его 100% нужно будет переопределять. Кстати так и задумано.

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

Уже потом, вдруг чего буду обращаться.