Merge commit 'origin/master' into tova
commit
a759a864f3
|
@ -0,0 +1,30 @@
|
|||
From the source of [[usage]]:
|
||||
|
||||
<a href="mailto:joey@ikiwiki.info">joey@ikiwiki.info</a>
|
||||
|
||||
Text::Markdown obfuscates email addresses in the href= attribute and in the text.
|
||||
Apparently this can't be configured.
|
||||
|
||||
HTML::Scrubber doesn't set `attr_encoded` for its HTML::Parser, so the href= attribtute is decoded.
|
||||
Currently it seems it doesn't set `attr_encoded` for good reason: so attributes can be sanitized easily,
|
||||
e.g. as in htmlscrubber with `$safe_url_regexp`.
|
||||
This apparently can't be configured either.
|
||||
|
||||
So I can't see an obvious solution to this.
|
||||
Perhaps improvements to Text::Markdown or HTML::Scrubber can allow a fix.
|
||||
|
||||
One question is: how useful is email obfuscation?
|
||||
Don't spammers use HTML parsers?
|
||||
|
||||
> I now see this was noted in the formatting [[/ikiwiki/formatting/discussion]], and won't/can't be fixed.
|
||||
> So I guess this is [[done]]. --Gabriel
|
||||
|
||||
I've [[patch]]ed mdwn.pm to prevent Text::Markdown from obfuscating the emails.
|
||||
The relevant commits are on the master branch of [my "fork" of ikiwiki on Github] [github]:
|
||||
|
||||
- 7d0970adbcf0b63e7e5532c239156f6967d10158
|
||||
- 52c241e723ced4d7c6a702dd08cda37feee75531
|
||||
|
||||
--Gabriel.
|
||||
|
||||
[github]: http://github.com/gmcmanus/ikiwiki/
|
|
@ -0,0 +1,20 @@
|
|||
Suppose a wiki has a source page a.mdwn, which is then moved to a.wiki.
|
||||
(Suppose both the mdwn and wikitext plugins are enabled, so this changes how "a" is rendered.)
|
||||
Currently, when the wiki is refreshed, ikiwiki doesn't notice the change
|
||||
and the page is not rebuilt.
|
||||
|
||||
I have a [[patch]] that fixes this.
|
||||
The relevant commit on [my Github fork of ikiwiki](http://github.com/gmcmanus/ikiwiki/) is:
|
||||
|
||||
b6a3b8a683fed7a7f6d77a5b3f2dfbd14c849843
|
||||
|
||||
The patch (ab)uses`%forcerebuild`, which is meant for use by plugins.
|
||||
If, for some reason, a plugin deletes the page's entry in `%forcerebuild`, it won't be rebuilt.
|
||||
|
||||
This patch uncovers another problem.
|
||||
Suppose a wiki has a source page "a" (no extension)
|
||||
which is then moved to "a.mdwn" (or vice versa).
|
||||
ikiwiki fails when trying to create a directory "a" where there is a file "a"
|
||||
(or vice versa).
|
||||
|
||||
The same problem occurs if both "a" and "a.mdwn" exist in the wiki.
|
|
@ -22,4 +22,15 @@ For now, I want to try and resolve the issues with net\_ssl\_test, and run more
|
|||
> is good.
|
||||
> --[[Joey]]
|
||||
|
||||
[[!tag done]]
|
||||
>> Ok, so I guess the worst that could happen when ikiwiki talks to the http
|
||||
>> address is that it gets intercepted, and ikiwiki gets the wrong address.
|
||||
>> ikiwiki will then redirect the browser to the wrong address. An attacker could
|
||||
>> trick ikiwiki to redirect to their site which always validates the user
|
||||
>> and then redirects back to ikiwiki. The legitimate user may not even notice.
|
||||
>> That doesn't so seem secure to me...
|
||||
|
||||
>> All the attacker needs is access to the network somewhere between ikiwiki
|
||||
>> and http://joey.kitenet.net/ or the ability to inject false DNS host names
|
||||
>> for use by ikiwiki and the rest is simple.
|
||||
|
||||
>> -- Brian May
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
Xapian supports indexing pdfs, openoffice docs, etc. It would be nice if
|
||||
the search plugin would index these documents and optionally allow their
|
||||
exclusion.
|
||||
|
||||
[[!tag wishlist]]
|
Loading…
Reference in New Issue