Форум PHP

Доброго всем времени суток!

Обращаюсь ко всем кого интересует классы авторизации и аутентификация пользователя. На данный момент я занимаюсь его проектированием. И мне нужна поддержка и консультативная помощь в разработке.

Задача состоит в следующем
- создать объект авторизации который автоматизирует:
1. Процесс предоставления определенному лицу прав на выполнение некоторых действий;
2. Процесс подтверждения (проверки) прав пользователей на выполнение некоторых действий;
3. Проверка прав пользователя на осуществление транзакций, проводимая в точке обслуживания, результатом которой будет разрешение или запрет операций клиента (например, совершения акта купли-продажи, получения наличных, доступ к ресурсам или службам).
- создать объект аутентификации, который автоматизирует:
1. Проверка принадлежности субъекту доступа предъявленного им идентификатора;
2. Подтверждение подлинности.

Предлагаю начать со скелета класса авторизации:

<?php abstract class authorization {     //Члены класса     private $type;//тип авторизации по умолчанию по имени и паролю     private $name;//имя пользователя     private $email;//email пользователя     private $password;//пароль пользователя     //.. и тд          //Методы класса     //Конструктор класса     function __construct($name, $pass)     {        //инициализация      }          //Метод для проверки существования пользователя     abstract function checkName()     {     }          //Метод для формирования и отправки письма для подтверждения регистрации     abstract function sendEmail()     {     }          //Метод вызывающийся после подтверждения с емайл     abstract function recEmail()     {     }          //Метод добавления в бд пользователя     abstract function recDb()     {     }          //Метод передачи полномочий объекту аутентификации     abstract function sendAuth()     {     }           } ?>

Жду критики, мысли, высказывания , идеи ....

Заранее благодарю за поддержку!

Прошу прощения, модератор перенисите меня в РНР форум. Я поошибке в javascripte тему создал! И удалите это сообщение! Пожалуйста!

как бы ни о чём не вижу смысла ради 10 строк создавать класс с кучей методов

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

... и еще сам движок создается на ООП, каждый объект в модельной области для которой пишется сайт это класс и этот класс будет жить и реагировать на события средствами Ajax...

>... и еще сам движок создается на ООП, каждый объект в модельной области для которой пишется сайт это класс и этот класс будет жить и реагировать на события средствами Ajax...

Что-то мне сомнительно что результатом будет создание чего-то концептуально нового а по-сему скажу аббревиатурой ооп никого не удивишь и аяксу уже 100 лет(хотя ещё до появления данной технологии успешно использовался айфрейм-транспорт)

А вы не сомневайтесь, давайте вместе работать. Когда все сделается будете применять классы в своих проектах.

Я тоже ломанулся всё переводить на ООП, но понял, что всему своя мера .....
Много кода , сжирание памяти , найти концы практически невозможно ( в чужих проектах )
Перелопатил многие фреймворки .по системе вид - модель - контроллер ...
Ту логику и те базовые ссылки которые они генерируют и с которыми работают----> поисковики засунут глубоко в ж......
Какой бы у вас сайт был-бы не навороченый ,с фрейморками никогда не попадёте в топ

Чем проще тем лучше...как автомат Калашникова...а то ,что вам КОГДА-ТО ,в будущем пригодится...так это НАДО СПЕРВА ДОЖИТЬ ДО ЭТОГО БУДУЩЕГО...
Не надо бежать вперёд паровоза....

python круче php

ООП следует использовать тогда, когда в этом есть необходимость, тем более на PHP. Это на C++, слава Страуструпу, его можно использовать всегда - потери в производительности не будет, а на PHP только когда уже мочи нет и очевидно, что нужен свой мини-язык программирования или добиться повторного использования кода другими средствами слишком дорого.

Фреймворк - это шаблон под определенную задачу, т.е. чтобы каждый раз не писать все с нуля, используется фреймворк. Каждый фреймворк, заточен под свою задачу. Если определенный тип задач встречается у вас часто лучше писать свой фреймворк, под эту у вас частовстречающуюся задачу, а использовать чужой фреймворк под свою задачу следует только в том случае, если вы уверены, что он идеально подходит.

Я понял по словам, что на PHP использование ООП приводит к потере производительности.

Я стал переводить на ООП и пока не чувствую потерю производительности.

А как получить оценку потери?
Как мне спрогнозировать потерю и спланировать разумные ходы?

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

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

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

Чем вы оценивать производительность?

>Ну подтормаживает, ну помедленнее - и что?
Когда один пользователь, да ничего страшного... проблема в том, что сайты и сервисы разрабатывают для 1000 пользователей. Вложили деньги в маркетинг пришло 5000 - сервер лег, поднять никакой возможности и вообще не известно сколько нужно серверов, как их организовывать, чтобы выдержать такой наплыв. Пользователи же больше к вам не придут - бизнес рухнул. Это не досужие вымыслы - такая ситуация повторялась не один, и не раз во многих компаниях. Поэтому по-нормальному, нужно строить модель сервера, которую бы желательно проверять на практике, чтобы хоть чуть чуть моделировать ситуацию, понимая когда наступит предел и как к нему готовиться.

>Чем вы оценивать производительность?
Смотря чего... вообще не одну и не две книги по этому вопросу можно написать.

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

КАК ВЫ ХОТИТЕ ОЦЕНИВАТЬ ПРОИЗВОДИТЕЛЬНОСТЬ ОБЪЕКТИВНО. Я ЕЁ ИЗМЕРЯЮ ВРЕМЕНЕМ ИСПОЛНЕНИЯ СКРИПТА.

Время исполнения - основной объективный измеритель?

>Это не досужие вымыслы - такая ситуация повторялась не один
В данном случае ДОСУЖИЕ, так надо СУЖДЕНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, определить по законам ЛОГИКИ.
У вас производительность не имеет логического определения.
Как вы судите о производительности?

Mожно дать объективную оценку потери производительности не зависимую от субъективных чувств?

Обороты сбавьте, вы мне еще про субъективные чувства по-рассказывайте. На этом форуме в таком тоне беседа не ведется.

Время исполнения скрипта - это основной критерий. Это время у вас будет изменяться в зависимости от количества посетителей, объема памяти, нагрузки на процессор, диски, ширины канала. Фактически моделирование сервера сводится к построению функции отклика от количества обращений или построению экспериментальной кривой. Вот исходя из этого и принимаются проектные решения. Если у вас нагрузка на файловую систему - усиливается подсистема ввода-вывода, как правило аппаратными средствами, если основная нагрузка на базу данных - перепроектируется база данных - вводятся кэширующие таблицы или через репликацию подчиненные сервера. Чтобы нагрузка приходилась именно на PHP - это очень редкое явление, нужно, чтобы была какая-то число-дробилка, в этом плане да, можно не очень заморачиваться на то, классы у вас или функции. Впрочем это от задачи зависит и от того, как построен PHP-код (но это как правило, самый неприхотливый участок - в PHP огромное количество функций и написаны они на C).

Надо еще Вам теорию построить из миллиона гипотез и догадок, свести к многопричинности и туманности))

