W
W
WebDev2018-12-03 10:39:27
User identification
WebDev, 2018-12-03 10:39:27

Is the authorization correct?

In order not to use anything ready, for, so to speak, development, I decided to do the authorization myself. Site on vuejs (SPA).
1. The user enters a login / password in the form, sends it to the server
2. On the server, I check the correctness of the data and generate a random hash, which I write to the database and send back to the user.
3. On the user side, I accept the hash, add it to the header of all Ajax requests, for example MYPRIVATEHEADER, on the server side, check this header for addresses that require authorization, take its contents and search the database for a user with such a hash.
That's all. Tell me, did I do everything right?
And the next question: How to properly organize logout by the user. For example, I want to forcefully log out a user. To do this, I will delete its hash in the database. But the user in the current situation will not understand anything, because the check for correctness occurs only during authorization, and when accessing other routes, a 403 error will simply be returned if there is no such hash. How to do it right? Start a middleware that checks the hash and return some kind of error, and on the client check the response to absolutely all requests, and, getting such an error, log out the user?
Please help me figure it out, thanks.

Answer the question

In order to leave comments, you need to log in

3 answer(s)
�
âš¡ Kotobotov âš¡, 2018-12-03
@angrySCV

a modern approach, give the user's authorization data encrypted in the form of a token, the decryption key is stored in memory, and nothing is looked up in the database and is not compared with anything, when requested, the token data is decrypted, and it is decided to give access or not based on its token (in the token says what permissions the user has), which allows you to remove the load from the database and unlimitedly scale the functionality across servers, since each server has the same key for decryption, in the case of checking data in a single database, scaling will rest on the performance of this database.

I
Ilya Sitnikov, 2018-12-03
@p_monsta

The hash is correct. You can also put this hash in the cookie so that the authorization is saved when the session is closed. And consistently check when opening the site, first the session variable, then the cookie. If there is no hash in the cookie, then the user is definitely out))
And with forced deauthorization, you can do this. Whether you in an index file check the user is authorized or not. Each time you visit the site, you compare the hash in the browser with the hash of the database. If different then - ask to log in again.

M
Mikhail Osher, 2018-12-03
@miraage

I would return 401 errors for a crooked/deleted/missing token.
You can also write not one token, but several (so that you can log in from different browsers / devices).
When loading an application, I would advise you to send a request to get the current user by token. If 401 is returned, then the user is not authorized. If at the same time the token remains on the client (for example, localStorage), then it must be deleted.
In general, the standard approach.
I would still send authorization not through MYPRIVATEHEADER, but as "Authorization: Bearer 2398mv59023m5v32".

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question