doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn

   1 This bug affects [[plugins/notifyemail]] but is probably caused more by [[plugins/openid]]. When using OpenID to login to a site, no email notification is sent to the user (pagespec set to `*`) when a modification is done on the wiki. I believe this is because the OpenID plugin assumes the email comes from the OpenID provider - which is not necessarily going to succeed if, for privacy reason, the OpenID provider refuses to transmit the email to ikiwiki.
   2
   3 In the OpenID plugin, the email is actually fetched when authenticating and is stored in the session, like so:
   4
   5 [[!format perl """
   6 sub auth ($$) {
   7 # [...]
   8                         my @extensions;
   9                         if ($vident->can("signed_extension_fields")) {
  10                                 @extensions=grep { defined } (
  11                                         $vident->signed_extension_fields('http://openid.net/extensions/sreg/1.1'),
  12                                         $vident->signed_extension_fields('http://openid.net/srv/ax/1.0'),
  13                                 );
  14                         }
  15                         my $nickname;
  16                         foreach my $ext (@extensions) {
  17                                 foreach my $field (qw{value.email email}) {
  18                                         if (exists $ext->{$field} &&
  19                                             defined $ext->{$field} &&
  20                                             length $ext->{$field}) {
  21                                                 $session->param(email => $ext->{$field});
  22                                                 if (! defined $nickname &&
  23                                                     $ext->{$field}=~/(.+)@.+/) {
  24                                                         $nickname = $1;
  25                                                 }
  26                                                 last;
  27                                         }
  28                                 }
  29
  30 """]]
  31
  32 This is based on the assumption that the openid provider supports "sreg" or "ax" extensions, which is not mandatory, and even then, the provider is not forced to provide the email.
  33
  34 Earlier in the plugin, the email field is actually hidden:
  35
  36 [[!format perl """
  37 sub formbuilder_setup (@) {
  38         my %params=@_;
  39
  40         my $form=$params{form};
  41         my $session=$params{session};
  42         my $cgi=$params{cgi};
  43
  44         if ($form->title eq "preferences" &&
  45                IkiWiki::openiduser($session->param("name"))) {
  46                 $form->field(name => "openid_identifier", disabled => 1,
  47                         label => htmllink("", "", "ikiwiki/OpenID", noimageinline => 1),
  48                         value => "",
  49                         size => 1, force => 1,
  50                         fieldset => "login",
  51                         comment => $session->param("name"));
  52                 $form->field(name => "email", type => "hidden");
  53         }
  54 }
  55 """]]
  56
  57 I believe this could be worked around simply by re-enabling that field and allowing the user to specify an email there by hand, making a note that the OpenID provider's email is used by default.
  58
  59 Here's the dumbest [[!taglink patch]] that actually fixes the problem for me:
  60
  61 [[!format diff """
  62 diff --git a/IkiWiki/Plugin/openid.pm b/IkiWiki/Plugin/openid.pm
  63 index e3b9982..df87ba3 100644
  64 --- a/IkiWiki/Plugin/openid.pm
  65 +++ b/IkiWiki/Plugin/openid.pm
  66 @@ -104,7 +104,6 @@ sub formbuilder_setup (@) {
  67                         size => 1, force => 1,
  68                         fieldset => "login",
  69                         comment => $session->param("name"));
  70 -               $form->field(name => "email", type => "hidden");
  71         }
  72  }
  73
  74 """]]
  75
  76 It would probably be better to add a comment on the field as indicated above, but it's a good proof of concept.
  77
  78 Any other ideas?