Задать вопрос
DPhil
@DPhil
Контент-менеджер

Как спроектировать страницу авторизации с точки зрения паттерна MVC на PHP?

Здравствуйте!

Не подскажите, как спроектировать страницу авторизации и регистрации с точки зрения MVC?

Я думаю, что нужен объект класса User, который принимает в конструктор логин пароль (и опционально -- ФИО и email для регистрации).

Также нужен класс AuthPage, который принимает этого User, проверяет по базе и пишет в куки и сессию. В случае правильной пары логин пароль показывает (через класс View) личный кабинет, если нет, то показывает ошибку. И класс RegisterPage, который записывает User в базу?

Или же я вообще пишу глупость, и никакие классы не нужны и вся эта логика прекрасно будет в index.php лежать?
  • Вопрос задан
  • 1092 просмотра
Подписаться 6 Простой 3 комментария
Решения вопроса 1
FanatPHP
@FanatPHP
Чебуратор тега РНР
Или же я вообще пишу глупость

В целом да. Но

вся эта логика прекрасно будет в index.php лежать?

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

По пунктам

Юзер не должен принимать в конструкторе логин и пароль.
Вот сейчас эта страница отображает мне двух юзеров помимо меня. Их обоих надо создавать с логином и паролем, серьёзно?

Что такое AuthPage вообще непонятно. Модель, контроллер? По базе проверяет модель, куки пишет контроллер. А здесь какой-то кадавр.

Перед тем как писать авторизацию "в стиле MVC", надо сначала разобраться, что такое модель, что такое контроллер, и что такое вью.

Модель - это вся логика приложения.
Контроллер - это интерфейс для общения модели с браузером. Делает всё, связанное с обработкой НТТР запросов.
Вью - отображение.

Как правильно.

Соответственно в модели должен быть класс User с методом auth(), который принимает логин и пароль и возвращает инстанс класса Юзер.
В конторе делается экшен: отдельный метод, который
- проверяет, если был запрос методом ПОСТ, то берет из него логин и пароль,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то вызывает метод auth() модели User, передавая в него логин и пароль
- если совпали, то пишет в сессию ид юзера, и делает редирект куда-нибудь
- если не совпали, то создает ошибку, которую надо показать юзеру
- вызывает вью с формой для логина и пароля

Для регистрации делается еще один экшен, который
- проверяет, если был запрос методом ПОСТ, то берет из него данные для регистрации,
- валидирует их, если валидация не прошла, то создает ошибку, которую надо показать юзеру
- если прошла, то то заполняет класс User данными и выполняет метод save() и делает редирект куда-нибудь
- вызывает вью с формой для регистрации

Для личного кабинета делается третий экшен, который берет из сессии ид юзера, обращается к методу read() модели User и через View показывает личный кабинет

Варианты реализации

Самый простой вариант реализации контроллера - это папочка с отдельными файлами-экшенами. Ничего плохого в такой архитектуре нет, этот этап надо пройти, если раньше так не делали.

То есть папка user в которой есть, скажем, файл index.php который является экшеном личного кабинета.
Он проверяет юзера в сессии, и если нету, то перекидывает на auth.php
в auth.php есть форма и ссылочка на register.php
Все три файла инклюдят в себя файл user.php из папки model, в котором есть функции auth(), register() и profile()

Но в более классическом варианта к трем буквам MVC добавляется ещё одна - R, роутер. Специальный сервис, который разбирает адресную строку, и видя, например, что к сайту обратились по адресу /user/register, создаёт экземпляр класса UserController и вызывает его метод register()
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
delphinpro
@delphinpro Куратор тега PHP
frontend developer
Контроллер LoginController
Модель User
Представление с формой логина
Ответ написан
customtema
@customtema
arint.ru
MVC? Легко.

==== Метод входа ====
Сущность - сессии авторизации.
Попытка входа - создание записи с правилами валидации. Правила валидации проверяют, что введено то, что надо, пользователь не заблокирован, пароль совпадает и т.д.
В случае удачного входа колбеком ставить куку. В куке токен, ключ от которой хранится в записи сессии в БД.

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

==== Выход ====
Если нет куки - ничего не делать, просто редирект на главную.
Если есть кука - найти сессию и деактивировать её. Можно удалить куку. Можно не удалять, если вы собираете цифровой след - к примеру, хотите отслеживать мультиачье и т.п.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы