Some of these might be relatively expensive to dereference or result
in messages being logged, and there's no reason why a search engine
should need to index them. (In particular, we'd probably prefer search
engines to index the rendered page, not its source code.)
CGI::FormBuilder->field has behaviour similar to the CGI.pm misfeature
we avoided in f4ec7b0. Force it into scalar context where it is used
in an argument list.
This prevents two (relatively minor) commit metadata forgery
vulnerabilities:
* In the comments plugin, an attacker who was able to post a comment
could give it a user-specified author and author-URL even if the wiki
configuration did not allow for that, by crafting multiple values
to other fields.
* In the editpage plugin, an attacker who was able to edit a page
could potentially forge commit authorship by crafting multiple values
for the rcsinfo field.
The remaining plugins changed in this commit appear to have been
protected by use of explicit scalar prototypes for the called functions,
but have been changed anyway to make them more obviously correct.
In particular, checkpassword() in passwordauth has a known prototype,
so an attacker cannot trick it into treating multiple values of the
name field as being the username, password and field to check for.
OVE-20161226-0001
Technically, when the user does this, a passwordless account is created
for them. The notify mails include a login url, and once logged in that
way, the user can enter a password to get a regular account (although
one with an annoying username).
This all requires the passwordauth plugin is enabled. A future enhancement
could be to split the passwordless user concept out into a separate plugin.
The plan is to use this for accounts that are created implicitly, as when
a non-logged-in user subscribes to notifyemail. Such an account has no
password, and login can be accomplished by way of a url that is sent to
them in email.
When the user sets a password, the passwordless login token is disabled.
Everywhere that REMOTE_ADDR was used, a session object is available, so
instead use its remote_addr method.
In IkiWiki::Receive, stop setting a dummy REMOTE_ADDR.
Note that it's possible for a session cookie to be obtained using one IP
address, and then used from another IP. In this case, the first IP will now
be used. I think that should be ok.
$cgi->params('do') may not be defined. The CSRF code may delete all
cgi params. This uninitalized value was introduced when do=register
support was added recently.
Now that openiduser is in IkiWiki core, it's ok to have passwordauth check
for it, and avoid displaying useless password fields when showing
preferences for an openid.
Also improved the styling of the display of the openid in the preferneces
page.
so that more than one plugin can use this hook.
I believe this is a safe change, since only passwordauth uses this hook.
(If some other plugin already used it, it would have broken passwordauth!)
passwordauth page to the basewiki describing password
authentication; like openid, it uses conditional to check which
forms of authentication the wiki allows. Add conditional cross-
links between the openid and passwordauth pages, to help the user
understand how they can log in.
for extended pagespecs. The old calling convention will still work for
back-compat for now.
* The calling convention for functions in the IkiWiki::PageSpec namespace
has changed so they are passed named parameters.
* Plugin interface version increased to 2.00 since I don't anticipate any
more interface changes before 2.0.
including out of disk space situations. ikiwiki should never leave
truncated files, and if the error occurs during a web-based file edit,
the user will be given an opportunity to retry.
Inspired by the many ways Moin Moin destroys itself when out of disk. :-)
* Fix syslogging of errors.
edited.
* Move code forcing signing before edit to a new "signinedit" plugin, and
code checking for locked pages into a new "lockedit" plugin. Both are
enabled by default.
* Remove the anonok config setting. This is now implemented by a new
"anonok" plugin. Anyone with a wiki allowing anonymous edits should
change their configs to enable this new plugin.
* Add an opendiscussion plugin that allows anonymous users to edit
discussion pages, on a wiki that is otherwise wouldn't allow it.
* Lots of CGI code reorg and cleanup.
Simon McVittie
Joey Hess
Joey Hess
Joey Hess
Joey Hess
joey
joshtriplett