diff --git a/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn new file mode 100644 index 000000000..7c7c016cb --- /dev/null +++ b/doc/bugs/do_not_let_big_brother_spy_on_our_users_on_login.mdwn @@ -0,0 +1,32 @@ +In the login page, the icons of: + + * livejournal.com + * myopenid.com - which is [closing](http://tech.slashdot.org/story/13/09/04/228229/myopenid-to-shut-down-in-february) + * verisign.com + * yahoo.com + * aol.com + * claimid.com + * flickr.com - which should be the same as yahoo + * wordpress.com + * google.com + +... are all hotlinked. Which means that on every ikiwiki out there, whenever someone logs in, the web browser of that person actually report backs to all those entities, some of which are known to collaborate with the US government in illegal spying of american citizens and, well, the world at large (see [[!wikipedia PRISM]], but also the patriot act and various warrantless wiretapping provisions established since 2001). + +In the old days, we used to call those [[!wikipedia web bugs]]. Nowadays, they seem so pervasive that we don't even notice. Nevertheless, I think it would be important to remove those snitches from the ikiwiki home page. + +A simple fix would be to ship those icons with ikiwiki and serve them locally, but there may be legal issues with redistributing those icons in the source code... Would it be covered by fair use? The [upstream library](https://code.google.com/p/openid-selector/) doesn't actually exhibit that problem, and ships those icons directly as a [PNG sprite](https://code.google.com/p/openid-selector/source/browse/#svn%2Ftrunk%2Fimages). -- [[anarcat]] + +> it's not exactly about OpenID, but the german heise newspaper group has +> switched away from directly including like/+1 buttons on their websites, and +> replaced them with locally hosted buttons which have to be clicked once to +> enable the buttons themselves and a second time to effect anything. +> [here's the article](http://www.h-online.com/features/Two-clicks-for-more-privacy-1783256.html). +> they've had [trouble with facebook (german)](http://www.heise.de/newsticker/meldung/Facebook-beschwert-sich-ueber-datenschutzfreundlichen-2-Klick-Button-2-Update-1335658.html) +> -- tl;dt: facebook complained +> about them using their "like"-button logo for something that's not a like +> button, they replaced the whole facebook logo there with a plain-text "F" (as +> you see on the bottom of the page). google's +1 seems not to have been an +> issue. i assume it will need case-by-case decisions to fully comply with all +> legal stuff involved. (from a practical point of view, things are not that +> strict, as `apt-file find facebook.png` and `apt-file find flickr.png` +> reveal.) --[[chrysn]] diff --git a/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn b/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn new file mode 100644 index 000000000..ca3599660 --- /dev/null +++ b/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn @@ -0,0 +1,67 @@ +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. + +In the OpenID plugin, the email is actually fetched when authenticating and is stored in the session, like so: + +[[!format perl """ +sub auth ($$) { +# [...] + my @extensions; + if ($vident->can("signed_extension_fields")) { + @extensions=grep { defined } ( + $vident->signed_extension_fields('http://openid.net/extensions/sreg/1.1'), + $vident->signed_extension_fields('http://openid.net/srv/ax/1.0'), + ); + } + my $nickname; + foreach my $ext (@extensions) { + foreach my $field (qw{value.email email}) { + if (exists $ext->{$field} && + defined $ext->{$field} && + length $ext->{$field}) { + $session->param(email => $ext->{$field}); + if (! defined $nickname && + $ext->{$field}=~/(.+)@.+/) { + $nickname = $1; + } + last; + } + } + +"""]] + +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. + +Earlier in the plugin, the email field is actually hidden: + +[[!format perl """ +sub formbuilder_setup (@) { + my %params=@_; + + my $form=$params{form}; + my $session=$params{session}; + my $cgi=$params{cgi}; + + if ($form->title eq "preferences" && + IkiWiki::openiduser($session->param("name"))) { + $form->field(name => "openid_identifier", disabled => 1, + label => htmllink("", "", "ikiwiki/OpenID", noimageinline => 1), + value => "", + size => 1, force => 1, + fieldset => "login", + comment => $session->param("name")); + $form->field(name => "email", type => "hidden"); + } +} +"""]] + +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. + +[[!template id=gitbranch branch=anarcat/openid_email author="[[anarcat]]"]] + +The dumbest [[!taglink patch]] that actually fixes the problem for me is in the branch mentionned here. + +It would probably be better to add a comment on the field as indicated above, but it's a good proof of concept. + +Any other ideas? --[[anarcat]] + +> 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]] diff --git a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn new file mode 100644 index 000000000..151c023be --- /dev/null +++ b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn @@ -0,0 +1,23 @@ +[[!template id=gitbranch branch=anarcat/syslog_utf8 author="[[anarcat]]"]] + +[[this feature|todo/syslog_should_show_wiki_name]] made it so syslog doesn't work anymore if the site being logged has non-ASCII characters it in. + +Specifically, my wiki was named "CⒶTS", and nothing was showing up in syslog. When I changed that to "C@TS", it worked again. + +My guess is this sits somewhere here: + +[[!format perl """ + return eval { + Sys::Syslog::syslog($type, "[$config{wikiname}] %s", join(" ", @_)); + }; +"""]] + +Yet I am not sure how to fix that kind of problem in Perl... --[[anarcat]] + +> If I remove the "eval" above, I get: +> +> Error: Wide character in syswrite at /usr/lib/perl/5.14/Sys/Syslog.pm line 485. +> +> I have improved a little the error handling in log_message() so that we see *something* when syslog fails, see the branch documented above. I can also confirm that reverting [[todo/syslog_should_show_wiki_name]] fixes the bug. Finally, I have a unit test that reproduces the problem in git, and a working [[!taglink patch]] for the bug, again in git. +> +> > One last note: I noticed that this problem also happens elsewhere in ikiwiki. For example, the [[plugins/notifyemail]] plugin will silently fail to send notifications if the pages contain unicode. The [[plugins/notifychanges]] plugin I am working on (in [[todo/option to send only the diff in notifyemail]]) seems to be working around the issue so far, but there's no telling which similar problem are out there. diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn index 0f4b8b5bf..56a69c943 100644 --- a/doc/news/openid.mdwn +++ b/doc/news/openid.mdwn @@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an OpenID, and see how OpenID works for you. And let me know your feelings about making such a switch. --[[Joey]] -[[!poll 70 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]] +[[!poll 71 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]] diff --git a/doc/spam_fighting.mdwn b/doc/spam_fighting.mdwn index 83b9dbfdf..d0a70316b 100644 --- a/doc/spam_fighting.mdwn +++ b/doc/spam_fighting.mdwn @@ -10,7 +10,8 @@ to the setup branch in git to be able to update the ban list, get in touch with joey with a ssh public key. Once your key is added, you will be able to edit the ikiwiki.setup file on the setup branch, and push changes. You will also be able to access the recent web server logs to find IP -addresses, by running: `ssh b-ikiwiki@ikiwiki.info logdump > access.log` +addresses from recent web edits, by running: `ssh b-ikiwiki@ikiwiki.info +logdump | grep 'GET .*\?updated HTTP\/' > access.log`. ## Spam commits @@ -22,4 +23,5 @@ d1dbd8e | 2013/08/19 | webschen1 | 79.228.8.176 6602052 | 2013/08/21 | webschen1 | 31.17.11.19 d93a948 | 2013/09/05 | soman81 | 31.17.11.19 568fdb0 | 2013/09/05 | soman81 | 31.17.11.19 +d759052 | 2013/09/08 | spain1001 | 80.187.106.2 """]] diff --git a/doc/tips/distributed_wikis.mdwn b/doc/tips/distributed_wikis.mdwn index 75a2368b1..29273ada1 100644 --- a/doc/tips/distributed_wikis.mdwn +++ b/doc/tips/distributed_wikis.mdwn @@ -101,9 +101,9 @@ Note that this will also configure CGI so that people can edit the wiki. Note th #### Apache configuration - ServerName reseaulibre.example.com:80 - DocumentRoot /var/www/reseaulibre.example.com - + ServerName mirror.example.com:80 + DocumentRoot /var/www/mirror.example.com + Options Indexes MultiViews ExecCGI AllowOverride None Order allow,deny @@ -116,9 +116,9 @@ Note that this will also configure CGI so that people can edit the wiki. Note th #### Nginx configuration server { - root /var/www/reseaulibre.example.com/; + root /var/www/mirror.example.com/; index index.html index.htm; - server_name reseaulibre.example.com; + server_name mirror.example.com; location / { try_files $uri $uri/ /index.html; @@ -127,7 +127,7 @@ Note that this will also configure CGI so that people can edit the wiki. Note th fastcgi_pass unix:/tmp/fcgi.socket; fastcgi_index ikiwiki.cgi; fastcgi_param SCRIPT_FILENAME /var/www/ikiwiki.cgi; - fastcgi_param DOCUMENT_ROOT /var/www/reseaulibre.example.com; + fastcgi_param DOCUMENT_ROOT /var/www/mirror.example.com; include /etc/nginx/fastcgi_params; } } diff --git a/doc/todo/option_to_send_only_the_diff_in_notifyemail.mdwn b/doc/todo/option_to_send_only_the_diff_in_notifyemail.mdwn new file mode 100644 index 000000000..b863d361d --- /dev/null +++ b/doc/todo/option_to_send_only_the_diff_in_notifyemail.mdwn @@ -0,0 +1,11 @@ +[[!tag wishlist]] + +[[!template id=gitbranch branch=anarcat/notifychanges author="[[anarcat]]"]] + +It would be nice if [[plugins/notifyemail]] wouldn't send the complete page source, but only the things that changed, when notifying users. They can always follow the link to see the full page if they want. + +For bonus points, make that optional. --[[anarcat]] + +> I am working on a patch, in the branch mentionned above. So far, my first job was to make sure notifyemail sends a single email per refresh. Next step is to try to figure out the revisions to send to the user - I am not sure it's quite obvious in the iki internals which diffs we're working on, because of the pluggable nature of the software (and even the possibility that not RCS exists at all). So far, I am thinking of using `rcs_recentchanges()`, but how many commits to look back into? Feedback welcome. --[[anarcat]] + +> > It turns out it was easier to simply make a completely new plugin for this, which I called "notifychanges" (i don't like that name too much). It is in my notifychanges branch, so i guess we have a [[!taglink patch]] now! --[[anarcat]] diff --git a/doc/todo/send_only_one_mail_per_page_in_notifyemail.mdwn b/doc/todo/send_only_one_mail_per_page_in_notifyemail.mdwn new file mode 100644 index 000000000..5bbee0d52 --- /dev/null +++ b/doc/todo/send_only_one_mail_per_page_in_notifyemail.mdwn @@ -0,0 +1,7 @@ +[[!tag wishlist]] + +[[!template id=gitbranch branch=anarcat/notify_one_email author="[[anarcat]]"]] + +While working on [[todo/option to send only the diff in notifyemail]], I tried to improve the [[plugins/notifyemail]] plugin to make it send only one email per change instead of one email per file changed. When using the wiki through git, this is particularly important if people touch a lot of pages at the same time. + +The [[!taglink patch]], incomplete and buggy, is in my `notify_one_email` branch. --[[anarcat]]