How to design an authorization page in terms of the MVC pattern in PHP?

Question

PHP

Hello!

Can you tell me how to design an authorization and registration page in terms of MVC?

I think that we need an object of the User class, which accepts a login password (and optionally a full name and email for registration) in the constructor.

You also need an AuthPage class that accepts this User, checks against the database and writes to cookies and session. In the case of a correct login password pair, it shows (through the View class) a personal account, if not, it shows an error. And the RegisterPage class that writes the User to the database?

Or am I writing nonsense at all, and no classes are needed and all this logic will be fine in index.php?

Answer 1

Or am I just writing nonsense

In general, yes. But

All this logic will be fine in index.php?

- this is much more stupidity.
Well, that is, it will lie, but it will have nothing to do with MVC.
According to the points
, the User should not accept a login and password in the constructor.
Right now this page shows me two users besides me. They both need to be created with a username and password, seriously?
What is AuthPage is generally unclear. Model, controller? The model checks the database, the controller writes cookies. And here is some cadaver.
Before writing authorization "in the style of MVC", you must first understand what is a model, what is a controller, and what is a view.
The model is the entire logic of the application.
The controller is the interface for the model to communicate with the browser . Does everything related to processing HTTP requests.
View - display.
How right.
Accordingly, the model must have a User class with an auth () method that accepts a login and password and returns an instance of the User class. An action
is made in the office : a separate method that - checks if there was a request using the POST method, then takes the login and password from it, - validates them, if the validation did not pass, then it creates an error that must be shown to the user - if passed, then calls the method auth() of the User model, passing the login and password to it - if they match, then writes the user id to the session, and makes a redirect somewhere - if they don’t match, then it creates an error that needs to be shown to the user - calls a view with a form for login and password
For registration, another action is made, which
- checks if there was a request using the POST method, then takes data for registration from it,
- validates them, if validation did not pass, then creates an error that must be shown to the user
- if passed, then fills the class User data and executes the save() method and redirects somewhere
- calls a view with a registration form
For the personal account, a third action is made that takes the user ID from the session, calls the read() method of the User model and shows the personal account through the View
Options implementations
The simplest implementation of a controller is a folder with separate action files. There is nothing wrong with such an architecture, this stage must be passed if it has not been done before.
That is, the user folder in which there is, say, the index.php file, which is the action of the personal account.
It checks the user in the session, and if not, it redirects to auth.php
in auth.php there is a form and a link to register.php
All three files include the user.php file from the model folder, which contains the auth () functions, register() and profile()
But in a more classic version, one more is added to the three letters MVC - R, router. A special service that parses the address bar, and seeing, for example, that the site was accessed at /user/register, creates an instance of the UserController class and calls its register() method

Answer 2

Controller LoginController
Model User
View with login form

Answer 3

MVC? Easily.
==== Login method ====
Entity - authorization sessions.
Login Attempt - Create an entry with validation rules. The validation rules check that the correct input is entered, the user is not locked out, the password matches, and so on.
In case of a successful login, set a cookie with a callback. The cookie contains a token, the key to which is stored in the session record in the database.
==== Session support ====
At each request, including AJAX, we read the authorization cookie. We are looking for a session, checking the key, session activity (expiration), user rights.
We can record in the user's properties that he is online.
We can write its properties (or at least an identifier) ​​to the authorized user class.
==== Exit ====
If there are no cookies, do nothing, just redirect to the main page.
If there is a cookie, find the session and deactivate it. You can delete the cookie. It is possible not to delete if you are collecting a digital footprint - for example, you want to track multi-accounts, etc.