| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
A new ikiwiki-transition moveprefs subcommand can pull the old data out of
the userdb and inject it into the setup file.
Note that it leaves the old values behind in the userdb too. I did this
because I didn't want to lose data if it fails writing the setup file for
some reason, and the old data in the userdb will only use a small amount of
space. Running the command multiple times will mostly not change anything.
|
| | |
|
| |
|
|
|
| |
This function as factored out was a bit confusing, I think this makes more
sense.
|
| | |
|
| |
|
|
| |
entity-encoding the wikiname in the session cookie.
|
| |
|
|
| |
if desired.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The recent setup revamp exposed some latent bugs in use/package ordering
that caused some symbols to not the exported into the correct scope.
|
| | |
|
| |
|
|
|
|
| |
The constructor can fail with a useless error message if module fail to
load. Work around this by evaling it, and checking for failures, and
printing CGI::Session->errstr to get a more useful message.
|
| |
|
|
|
|
|
|
|
|
|
| |
* The editpage form now uses the raw page name, not the page title, in its
'page' cgi parameter. Using the title was ambiguous and made it
impossible to tell between some pages, like "foo/bar" and "foo__47__bar",
sometimes causing the wrong page to be edited.
* This change means that some edit links need to be updated.
Force a rebuild on upgrade to this version.
* Above change also allowed really fixing escaped slashes from the blogpost
form.
|
| |
|
|
|
| |
Make it a config setting, this way subtle load order issues don't come into
play. (As much?)
|
| | |
|
| |
|
|
|
| |
This allows plugins that want to enable uploads to do so by changing the
value of $CGI::DISABLE_UPLOADS at some point before the cgi hook is run.
|
| |
|
|
|
| |
The title was set to editpage, but then always changed.
And some code tested for this. Remove this dead code.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* toc: Revert change in 2.45 that made it run at sanitize time. This breaks
use of toc in a sidebar.
* Call format hooks when generating page previews, thus fixing toc display
there, as well as fixing inlins to again display in page previews, since
it's started using format hooks. This also allows several other things,
like embed, that use format hooks, to work during page preview time.
* Format hooks should not rely on getting an entire html document, as they
will only get the body during page preview.
* toggle: Deal with preview mode when adding javascript.
|
| |
|
|
|
|
|
|
| |
Because the search plugin needed it, also because it's one of the few
plugins that didn't already have it.
I also considered adding it to htmlize, but I really cannot imagine caring
what the destpage is when htmlizing. (I'll probably be poven wrong later.)
|
| |
|
|
| |
values. Neither method will work for all versions of perl, so check version number at runtime.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
| |
srcfile now has an optional second parameter to avoid it throwing an error
if the source file does not exist.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
things that need to know the page source or type can query it from there.
Fixes previewing of tables when creating a new page.
|
| |
|
|
|
|
| |
set to the destination page. This avoids need for hacks to munge the urls
in preview mode, which fixes several bugs.
* Several destpage fixes in plugins.
|
| |
|
|
|
|
|
|
|
|
| |
As was already done for linkfication, links generated in a prevew page
are relative to the top of the wiki, so it has to be told that the destpage
is there.
I was using "" to indicate this, but that may confuse some preprocessor
plugins, which treat parameters with an empry value specially (sparkline is one
such). Instead, use "/", which is more accurate anyway and works just as well.
|
| |
|
|
|
|
|
|
| |
(as preserving the full list across preview would be tricky). Userdirs
were still being offered as an option there, remove them.
* Fix a bug where user A created a page concurrently with user B, and
when B previewed it would redirect B to A's new page, losing B's work.
Instead, don't redirect and let conflict handling resolve it.
|
| |
|
|
|
| |
This call is only present to handle the case where previewing a page
actually causes files to be rendered.
|
| | |
|
| |
|
|
|
| |
* This allows locking the wiki before loading state, which avoids some
tricky locking code when saving a web edit.
|
| |
|
|
| |
Doesn't look as good as the old table, but works as a rss feed.
|
| |
|
|
|
| |
the svnrepo and notify settings, though both will be ignored if left in
setup files.
|
| |
|
|
|
|
| |
If a page type starts with an underscore, hide it from the list of page types
in the edit form, and don't allow editing pages of that type. This allows
for plugins to add page types for internal use.
|
| |
|
|
| |
I have a plugin that needs to use userlink.
|
| |
|
|
|
| |
No point in using a relative time value in rcs_recentchanges. Different
consumers of the info want different things.
|
| | |
|
| |
|
|
| |
This happens when openid auth fails in certian ways
|
| | |
|
| |
|
|
|
|
|
| |
returned (and not run in some cases) rather than the plugins directly
forcing a user to log in.
* opendiscussion: allow editing of the toplevel discussion page,
and, indirectly, allow creating new discussion pages.
|
| |
|
|
|
| |
user goes back from the signin screen and does something else.
* Improve behavior when trying to sign in with no cookies.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* decode_form_utf8 only fixed the utf-8 encoding for fields that were
registered at the time it was called, which was before the
formbuilder_setup hook. Fields added by the hook didn't get decoded.
But it can't be put after the hook either, since plugins using the hook
need to be able to use form values. To fix this dilemma, it's been changed
to a decode_cgi_utf8, which is called on the cgi query object, before the
form is set up, and decodes *all* cgi parameters.
|
| |
|
|
| |
creating a new page that's entirely empty.
|
| | |
|