June 19, 2011 at 10:27The main thing is the tail! or opt-out 2
The note “ Refusal to register ” stirred my mind and I couldn’t fall asleep for 2 hours (or was it a cup of coffee at night? ..)
I had read about “soft” registration, or delayed registration, or “unobtrusive” registration, and then I I decided for myself that the solution would be OpenID and everything that looks 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 made the implementation this morning. I was satisfied.
But first things first.
To begin with, what OpenID did not suit me with. Everything is simple. The target audience of the site of this project, all of them, of course, are decent people, mostly far from social networks (forestry managers) and may either not have the necessary accounts at all, or it will be difficult for them to understand what they want from them when they offer to choose a system through which You 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 was legs or wings. Their argument is reminiscent of trying to choose between a “simplified” registration and a “completely simplified” one. So the main thing is not legs or wings, but the tail, in our case, authorization. It does not matter how simple the registration is, the data 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 you log in 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 too little for full authorization, but the dashing trouble has begun. You can increase the storage time of the session identifier in cookies by the visitor and the session itself on the server. I think it’s even necessary for greater reliability.
If suddenly the user needed to enter an email 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 address in any browser and from any computer. But prior to authorization, the history of his interaction with our site will not be available to him.
But when the user wanted to authorize himself, we send a password to his email.
Now we have a user registered according to all the rules, and the loyalty of this user is IMHO significantly higher than that of a user registered according to the “standard” scheme.
I offer my version.
I already have a module in the engine that collects statistics on visits. Now it saves in a single table the session identifier, user identifier (by default, this is the guest identifier) and all information on request. We remove the user ID from the statistics table and create a new table with two fields:
We will enter information into this table if:
Thus, statistics are kept completely independent of the identification and authorization processes, but we have almost all of them for any user, regardless of how quickly he became registered.
There are no problems linking OpenID to this scheme in the future.
To implement the mechanism for saving unfilled forms, create the following table:
I’m also thinking of substituting the most frequently entered values, but this is 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 “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 about him.
So, the registration issue for me is no longer a problem. I hope my solution is useful in your projects.
PS A wonderful cartoon about the neck, ostrich and lizard can be seen here .
UPD:
The standard "explicit" registration is also implemented. Password change and password recovery is.
UPD2: I
see any resource in the scope of the proposed mechanism, 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 only identified and can do any actions of categories 1 and 2 as many times as necessary. Also, he can access any action from category 3, but ONLY once. After the successful completion of this action, such a user becomes fully registered (the sign is the presence of a confirmed email in his profile), and the next time he will not be able to perform category 3 actions without authorization. Now the user must ensure that his account does not fall into the wrong hands ( e.g. moms). Naturally, the user is notified of this in the letter. Naturally, he has a button “Exit”.
UPD3:
I, an authenticated user, without a verified email or phone, performed 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 there is one user, namely I committed all these 100501 category 2 actions.
Amendment required. If the user's personal data without a confirmed email or phone (the list of which is selected 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 can be different in principle and on different sites in particular, and must be selected separately in each case.
For a detailed discussion of this case, special thanks to Nail13 .
I had read about “soft” registration, or delayed registration, or “unobtrusive” registration, and then I I decided for myself that the solution would be OpenID and everything that looks 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 made the implementation this morning. I was satisfied.
But first things first.
To begin with, what OpenID did not suit me with. Everything is simple. The target audience of the site of this project, all of them, of course, are decent people, mostly far from social networks (forestry managers) and may either not have the necessary accounts at all, or it will be difficult for them to understand what they want from them when they offer to choose a system through which You 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 was legs or wings. Their argument is reminiscent of trying to choose between a “simplified” registration and a “completely simplified” one. So the main thing is not legs or wings, but the tail, in our case, authorization. It does not matter how simple the registration is, the data that we can authorize the user in the future is important. As a result, the user may not notice that he has already "registered".
Formalization of ideas
Each new session is a new user. If you log in 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 too little for full authorization, but the dashing trouble has begun. You can increase the storage time of the session identifier in cookies by the visitor and the session itself on the server. I think it’s even necessary for greater reliability.
If suddenly the user needed to enter an email 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 address in any browser and from any computer. But prior to authorization, the history of his interaction with our site will not be available to him.
But when the user wanted to authorize himself, we send a password to his email.
Now we have a user registered according to all the rules, and the loyalty of this user is IMHO significantly higher than that of a user registered according to the “standard” scheme.
Implementation of the idea
I offer my version.
I already have a module in the engine that collects statistics on visits. Now it saves in a single table the session identifier, user identifier (by default, this is the guest identifier) and all information on request. We remove the user ID from the statistics table and create a new table with two fields:
- Session identifier;
- User ID.
We will enter information into this table if:
- Create a new user;
- We update all lines with the current nameless user after identification or authorization of the current user.
Thus, statistics are kept completely independent of the identification and authorization processes, but we have almost all of them for any user, regardless of how quickly he became registered.
There are no problems linking OpenID to this scheme in the future.
To implement the mechanism for saving unfilled forms, create the following table:
- Session identifier;
- Identifier of the form type;
- Last serialized post request related to the form.
I’m also thinking of substituting the most frequently entered values, but this is 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 “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 about him.
Conclusion
So, the registration issue for me is no longer a problem. I hope my solution is useful in your projects.
PS A wonderful cartoon about the neck, ostrich and lizard can be seen here .
UPD:
The standard "explicit" registration is also implemented. Password change and password recovery is.
UPD2: I
see any resource in the scope of the proposed mechanism, regardless of its complexity and scale.
I will explain. All user actions of any resource can be divided into three categories:
- It doesn’t matter who does it, a person or a robot (going through the pages and, possibly, something else).
- Protection in this case is not needed.
- The action is available to anyone who visits the site.
- It is important that this is done by a person (a comment on a regular site and another such simple action).
- Protection is a common captcha.
- The action is available to any authenticated user, i.e. in our case, anyone who visits the site, even a robot, if he can handle the captcha.
- It is important that this is done by a person and that he assumes responsibility for this action (order, post, comment on some serious resource).
- Protection - confirmation by email.
- It is accessible to an authenticated user without a verified email (it is clear that he can do this 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 only identified and can do any actions of categories 1 and 2 as many times as necessary. Also, he can access any action from category 3, but ONLY once. After the successful completion of this action, such a user becomes fully registered (the sign is the presence of a confirmed email in his profile), and the next time he will not be able to perform category 3 actions without authorization. Now the user must ensure that his account does not fall into the wrong hands ( e.g. moms). Naturally, the user is notified of this in the letter. Naturally, he has a button “Exit”.
UPD3:
The problem situation and its solution
I, an authenticated user, without a verified email or phone, performed 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 there is one user, namely I committed all these 100501 category 2 actions.
Amendment required. If the user's personal data without a confirmed email or phone (the list of which is selected 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 can be different in principle and on different sites in particular, and must be selected separately in each case.
For a detailed discussion of this case, special thanks to Nail13 .