| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
This implements the previously documented hashed password support.
While implementing that, I noticed a security hole, which this commit
also fixes..
|
|
|
|
|
|
Everything but the actual coding to support them.
|
|
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.
|
|
on the cgi following edit links.
|
|
|
|
Also improve error message when a pagespec fails to parse.
|
|
values. Neither method will work for all versions of perl, so check version number at runtime.
|
|
|
|
such as TZ or PATH.
|
|
generating recentchanges.
|
|
just expanded to nothing.
|
|
orphaned page.
|
|
hardcode a proper 'use lib' statement anyway. This fixes a gotcha, since PERL5LIB won't work once ikiwiki is running via a wrapper or as a cgi.
|
|
|
|
|
|
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.)
|
|
|
|
|
|
number of system calls in half. (Still room for improvement.)
|
|
|
|
|
|
|
|
stuck on shared hosting without cron. (Sheesh.) Enabled via the `aggregate_webtrigger` configuration optiom.
|
|
|
|
* Add a Bundle::Ikiwiki to the source for use with CPAN to install *all*
the modules ikiwiki can use.
* Add a cpan directory containing a CPAN::MyConfig that can ease use of
CPAN to install in a home directory on shared hosting providers.
* With these changes, it's pretty easy to install onto nearlyfreespeech.net
and probably other shared hosting providers like dreamhost. Added
a tip page documentng the process for nearlyfreespeech.
|
|
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.
|
|
This manifested as wikis with no locked pages treating them all as locked.
The bug was introduced in version 2.41.
Medium urgency upload due to above fix.
|
|
the markdown package.
|
|
|
|
recentchangediff to work with svn repos.
|
|
|
|
|
|
|
|
(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.
|
