The main thing is the tail! or opt-out 2
The note “ Refusal to register ” stirred my mind and I could not sleep for 2 hours (or was it a cup of coffee at night? ..)
I used to read about “soft” registration, or deferred registration, or “unobtrusive” registration, and then I decided for myself that the output would be OpenID and everything like it. But when working on the current project, I realized that this did not suit me at all.
The decision came just before bedtime, and the implementation was made this morning. I was pleased.
')
But first things first.
I'll start with what OpenID didn’t suit me. It's simple. The target audience of this project’s site is, of course, they are decent people, mostly far from social networks (forest managers) and may either not have the necessary accounts at all, or it will be hard for them to understand what they are wanted to when they are offered to choose a system through which can register. Therefore, you need something simple-simple, but not OpenID.
I think everyone remembers a wonderful Soviet cartoon about an ostrich and neck, who argued that the main thing: legs or wings. Their dispute is reminiscent of attempts to choose between “simplified” registration and “very simplified” registration. So the main thing is not the legs or wings, but the tail, in our case authorization. No matter how simple the registration is, the information that we can authorize the user in the future is important. As a result, the user may not notice that he has already "registered".
Each new session is a new user. If there is an entrance in a day from the same browser and from the same computer, then it is clear that this is the same user, if in a month it is still the same user. So far this is not enough for full authorization, but the first step is the hardest. You can increase the storage time of the session identifier in cookies with the visitor and the session itself on the server. I think even necessary, for greater reliability.
If suddenly the user needed to enter an e-mail somewhere on the site, then: Hurray! - now this user will not be lost. We can allow him to identify himself by offering to enter his email in any browser and from any computer. But before authorization, he will not have access to the history of his interaction with our site.
But when a user wants to authorize himself, we will send a password to his email.
Now we have a registered user, and the loyalty of this user is much higher than that of a user registered under the “standard” scheme.
I offer my version.
I already have a module in the engine that collects visitor statistics. Now it saves the session ID, the user ID (by default, the guest ID) and all the information on the request into one table. We remove the user ID from the statistics table and create a new table with two fields:
In this table we will enter information if:
Thus, statistics is maintained completely independently of the identification and authorization processes, but we have almost all of them, for any user, regardless of how quickly he became registered.
To bind in the future to this scheme OpenID will not be problems.
To implement the mechanism for saving underfilled forms, create the following table:
I think more to make the substitution of the most frequently entered values, but this later.
You can still do such a useful thing. If we have some confidential information of the current user, and we already know his email, then we place in a prominent place a link with the text “The history of your orders (questions, complaints, requests, etc.) you can see by entering your email and passing authorization. So the user will understand that they recognize him and remember him.
So, the registration issue is no longer a problem for me. I hope my solution will be useful in your projects.
PS A beautiful cartoon about the neck, ostrich and lizard can be found here .
UPD:
Standard "explicit" registration is also implemented. Password change and its recovery is.
UPD2:
The scope of the proposed mechanism I see any resource, regardless of its complexity and scale.
I will explain. All user actions of any resource can be divided into three categories:
With authorized users everything is clear. This is a standard situation.
A lot of talk about identified, but not authorized users.
While the user has never entered his email address on the site, he is considered to be only identified and can do any actions of categories 1 and 2 as many times as necessary. He also has access to any action from category 3, but ONLY once. After successfully completing this action, such a user becomes fully registered (sign - the presence of a confirmed email in his profile), and the next time without authorization, he will not be able to perform category 3 actions. for example, mothers). Naturally the user is notified of this in a letter. Naturally, it appears "Exit" button.
UPD3:
I am an identified user without a confirmed email or phone made a category 2 action on the site. During the life of my session, another 100,500 users performed category 2 action (s) on the site.
From the topic it follows that the site will think that one user, namely, I have completed all these 100,501 actions of category 2.
Required amendment. If the user's personal data without a confirmed email or phone (the list of which is chosen in advance for a particular site) has changed dramatically, then this is a new user.
Please note that the list of personal data for each type of category 2 action may be different in principle and on different sites in particular and should be selected separately in each specific case.
For a detailed review of this case, special thanks to Nail13 .
I used to read about “soft” registration, or deferred registration, or “unobtrusive” registration, and then I decided for myself that the output would be OpenID and everything like it. But when working on the current project, I realized that this did not suit me at all.
The decision came just before bedtime, and the implementation was made this morning. I was pleased.
')
But first things first.
I'll start with what OpenID didn’t suit me. It's simple. The target audience of this project’s site is, of course, they are decent people, mostly far from social networks (forest managers) and may either not have the necessary accounts at all, or it will be hard for them to understand what they are wanted to when they are offered to choose a system through which can register. Therefore, you need something simple-simple, but not OpenID.
I think everyone remembers a wonderful Soviet cartoon about an ostrich and neck, who argued that the main thing: legs or wings. Their dispute is reminiscent of attempts to choose between “simplified” registration and “very simplified” registration. So the main thing is not the legs or wings, but the tail, in our case authorization. No matter how simple the registration is, the information that we can authorize the user in the future is important. As a result, the user may not notice that he has already "registered".
Idea formalization
Each new session is a new user. If there is an entrance in a day from the same browser and from the same computer, then it is clear that this is the same user, if in a month it is still the same user. So far this is not enough for full authorization, but the first step is the hardest. You can increase the storage time of the session identifier in cookies with the visitor and the session itself on the server. I think even necessary, for greater reliability.
If suddenly the user needed to enter an e-mail somewhere on the site, then: Hurray! - now this user will not be lost. We can allow him to identify himself by offering to enter his email in any browser and from any computer. But before authorization, he will not have access to the history of his interaction with our site.
But when a user wants to authorize himself, we will send a password to his email.
Now we have a registered user, and the loyalty of this user is much higher than that of a user registered under the “standard” scheme.
Implementation of the idea
I offer my version.
I already have a module in the engine that collects visitor statistics. Now it saves the session ID, the user ID (by default, the guest ID) and all the information on the request into one table. We remove the user ID from the statistics table and create a new table with two fields:
- Session ID;
- User ID.
In this table we will enter information if:
- Create a new user;
- We update all lines with the current unnamed user after identifying or authorizing the current user.
Thus, statistics is maintained completely independently of the identification and authorization processes, but we have almost all of them, for any user, regardless of how quickly he became registered.
To bind in the future to this scheme OpenID will not be problems.
To implement the mechanism for saving underfilled forms, create the following table:
- Session ID;
- ID of the form view;
- The last serialized post request associated with the form.
I think more to make the substitution of the most frequently entered values, but this later.
You can still do such a useful thing. If we have some confidential information of the current user, and we already know his email, then we place in a prominent place a link with the text “The history of your orders (questions, complaints, requests, etc.) you can see by entering your email and passing authorization. So the user will understand that they recognize him and remember him.
Conclusion
So, the registration issue is no longer a problem for me. I hope my solution will be useful in your projects.
PS A beautiful cartoon about the neck, ostrich and lizard can be found here .
UPD:
Standard "explicit" registration is also implemented. Password change and its recovery is.
UPD2:
The scope of the proposed mechanism I see any resource, regardless of its complexity and scale.
I will explain. All user actions of any resource can be divided into three categories:
- It does not matter who does, a person or a robot (go through the pages and, perhaps, something else).
- Protection in this case is not needed.
- The action is available to anyone coming to the site.
- It is important that this is done by a person (comment on a regular site and another such simple action).
- Protection - the usual captcha.
- The action is available to any identified user, i.e. in our case, anyone who visits the site, even the robot, if he can handle the captcha.
- It is important that the person does this and that he takes responsibility for this action (order, post, comment on some serious resource).
- Protection - confirmation by email.
- Available to the identified user without a confirmed email (it is clear that he can do it only once) and to any authorized user.
With authorized users everything is clear. This is a standard situation.
A lot of talk about identified, but not authorized users.
While the user has never entered his email address on the site, he is considered to be only identified and can do any actions of categories 1 and 2 as many times as necessary. He also has access to any action from category 3, but ONLY once. After successfully completing this action, such a user becomes fully registered (sign - the presence of a confirmed email in his profile), and the next time without authorization, he will not be able to perform category 3 actions. for example, mothers). Naturally the user is notified of this in a letter. Naturally, it appears "Exit" button.
UPD3:
Problem situation and its solution
I am an identified user without a confirmed email or phone made a category 2 action on the site. During the life of my session, another 100,500 users performed category 2 action (s) on the site.
From the topic it follows that the site will think that one user, namely, I have completed all these 100,501 actions of category 2.
Required amendment. If the user's personal data without a confirmed email or phone (the list of which is chosen in advance for a particular site) has changed dramatically, then this is a new user.
Please note that the list of personal data for each type of category 2 action may be different in principle and on different sites in particular and should be selected separately in each specific case.
For a detailed review of this case, special thanks to Nail13 .
Source: https://habr.com/ru/post/122174/
All Articles