OpenID with a human face in Drupal
Starting with version 6 of Drupal, the OpenID module comes with the system, which provides authorization via the OpenID protocol. But the module has quite serious problems. In particular, the module itself implements the anti-pattern described by Ivan Sagalaev in his blog . The second problem of the module, from the point of view of usability, is non-transparent authorization by OpenID, and to be more precise, when you first try to authorize through a certain OpenID account, the system asks you to fill in a certain number of fields.
In general, I personally don’t see anything terribly terrible in filling in a small number of fields (especially in some cases, some of the fields are filled automatically, but more on that below) - the reason for this is the Drupal architecture. OpenID accounts are tied to real Drupal accounts, i.e. upon successful authorization with the OpenID provider, Drupal tries to find a match between the OpenID account and the Drupal account. If such a match is not found - the system offers to register a new account, for which you need to fill in a certain number of required fields - in general, this is a unique username in the system and an email address. If a match is found, the user is authorized. In the profile, the user can add any number of OpenID accounts that will be associated with his Drupal account.
')
With the principle of OpenID in Drupal, everything is more or less clear. But the questions to usability have not gone away - a reference at the bottom of the authorization block can not be called a very convenient solution. In a post on Ivan's blog, about which I wrote above, one of the possible prototypes for solving this problem was presented, and I started to implement it for Drupal.
How and what was written - I think in this case it does not really matter - in the end everything is distributed in the form of source codes. Let's go directly to the point - what happened =)
And it turned out a system that allows using a certain set of APIs to connect friendly (as far as I did) support for certain OpenID providers, plus added an additional feature in the form of plug-in themes for the block.
A little more about everything, and with pictures =)
I think that it’s not necessary to tell about how modules are installed in Drupal, and if necessary, I advise you to familiarize yourself with my previous article , where I described the basics of working with this system. Therefore, simply download the OpenID Extenisions module and install it (note that it depends on the OpenID module). Now you can do it setting.
Go to User management -> OpenID Extensions and get into the settings of OpenID providers.
In the settings (the operation of which I copied from the Blocks module =)), you can connect / disconnect the available providers, as well as set the order for them. The latter is convenient in the case when you know that the majority of OpenID authorizations on your resource goes, for example, from LiveJournal - then put LJ in the first place and it will be selected by default when loading pages on which the block is displayed. Also there you can find the Themes tab, by going to which you will see a list of available topics. Themes define the appearance of the OpenID authorization form. In the basic package (and the other one at the time of writing this blog post does not exist =)) there are 2 topics:
By selecting a design theme you like and configuring OpenID providers, you can go to the block settings ( Site building -> Blocks ), add the block called OpenID Extensions to the desired region, set its position and, if necessary, set the block display filter on the pages. There is no point in setting up a visibility filter by roles - in any case, the block is visible only to unauthorized users.
After successful authorization with the OpenID provider, the first time you try to log in, as I wrote above, Drupal redirects the user to the registration page, where he tries to fill in the form fields with the values ​​received from the provider. If the OpenID provider implements SRE (Simple Registration Extension) and the required fields in your profile are filled, then these fields on the registration form are filled in automatically. For example, in my account on Yandex, all the necessary information is filled in - when I try to authorize, Yandex asked if I would like to allow authorization for the example.com resource and whether I allow it to transfer 2 fields to this resource - Nickname and Email. If the registration procedure is completed successfully in automatic mode (i.e., all the necessary data is received and they successfully pass validation), then a Drupal account is created for the user, to which the OpenID identifier is automatically linked and the user is automatically logged in.
If the required data is not filled in, or the provider does not provide such data (for example, Google, which does not implement SRE, but only AX, which is not supported by the OpenID module in Druapal), the system will give an error and ask you to enter the missing fields manually. Also, if the OpenID provider does not provide a Nickname, then the User Name field is filled with the OpenID identifier value. To solve this problem, the module provides a small workaround, but it works only for certain providers - in the base package only with LiveJournal and Yandex. In general, I managed to get the email address from Google patching the OpenID module, so in the future I think I’m going to expand the functionality of the module a bit, and for some providers I’ll write my own handlers that will replace the standard ones. I also had plans to have a hand in the OpenID module, which is part of Drupal 7, which recently entered into the freezing mode of the functional. In the meantime, it works the way it works.
It should also be noted that the OpenID Extensions module “cleans up” some moments behind the OpenID module, namely, it removes links from login forms (in the block and on a separate page) that switch these forms to the OpenID authorization mode - the behavior of the standard module is repeated by the provider Any OpenID , which is enabled by default when the module is installed.
Here, in general, is all that I was going to tell you about improving usability of OpenID authorization in Drupal. The module so far can only be downloaded from my website in the Projects section. After the module is cleaned up a bit, it will be uncontrollable (I can’t think up a Russian equivalent of this word) on drupal.org , which I ’ll report further.
And finally, a small intrigue - this module was originally developed for the project, which should see the light in the near future. Announcement of the project will necessarily be published =)
Now everything is exactly =) Waiting for feedback / bugreports / suggestions / suggestions.
Threat There are currently some problems with the display of the design of the Accordion in some Drupal topics. In particular, the design does not quite work correctly with the theme of LightWord .
UPD: Currently, the module is in the stage of code review at drupal.org .
UPD2: For those who get an error when trying to log in with Google - Google uses https, so PHP should be compiled with OpenSSL support (in Ubunt, just put the openssl package, if I'm not mistaken).
UPD3: updated to version 0.6.5, in it:
- added new provider 'Chi.mp'
- added the ability to check the availability of the provider
- implemented a check for google and chi.mp - now both are not available if there is no openssl support, which will be notified in the administration of providers.
In general, I personally don’t see anything terribly terrible in filling in a small number of fields (especially in some cases, some of the fields are filled automatically, but more on that below) - the reason for this is the Drupal architecture. OpenID accounts are tied to real Drupal accounts, i.e. upon successful authorization with the OpenID provider, Drupal tries to find a match between the OpenID account and the Drupal account. If such a match is not found - the system offers to register a new account, for which you need to fill in a certain number of required fields - in general, this is a unique username in the system and an email address. If a match is found, the user is authorized. In the profile, the user can add any number of OpenID accounts that will be associated with his Drupal account.
')
With the principle of OpenID in Drupal, everything is more or less clear. But the questions to usability have not gone away - a reference at the bottom of the authorization block can not be called a very convenient solution. In a post on Ivan's blog, about which I wrote above, one of the possible prototypes for solving this problem was presented, and I started to implement it for Drupal.
How and what was written - I think in this case it does not really matter - in the end everything is distributed in the form of source codes. Let's go directly to the point - what happened =)
And it turned out a system that allows using a certain set of APIs to connect friendly (as far as I did) support for certain OpenID providers, plus added an additional feature in the form of plug-in themes for the block.
A little more about everything, and with pictures =)
I think that it’s not necessary to tell about how modules are installed in Drupal, and if necessary, I advise you to familiarize yourself with my previous article , where I described the basics of working with this system. Therefore, simply download the OpenID Extenisions module and install it (note that it depends on the OpenID module). Now you can do it setting.
Go to User management -> OpenID Extensions and get into the settings of OpenID providers.
In the settings (the operation of which I copied from the Blocks module =)), you can connect / disconnect the available providers, as well as set the order for them. The latter is convenient in the case when you know that the majority of OpenID authorizations on your resource goes, for example, from LiveJournal - then put LJ in the first place and it will be selected by default when loading pages on which the block is displayed. Also there you can find the Themes tab, by going to which you will see a list of available topics. Themes define the appearance of the OpenID authorization form. In the basic package (and the other one at the time of writing this blog post does not exist =)) there are 2 topics:
- Dropdown - demo
- Accordion - Demonstration
By selecting a design theme you like and configuring OpenID providers, you can go to the block settings ( Site building -> Blocks ), add the block called OpenID Extensions to the desired region, set its position and, if necessary, set the block display filter on the pages. There is no point in setting up a visibility filter by roles - in any case, the block is visible only to unauthorized users.
After successful authorization with the OpenID provider, the first time you try to log in, as I wrote above, Drupal redirects the user to the registration page, where he tries to fill in the form fields with the values ​​received from the provider. If the OpenID provider implements SRE (Simple Registration Extension) and the required fields in your profile are filled, then these fields on the registration form are filled in automatically. For example, in my account on Yandex, all the necessary information is filled in - when I try to authorize, Yandex asked if I would like to allow authorization for the example.com resource and whether I allow it to transfer 2 fields to this resource - Nickname and Email. If the registration procedure is completed successfully in automatic mode (i.e., all the necessary data is received and they successfully pass validation), then a Drupal account is created for the user, to which the OpenID identifier is automatically linked and the user is automatically logged in.
If the required data is not filled in, or the provider does not provide such data (for example, Google, which does not implement SRE, but only AX, which is not supported by the OpenID module in Druapal), the system will give an error and ask you to enter the missing fields manually. Also, if the OpenID provider does not provide a Nickname, then the User Name field is filled with the OpenID identifier value. To solve this problem, the module provides a small workaround, but it works only for certain providers - in the base package only with LiveJournal and Yandex. In general, I managed to get the email address from Google patching the OpenID module, so in the future I think I’m going to expand the functionality of the module a bit, and for some providers I’ll write my own handlers that will replace the standard ones. I also had plans to have a hand in the OpenID module, which is part of Drupal 7, which recently entered into the freezing mode of the functional. In the meantime, it works the way it works.
It should also be noted that the OpenID Extensions module “cleans up” some moments behind the OpenID module, namely, it removes links from login forms (in the block and on a separate page) that switch these forms to the OpenID authorization mode - the behavior of the standard module is repeated by the provider Any OpenID , which is enabled by default when the module is installed.
Here, in general, is all that I was going to tell you about improving usability of OpenID authorization in Drupal. The module so far can only be downloaded from my website in the Projects section. After the module is cleaned up a bit, it will be uncontrollable (I can’t think up a Russian equivalent of this word) on drupal.org , which I ’ll report further.
And finally, a small intrigue - this module was originally developed for the project, which should see the light in the near future. Announcement of the project will necessarily be published =)
Now everything is exactly =) Waiting for feedback / bugreports / suggestions / suggestions.
Threat There are currently some problems with the display of the design of the Accordion in some Drupal topics. In particular, the design does not quite work correctly with the theme of LightWord .
UPD: Currently, the module is in the stage of code review at drupal.org .
UPD2: For those who get an error when trying to log in with Google - Google uses https, so PHP should be compiled with OpenSSL support (in Ubunt, just put the openssl package, if I'm not mistaken).
UPD3: updated to version 0.6.5, in it:
- added new provider 'Chi.mp'
- added the ability to check the availability of the provider
- implemented a check for google and chi.mp - now both are not available if there is no openssl support, which will be notified in the administration of providers.
Source: https://habr.com/ru/post/74416/
All Articles