Притча
Один академик строил гипотезы и теории.
Академик поехал в Африку
А в Африке жил лев и не знал этих теорий, что академик специалист по теориям.
Лев съел академика чисто практически

Реальность
В нашем случае есть рынок и конкуренция.
Есть практические реалии этого рынка и конкуренции
Рынок съест всех, кто не считается с практической целесообразностью

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

Данная тема: "...реализация классов авторизации и аутентификации"
Вы такой туман нагородили, что никакого решения не нашли, а только все поперепутывали

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

Титаник строили профессионалы, Ноев ковчег – дилетант
Истина всегда где то рядом и никогда не достижима

Деньги платите - тогда будет все разложено по полкам. Или хотя бы научитесь разговаривать вежливо и слушать собеседника, а пока такими навыками не обладаете - покиньте форум.

А почему при добавлении обработки чего-то и без ООП потребуется все переписывать?

Под словом весь код системы имеется ввиду Систему Авторизации.

И как я понимаю ООП, мне только полиморфизм может построить правильный абстрактный тип авторизации от которого будут разветвляться разные типы авторизации, хоть по паролю, хоть по отпечатку, хоть по глазной роговице, хоть пофейс через веб камеру. Это все дело технологий и времени.

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

Мне ваша мысль и позиция понятна.

Давайте по сути, я выбрал ООП подход для написания системы авторизации как части администрирования так и представления.

Что вы можете дополнить или предложить для усовершенствования данного объекта?

Ничего. Я только и заметил по поводу "придется все переписывать", потому как это далеко не так, в данном случае. Не тот случай. )

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

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

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

Мне и нужна помощь в построении правильной модели ООП авторизации.
Вот я и начал со скелета абстракции модели.

>в финансовой части сайта авторизация проводится при использовании банковских платежных,
>кредитных и иных карт.
Вы задаете на абстрактном уровне методы recEmail() и sendEmail() - они будут использоваться при авторизации банковскими картами? Если нет, тогда им не место на этом уровне абстракции.

>- в обучающей части сайта авторизация проводится выдачей сертификатов
Это как? Т.е. как человек подтвердит что он, это он при помощи сертификата? Скан его вышлет? У вас класс называется authorization, могу ошибаться, но помоему вы хотите его нагрузить слишком большим количеством методов и способностью делать все. Создайте лучше десяток небольших классов, чем один большой (тем более в PHP с большим классом решительно неудобно работать).

>abstract function recDb()
Совершенно напрасно вводите здесь метод добавления пользователя - для пользователя просится свой класс, который будет отвечать за добавление, редактирование и удаление пользователя и назвать его лучше users, он может использовать экземпляр класса authorization, но наоборот лучше не делать.

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

Вообще изначально ООП вводился для больших систем, когда в одной голове невозможно было удержать огромное количество сущеностей и функций, которые их обрабатывали. PHP сам по себе плохо для таких задач подходит - слишком он медленный и не продуманный для больших проектов. Поэтому реальная потребность в ООП в нем возникает очень редко. Есть эмпирический признак, который срабатывает с высокой точностью. Если у вас в проекте больше десяти switch-переключателей (в case-операторах которых что-то отличное от присвоения значения перменной), вам можно задумываться об ООП. Если вы их не видите, ООП вам не нужен.