| Age | Commit message (Collapse) | Author |
|---|
|
|
|
wikilinks added by filters from being scanned properly. But no known filter hook does that, and calling filters unncessarily during scan slowed down complex filters such as the one used to update the xapian index.
|
|
The omega docs suggest doing this if the term may contain upper case, which
it could here.
|
|
"substr outside of string"
|
|
this seems to be the thing to use for a unique id
|
|
|
|
|
|
|
|
|
|
Still some TODOs to fill in.
|
|
Everything is done except for the actual indexing. I plan to do incremental
indexing as pages change.
|
|
avoid overoptimising.
|
|
|
|
This implements the previously documented hashed password support.
While implementing that, I noticed a security hole, which this commit
also fixes..
|
|
|
|
|
|
explicitly pass 0 (FB_DEFAULT) as the second parameter. Apparently perl 5.8 needs this to avoid crashing on malformed utf-8, despite its docs saying it is the default.
|
|
between the two versions.
|
|
values. Neither method will work for all versions of perl, so check version number at runtime.
|
|
|
|
generating recentchanges.
|
|
just expanded to nothing.
|
|
orphaned page.
|
|
|
|
Something has changed in CGI.pm in perl 5.10. It used to not care
if STDIN was opened using :utf8, but now it'll mis-encode utf-8 values
when used that way by ikiwiki. Now I have to binmode(STDIN) before
instantiating the CGI object.
In 57bba4dac132a06729eeec809f5e1a5adf829806, I changed from decoding
CGI::Formbuilder fields to utf-8, to decoding cgi parameters before setting
up the form object. As of perl 5.10, that approach no longer has any effect
(reason unknown). To get correctly encoded values in FormBuilder forms,
they must once again be decoded after the form is set up.
As noted in 57bba4da, this can cause one set of problems for
formbuilder_setup hooks if decode_form_utf8 is called before the hooks, and
a different set if it's called after. To avoid both sets of problems, call
it both before and after. (Only remaining problem is the sheer ugliness and
inefficiency of that..)
I think that these changes will also work with older perl versions, but I
haven't checked.
Also, in the case of the poll plugin, the cgi parameter needs to be
explcitly decoded before it is used to handle utf-8 values. (This may have
always been broken, not sure if it's related to perl 5.10 or not.)
|
|
|
|
|
|
This allows plugins to getopt and change what is done before an incorrect
line is printed.
|
|
Turns out duplicate index files do not need to be stored when usedirs is in
use, just when it's not. Ikiwiki is quite consistent about using page/ when
usedirs is in use. (The only exception is the search plugin, which needs
fixing.)
This also includes significant code cleanup, removal of a incorrect special
case for empty files, and addition of a workaround for a bug in the amazon
perl module.
|
|
|
|
|
|
|
|
|
|
pruning not yet implemented, however
|
|
number of system calls in half. (Still room for improvement.)
|
|
|
|
|
|
stuck on shared hosting without cron. (Sheesh.) Enabled via the `aggregate_webtrigger` configuration optiom.
|
|
message when the file doesn't exist.
|
|
srcfile now has an optional second parameter to avoid it throwing an error
if the source file does not exist.
|
|
|
|
anonymous users to edit only matching pages. Closes: #478892
|
|
|
|
This allows the toc to be displayed when previewing an edit. It also avoids headers in the page template from showing up in the toc.
|
|
(Scott Bronson)
|
|
|
|
The fix involved embedding the session id in the forms, and not allowing the
forms to be submitted if the embedded id does not match the session id.
In the case of the preferences form, if the session id is not embedded,
then the CGI parameters are cleared. This avoids a secondary attack where the
link to the preferences form prefills password or other fields, and
the user hits "submit" without noticing these prefilled values.
In the case of the editpage form, the anonok plugin can allow anyone to edit,
and so I chose not to guard against CSRF attacks against users who are not
logged in. Otherwise, it also embeds the session id and checks it.
For page editing, I assume that the user will notice if content or commit
message is changed because of CGI parameters, and won't blndly hit save page.
So I didn't block those CGI paramters. (It's even possible to use those CGI
parameters, for good, not for evil, I guess..)
The only other CSRF attack I can think of in ikiwiki involves the poll plugin.
It's certianly possible to set up a link that causes the user to unknowingly
vote in a poll. However, the poll plugin is not intended to be used for things
that people would want to attack, since anyone can after all edit the poll page
and fill in any values they like. So this "attack" is ignorable.
|
|
Also, simplified finding the url to the top of the site.
|
|
tag 473987 +patch
thanks
Hi,
The issue is that we need to convert relative links to absolute
ones for atom and rss feeds -- but there are two types of
relative links. The first kind, relative to the current
document ( href="some/path") is handled correctly. The second
kind of relative url is is relative to the http server
base (href="/semi-abs/path"), and that broke.
It broke because we just prepended the url of the current
document to the href (http://host/path/to/this-doc/ + link),
which gave us, in the first place:
http://host/path/to/this-doc/some/path [correct], and
http://host/path/to/this-doc//semi-abs/path [wrong]
The fix is to calculate the base for the http server (the base of
the wiki does not help, since the base of the wiki can be
different from the base of the http server -- I have, for example,
"url => http://host.name.mine/blog/manoj/"), and prepend that to
the relative references that start with a /.
This has been tested.
Signed-off-by: Manoj Srivastava <srivasta@debian.org>
|
|
lacking one.
|
