summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/SVG_files_not_recognized_as_images.mdwn29
-rw-r--r--doc/bugs/cannot_preview_shortcuts.mdwn17
-rw-r--r--doc/bugs/disabling_backlinks.mdwn2
-rw-r--r--doc/bugs/http_proxy_for_openid.mdwn34
-rw-r--r--doc/bugs/rst_tweak.mdwn14
-rw-r--r--doc/bugs/ssl_certificates_not_checked_with_openid.mdwn19
-rw-r--r--doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn4
7 files changed, 117 insertions, 2 deletions
diff --git a/doc/bugs/SVG_files_not_recognized_as_images.mdwn b/doc/bugs/SVG_files_not_recognized_as_images.mdwn
new file mode 100644
index 000000000..207edd426
--- /dev/null
+++ b/doc/bugs/SVG_files_not_recognized_as_images.mdwn
@@ -0,0 +1,29 @@
+In ikiwiki 2.66, SVG images are not recognized as images. In ikiwiki.pm,
+the hardcoded list of image file extensions does not include ".svg", which
+it probably should unless there's some other issue about rendering SVGs?
+
+The 'img' plugin also seems to not support SVGs.
+
+> SVG images can only be included via an `<object>`, `<embed>`, or
+> `<iframe>` tag. Or, perhaps as [inline SVG](http://wiki.svg.org/Inline_SVG).
+> The [[plugins/htmlscrubber]] strips all three tags since they can easily
+> be used maliciously. If doing inline SVG, I'd worry that the svg file
+> could be malformed and mess up the html, or even inject javascript. So,
+> the only options seem to be only supporting svgs on wikis that do not
+> sanitize their html, or assuming that svgs are trusted content and
+> embedding them inline. None of which seem particularly palatable.
+>
+> I suppose the other option would be converting the svg file to a static
+> image (png). The img plugin could probably do that fairly simply.
+> --[[Joey]]
+
+>> I'm working on inline SVG and MathML support in ikiwiki and I've
+>> modified my htmlscrubber to sanitize SVG and MathML using the
+>> whitelists from html5lib. Here's a [patch][]. I've also made some
+>> notes about this here: [[todo/svg]].
+>>
+>> I suspect that this bug may have caught the eye of anyone interested
+>> in this sort of thing. I'll elaborate a bit on my user page to avoid
+>> getting off-topic here. --[[JasonBlevins]], October 21, 2008
+
+ [patch]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
diff --git a/doc/bugs/cannot_preview_shortcuts.mdwn b/doc/bugs/cannot_preview_shortcuts.mdwn
new file mode 100644
index 000000000..d7045b2dc
--- /dev/null
+++ b/doc/bugs/cannot_preview_shortcuts.mdwn
@@ -0,0 +1,17 @@
+Shortcuts such as \[[!google foo]] do not work when previewing pages.
+--[[JasonBlevins]]
+
+> Broken during the setup dumping changes, now fixed. --[[Joey]] [[done]]
+
+>> Just a quick note that this fix interacts with the way the `listdirectives`
+>> directive gets its list of non-shortcut directives. At the moment it
+>> still works, but it relies on the fact that the `listdirectives` `checkconfig`
+>> hook is called before the `shortcut` `checkconfig` hook.
+>> -- [[Will]]
+
+>> The order plugins are loaded is effectively random. (`keys %hooks`).
+>> So I've made shortcuts pass a 'shortcut' parameter when registering
+>> them, which listdirectives can grep out of the full list of directives.
+>> That may not be the best name to give it, especially if other plugins
+>> generate directives too. Seemed better than forcing shortcut's
+>> checkconfig hook to run last tho. --[[Joey]]
diff --git a/doc/bugs/disabling_backlinks.mdwn b/doc/bugs/disabling_backlinks.mdwn
index ba96a4e2b..415708a50 100644
--- a/doc/bugs/disabling_backlinks.mdwn
+++ b/doc/bugs/disabling_backlinks.mdwn
@@ -28,3 +28,5 @@ auto-generated index is insufficient.
> tagged, I think you have larger problems than tags and backlinks being
> the same. Like keeping that list of links up to date as tags are added
> and changed. --[[Joey]]
+
+I see your point, Joey. I need to maintain that list manually, though, because the automatically generated list is too brief. \[[!map ...]] generates just a list of titles or descriptions. I need a list that contains both. See [[this_posting|ikiwiki/directive/map/discussion]] for more details. Until \[[!map]] can do that, I'm stuck with a manually maintained list. Which means that every link shows up in the backlinks.
diff --git a/doc/bugs/http_proxy_for_openid.mdwn b/doc/bugs/http_proxy_for_openid.mdwn
index e8f87f9c4..3d0c99b83 100644
--- a/doc/bugs/http_proxy_for_openid.mdwn
+++ b/doc/bugs/http_proxy_for_openid.mdwn
@@ -6,10 +6,42 @@ I have found if I add:
newenviron[i++]="HTTPS_PROXY=http://host.domain.com:3128";
-to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not configured.
+to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not hard coded.
Also, the ability to set HTTPS\_CA\_FILE and HTTPS\_CA\_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the [[bug_report|ssl_certificates_not_checked_with_openid]] I filed on this separate issue.
Unfortunately, HTTP\_PROXY doesn't work for http requests, it looks like that library is different.
+---
+
+Update 2008-10-26:
+
+Better solution, one that works for both http and https, and uses config options. It appears to work...
+
+Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implemented" error, see <http://community.activestate.com/forum-topic/lwp-https-requests-proxy>. Also see [[!debbug 129528]].
+
+Also note that the proxy won't work with liblwpx-paranoidagent-perl, I had to remove liblwpx-paranoidagent-perl first.
+
+Please get the patch from the *.mdwn source.
+
+louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm
+--- openid.pm.old 2008-10-26 12:18:58.094489360 +1100
++++ openid.pm 2008-10-26 12:40:05.763429880 +1100
+@@ -165,6 +165,14 @@
+ $ua=LWP::UserAgent->new;
+ }
+
++ if (defined($config{"http_proxy"})) {
++ $ua->proxy(['http'], $config{"http_proxy"});
++ }
++
++ if (defined($config{"https_proxy"})) {
++ $ENV{HTTPS_PROXY} = $config{"https_proxy"};
++ }
++
+ # Store the secret in the session.
+ my $secret=$session->param("openid_secret");
+ if (! defined $secret) {
+
+
Brian May
diff --git a/doc/bugs/rst_tweak.mdwn b/doc/bugs/rst_tweak.mdwn
index 8c7d8134d..9d433e24e 100644
--- a/doc/bugs/rst_tweak.mdwn
+++ b/doc/bugs/rst_tweak.mdwn
@@ -27,3 +27,17 @@ Does the Perl version of this plugin still exist? There appears to be no "rst.p
> No, only the python version exists. It does have `raw_enabled` set.
> --[[Joey]]
+
+I am sorry, but I am confused. Does this mean that I can use Ikiwiki
+features that translate to HTML in rst files? For example, when I use a
+\[[pagename]]-style link in a rst file, the page generated by Ikiwiki's rst
+plugin says &lt;a href="./../pagename/">pagename&lt;/a> as text. The link
+is expanded correctly, but the result isn't interpreted as HTML. Is that
+what is supposed to happen? --Peter
+
+> `raw_enabled` allows you to use the
+> [raw directive](http://docutils.sourceforge.net/docs/ref/rst/directives.html),
+> but this is not used by ikiwiki for wikilinks or anything else.
+> That's why the [[plugin_page|plugins/rst]] has its note about
+> issues with wikilinks and directives. You'd have to put those inside
+> raw directives yourself to avoid rst escaping their result. --[[Joey]]
diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
index 2dc74a984..04ece0ae8 100644
--- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
+++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn
@@ -65,4 +65,21 @@ significantly harder than the network based attacks."
With regards to implementation, I am surprised that the libraries don't seem to
do this checking, already, and by default. Unfortunately, I am not sure how to test
-this adequately, see <http://bugs.debian.org/466055>. -- Brian May
+this adequately, see [[!debbug 466055]]. -- Brian May
+
+---
+
+I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick
+is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to
+enable this checking.
+
+I think the trick is to set one of the the following environment variables before retrieving
+the data:
+
+$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/";
+$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem";
+
+Unfortunately I get weird results if the certificate verification fails, see [[!debbug 503440]].
+It still seems to work though, regardless.
+
+-- Brian May
diff --git a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
index 5d5e90f7a..472597c46 100644
--- a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
+++ b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
@@ -11,6 +11,10 @@ Replacing "ยท" with "-" in `wikiname` fixed this login issue.
> issues too.) Seems like I will have to possibly break some sessions and
> entity-encode the wikiname in the cookie.. [[done]]. --[[Joey]]
+>> I confirm it fixes the bug for me. --[[intrigeri]]
+
(BTW, such a char was replaced by -I don't remember what encoding thingie- in my setup file, when running `ikiwiki-transition setupformat`.)
> Thanks for the heads up, fixed that too. --[[Joey]]
+
+>> I confirm it fixes the bug for me. --[[intrigeri]]