November 6, 2009 at 00:22OpenID with a human face in Drupal
Starting with version 6 of Drupal, the OpenID module comes with the system, which provides authorization through the OpenID protocol. But the module has quite serious problems. In particular, the module itself implements the antipattern described by Ivan Sagalaev in his blog . The second problem of the module, from the point of view of usability, is opaque OpenID authorization, and to be more precise, the first time you try to authorize through an OpenID account, the system asks you to fill in a number of fields.
In general, I personally don’t see anything terrible about filling out a small number of fields (especially since in some cases some of the fields are filled in 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 the correspondence of the OpenID account to the Drupal account. If such a match is not found - the system offers to register a new account, for which it is necessary to fill in a number of required fields - in general, this is a unique username in the system and email address. If a match is found, the user logs in. 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 questions about usability have not gone away - the link at the bottom of the authorization block cannot 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, which I took up with 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 we got a system that allows using a certain set of APIs to connect friendly (as far as I can get it) support for certain OpenID providers, plus I added an additional feature in the form of plug-in block design themes.
A little more detailed about everything, and with pictures =)
I think that you don’t need to talk about how the modules are installed in Drupal, but if necessary, I advise you to read my previous article , where I described the basics of working with this system. So just download the OpenID Extenisions module and install it (note that it depends on the OpenID module). Now you can set it up.
Go to User management -> OpenID Extensions and get into the settings of OpenID providers. In the settings (the functioning of which I copied from the Blocks module
=)) you can connect / disconnect available providers, as well as set them the sequence. The latter is convenient in the case when you know that most OpenID authorizations on your resource come, 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. You can also find the Themes tab there , by going to which you will see a list of available topics. Themes determine the appearance of the OpenID authorization form. In the basic delivery (and the other one at the time of writing this blog post does not exist =)) there are 2 topics:
After choosing your favorite theme and setting up OpenID providers, you can go to the block settings ( Site building -> Blocks ), add a block called OpenID Extensions to the desired region, set its position and, if necessary, configure the block display filter on pages. There is no sense 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 I 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 necessary fields in your profile are filled, then these fields on the registration form are filled in automatically. For example, in my Yandex account, all the necessary information is filled in - when I try to log in, Yandex asked if I want to allow authorization for the example.com resource and if I allow 2 fields to be transferred to this resource - Alias and Email. If the registration procedure completes successfully in automatic mode (i.e. all the necessary data is received and they pass validation), then a Drupal account is created for the user,
If the required data is not filled out, 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 generate an error and ask you to enter the missing fields manually. Also, if the OpenID provider does not provide an Alias, then the "Username" field is filled with the value of the OpenID identifier. To solve this problem, the module provides a small workaround, but it works only for certain providers - in the basic distribution only with LiveJournal and Yandex. In general, patching the OpenID moduleI managed to get the email address from Google, so in the future I’m thinking of expanding the module’s functionality a bit, and for some providers I’ll write my own handlers that will have to replace the standard ones. It was also in the plans to have a hand in the OpenID module , which is part of Drupal 7, which recently entered the functional freeze mode. In the meantime, it works the way it works.
It should also be noted that the OpenID Extensions module “cleans up” some points behind the OpenID module , namely it removes links from login forms (in the block and on a separate page) that switch these forms to OpenID authorization mode - the provider repeats the behavior of the standard module Any openid, which is enabled by default when installing the module.
That's just that, and all that I was going to tell you about improving the usability of OpenID authorization in Drupal. The module so far can only be downloaded on my website in the Projects section . After the module is cleaned up a bit, it will be counter-paid (I can’t think of a Russian analogue of this word) on drupal.org , which I will inform about additionally.
And finally, a little intrigue - this module was originally developed for the project, which should see the light in the near future. The announcement of the project will certainly be published =)
Now for sure everything =) I look forward to comments / bugreports / suggestions / wishes in comments.
Threat There are currently some problems with the display of the appearance of Accordion in some Drupal themes. In particular, the design does not work correctly with the LightWord theme .
UPD: The module is currently undergoing the code review phase at drupal.org .
UPD2: For those who get an error when trying to log in with Google, Google uses https, so PHP must be built with OpenSSL support (in the ubunt it is enough to install the openssl package, if I'm not mistaken).
UPD3: updated to version 0.6.5, in it:
- added a new provider 'Chi.mp'
- added the ability to check provider availability
- implemented a check for google and chi.mp - now both of them 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 terrible about filling out a small number of fields (especially since in some cases some of the fields are filled in 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 the correspondence of the OpenID account to the Drupal account. If such a match is not found - the system offers to register a new account, for which it is necessary to fill in a number of required fields - in general, this is a unique username in the system and email address. If a match is found, the user logs in. 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 questions about usability have not gone away - the link at the bottom of the authorization block cannot 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, which I took up with 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 we got a system that allows using a certain set of APIs to connect friendly (as far as I can get it) support for certain OpenID providers, plus I added an additional feature in the form of plug-in block design themes.
A little more detailed about everything, and with pictures =)
I think that you don’t need to talk about how the modules are installed in Drupal, but if necessary, I advise you to read my previous article , where I described the basics of working with this system. So just download the OpenID Extenisions module and install it (note that it depends on the OpenID module). Now you can set it up.
Go to User management -> OpenID Extensions and get into the settings of OpenID providers. In the settings (the functioning of which I copied from the Blocks module
=)) you can connect / disconnect available providers, as well as set them the sequence. The latter is convenient in the case when you know that most OpenID authorizations on your resource come, 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. You can also find the Themes tab there , by going to which you will see a list of available topics. Themes determine the appearance of the OpenID authorization form. In the basic delivery (and the other one at the time of writing this blog post does not exist =)) there are 2 topics:
- Dropdown - demonstration
- The Accordion - demonstration
After choosing your favorite theme and setting up OpenID providers, you can go to the block settings ( Site building -> Blocks ), add a block called OpenID Extensions to the desired region, set its position and, if necessary, configure the block display filter on pages. There is no sense 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 I 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 necessary fields in your profile are filled, then these fields on the registration form are filled in automatically. For example, in my Yandex account, all the necessary information is filled in - when I try to log in, Yandex asked if I want to allow authorization for the example.com resource and if I allow 2 fields to be transferred to this resource - Alias and Email. If the registration procedure completes successfully in automatic mode (i.e. all the necessary data is received and they pass validation), then a Drupal account is created for the user,
If the required data is not filled out, 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 generate an error and ask you to enter the missing fields manually. Also, if the OpenID provider does not provide an Alias, then the "Username" field is filled with the value of the OpenID identifier. To solve this problem, the module provides a small workaround, but it works only for certain providers - in the basic distribution only with LiveJournal and Yandex. In general, patching the OpenID moduleI managed to get the email address from Google, so in the future I’m thinking of expanding the module’s functionality a bit, and for some providers I’ll write my own handlers that will have to replace the standard ones. It was also in the plans to have a hand in the OpenID module , which is part of Drupal 7, which recently entered the functional freeze mode. In the meantime, it works the way it works.
It should also be noted that the OpenID Extensions module “cleans up” some points behind the OpenID module , namely it removes links from login forms (in the block and on a separate page) that switch these forms to OpenID authorization mode - the provider repeats the behavior of the standard module Any openid, which is enabled by default when installing the module.
That's just that, and all that I was going to tell you about improving the usability of OpenID authorization in Drupal. The module so far can only be downloaded on my website in the Projects section . After the module is cleaned up a bit, it will be counter-paid (I can’t think of a Russian analogue of this word) on drupal.org , which I will inform about additionally.
And finally, a little intrigue - this module was originally developed for the project, which should see the light in the near future. The announcement of the project will certainly be published =)
Now for sure everything =) I look forward to comments / bugreports / suggestions / wishes in comments.
Threat There are currently some problems with the display of the appearance of Accordion in some Drupal themes. In particular, the design does not work correctly with the LightWord theme .
UPD: The module is currently undergoing the code review phase at drupal.org .
UPD2: For those who get an error when trying to log in with Google, Google uses https, so PHP must be built with OpenSSL support (in the ubunt it is enough to install the openssl package, if I'm not mistaken).
UPD3: updated to version 0.6.5, in it:
- added a new provider 'Chi.mp'
- added the ability to check provider availability
- implemented a check for google and chi.mp - now both of them are not available if there is no openssl support, which will be notified in the administration of providers.