diff options
Diffstat (limited to 'doc/bugs')
4 files changed, 113 insertions, 0 deletions
diff --git a/doc/bugs/attachment:_escaping_underscores_in_filename__63__.mdwn b/doc/bugs/attachment:_escaping_underscores_in_filename__63__.mdwn index d7d101700..4ce4ac5ee 100644 --- a/doc/bugs/attachment:_escaping_underscores_in_filename__63__.mdwn +++ b/doc/bugs/attachment:_escaping_underscores_in_filename__63__.mdwn @@ -17,3 +17,6 @@ Is it a bug or security feature? --[[Paweł|ptecza]] >> (`myisam__95__vs__95__ndb` instead of `myisam_vs_ndb`). --[[Paweł|ptecza]] > [[done]], uses `linkpage` now. + +>> It's seems that now Ikiwiki doesn't escape the filenames with underscore(s). +>> Thank you very much for the fast fix! --[[Paweł|ptecza]] diff --git a/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn b/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn new file mode 100644 index 000000000..8efd6da57 --- /dev/null +++ b/doc/bugs/markdown_bug:_email_escaping_and_plus_addresses.mdwn @@ -0,0 +1,36 @@ +compare: + + * <jon+markdownbug@example.org> + * <jon.markdownbug@example.org> + +* <jon+markdownbug@example.org> +* <jon.markdownbug@example.org> + +It seems putting a '+' in there throws it. Maybe it's a markdown bug, or maybe the obfuscation markdown applies to email-links is being caught by the HTML sanitizer. + + -- [[JonDowland]] + +> It's a markdown bug. For some reason, markdown doesn't recognize the email with a '+' as an email: +> +> $ echo '<a+b@c.org>' | markdown +> <p><a+b@c.org></p> +> +> htmlscrubber then (rightly) removes this unknown tag. +> + +>> Filed [in CPAN](http://rt.cpan.org/Ticket/Display.html?id=37909) --[[Joey]] [[tag done]] + +> But I've noticed some other Text::Markdown bugs that, even with htmlscrubber, produce +> [ill-formed (X)HTML](http://validator.w3.org/check?uri=http%3A%2F%2Fikiwiki.info%2Fbugs%2Fmarkdown_bug%3A_email_escaping_and_plus_addresses%2F). +> (View the markdown source of this page.) +> +> --Gabriel + +>> The htmlscrubber does not attempt to produce valid html from invalid. It +>> attempts to prevent exploits in html. The tidy plugin can force html to +>> valid. --[[Joey]] + +<tt> + +- +> diff --git a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn index cb4c706f0..e3bd56cfd 100644 --- a/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn +++ b/doc/bugs/ssl_certificates_not_checked_with_openid.mdwn @@ -12,6 +12,10 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more > ikiwiki) performing any sanity checking of the openid server. All the > security authentication goes on between your web browser and the openid > server. This may involve ssl, or not. +> +>> Note that I'm not an openid expert, and the above may need to be taken +>> with a grain of salt. I also can make no general statements about openid +>> being secure. ;-) --[[Joey]] > > For example, my openid is "http://joey.kitenet.net/". If I log in with > this openid, ikiwiki connects to that http url to determine what openid @@ -34,3 +38,15 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more >> for use by ikiwiki and the rest is simple. >> -- Brian May + +>>> I guess that the place to add SSL cert checking would be in either +>>> [[cpan LWPx::ParanoidAgent]] or [[cpan Net::OpenID::Consumer]]. Adding +>>> it to ikiwiki itself, which is just a user of those libraries, doesn't +>>> seem right. +>>> +>>> It's not particularly clear to me how a SSL cert can usefully be +>>> checked at this level, where there is no way to do anything but +>>> succeed, or fail; and where the extent of the check that can be done is +>>> that the SSL cert is issued by a trusted party and matches the domain name +>>> of the site being connected to. I also don't personally think that SSL +>>> certs are the right fix for DNS poisoning issues. --[[Joey]] diff --git a/doc/bugs/toggle_fails_on_Safari.mdwn b/doc/bugs/toggle_fails_on_Safari.mdwn new file mode 100644 index 000000000..25f62e088 --- /dev/null +++ b/doc/bugs/toggle_fails_on_Safari.mdwn @@ -0,0 +1,58 @@ +The [[plugins/toggle]] plugin has no effect when viewed on the Safari web browser. + +All toggles appear open all the time. + +I don't know if this is true for other webkit browsers (the new Konqueror, the iPhone, etc). +I'm currently testing in the Safari nightly builds, but I've seen the bug in the current release +of Safari too. + +Looking at the Safari Web Inspector, it believes there is a parse error on line 47 of the +[[news]] page. This is the definition of the getElementsByClass(class) function. + + 45 } + 46 + 47 function getElementsByClass(class) { + SyntaxError: Parse error + 48 var ret = new Array(); + +> Reproduced in epiphany-webkit on debian. +> +> Also noticed something interesting when I opened the page in vim. It +> highlighted the "class" like a type definition, not a variable. Sure +> enough, replacing with "c" fixed it. +> +> I wonder if webkit is actually in the right here, and using a reseved +> word like, presumably, "class" as a variable name is not legal. As I try +> to ignore javascript as much as possible, I can't say. [[done]] --[[Joey]] + +>> I also started having a look at this. I found the same issue with the +>> the variable 'class'. I'm not a javascript guru so I looked on the web +>> at other implementations of getElementsByClass() and noticed some +>> things that we might use. I took a bunch of different ideas and came +>> up with this: + + function getElementsByClass(cls, node, tag) { + if (document.getElementsByClass) + return document.getElementsByClass(cls, node, tag); + if (! node) node = document; + if (! tag) tag = '*'; + var ret = new Array(); + var pattern = new RegExp("(^|\\s)"+cls+"(\\s|$)"); + var els = node.getElementsByTagName(tag); + for (i = 0; i < els.length; i++) { + if ( pattern.test(els[i].className) ) { + ret.push(els[i]); + } + } + return ret; + } + +>> Most of the changes are minor, except that this one will use the +>> built in function if it is available. That is likely to be significantly +>> faster. Adding the extra parameters doesn't cause a problem -- +>> they're filled in with useful defaults. + +>> I don't know if it is worth making this change, but it is there if you want it. + +>>> Well, it seems to work. Although god only knows about IE. Suppose I +>>> might as well.. --[[Joey]] |