diff options
Diffstat (limited to 'doc/bugs')
| -rw-r--r-- | doc/bugs/SVG_files_not_recognized_as_images.mdwn | 29 | ||||
| -rw-r--r-- | doc/bugs/cannot_preview_shortcuts.mdwn | 17 | ||||
| -rw-r--r-- | doc/bugs/disabling_backlinks.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/http_proxy_for_openid.mdwn | 34 | ||||
| -rw-r--r-- | doc/bugs/rst_tweak.mdwn | 14 | ||||
| -rw-r--r-- | doc/bugs/ssl_certificates_not_checked_with_openid.mdwn | 19 | ||||
| -rw-r--r-- | doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn | 4 |
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 <a href="./../pagename/">pagename</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]] |