first answer
[ikiwiki.git] / doc / bugs / notifyemail_fails_with_some_openid_providers.mdwn
1 [[!template  id=gitbranch branch=anarcat/dev/openid_email author="[[anarcat]]"]]
2
3 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.
4
5 In the OpenID plugin, the email is actually fetched when authenticating and is stored in the session, like so:
6
7 [[!format perl """
8 sub auth ($$) {
9 # [...]
10                         my @extensions;
11                         if ($vident->can("signed_extension_fields")) {
12                                 @extensions=grep { defined } (
13                                         $vident->signed_extension_fields('http://openid.net/extensions/sreg/1.1'),
14                                         $vident->signed_extension_fields('http://openid.net/srv/ax/1.0'),
15                                 );
16                         }
17                         my $nickname;
18                         foreach my $ext (@extensions) {
19                                 foreach my $field (qw{value.email email}) {
20                                         if (exists $ext->{$field} &&
21                                             defined $ext->{$field} &&
22                                             length $ext->{$field}) {
23                                                 $session->param(email => $ext->{$field});
24                                                 if (! defined $nickname &&
25                                                     $ext->{$field}=~/(.+)@.+/) {
26                                                         $nickname = $1;
27                                                 }
28                                                 last;
29                                         }
30                                 }
31
32 """]]
33
34 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.
35
36 Earlier in the plugin, the email field is actually hidden:
37
38 [[!format perl """
39 sub formbuilder_setup (@) {
40         my %params=@_;
41
42         my $form=$params{form};
43         my $session=$params{session};
44         my $cgi=$params{cgi};
45         
46         if ($form->title eq "preferences" &&
47                IkiWiki::openiduser($session->param("name"))) {
48                 $form->field(name => "openid_identifier", disabled => 1,
49                         label => htmllink("", "", "ikiwiki/OpenID", noimageinline => 1),
50                         value => "", 
51                         size => 1, force => 1,
52                         fieldset => "login",
53                         comment => $session->param("name"));
54                 $form->field(name => "email", type => "hidden");
55         }
56 }
57 """]]
58
59 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.
60
61 The dumbest [[!taglink patch]] that actually fixes the problem for me is in the branch mentionned above.
62
63 It would probably be better to add a comment on the field as indicated above, but it's a good proof of concept.
64
65 Any other ideas? --[[anarcat]]
66
67 > Note: it seems that my email *is* given by my OpenID provider, no idea why this is not working, but the fix proposed in my branch works. --[[anarcat]]
68
69 >> Note: this is one of two patches i need to apply at every upgrade. The other being [[can__39__t_upload_a_simple_png_image:_prohibited_by_allowed__95__attachments___40__file_MIME_type_is_application__47__octet-stream...]]. --[[anarcat]]
70
71 >>> Is there any sort of check that the owner of the given email address
72 >>> wants to receive email from us, or way for the owner of that email
73 >>> address to stop getting the emails?
74 >>>
75 >>> With passwordauth, if someone maliciously subscribes my email
76 >>> address to high-traffic pages or something (by using it as the
77 >>> email address of their wiki login), I can at least use
78 >>> password-recovery to hijack their account and unsubscribe myself.
79 >>> If they're signing in with an OpenID not associated with my
80 >>> email address and then changing the email address in the userdb
81 >>> to point to me, I don't think I can do that.
82 >>>
83 >>> With OpenID, I think we're just trusting that the OpenID provider
84 >>> wouldn't give us an unverified email address, which also seems
85 >>> a little unwise.
86 >>>
87 >>> It might be better to give ikiwiki a concept of verifying an
88 >>> email address (the usual send-magic-token flow) and only be
89 >>> willing to send notifications to a verified address?
90 >>>
91 >>> --[[smcv]]
92 >>>
93 >>>> hmm... true, that is a problem, especially for hostile wikis. but then any hostile site could send you such garbage - they would be spammers then. otherwise, you could ask the site manager to disable that account...
94 >>>>
95 >>>> this doesn't seem to be a very big security issue that would merit implementing a new verification mechanism, especially since we don't verify email addresses on accounts right now. what we could do however is allow password authentication on openid accounts, and allow those users to actually change settings like their email addresses. however, I don't think this should be blocking that functionality right now. --[[anarcat]]