| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
| |
This can happen if the user goes directly to /ikiwiki.cgi?do=login and
logs in, since nothing redirected them to there, there's no postsignin
value set. It can also happen when cookies are disabled, or perhaps
other problems.
|
| |
|
|
|
| |
$@ could be clobbered by the "exception handler", and in practice
it seems that it is. This can be seen on stderr of t/git-cgi.t.
|
| |
|
|
|
| |
If misconfiguration has resulted in an empty session name, treat the
session as having not signed in.
|
| |
|
|
|
|
|
|
|
|
| |
These instances of code similar to OVE-20170111-0001 are not believed
to be exploitable, because defined(), length(), setpassword(),
userinfo_set() and the binary "." operator all have prototypes that
force the relevant argument to be evaluated in scalar context. However,
using a safer idiom makes mistakes less likely.
(cherry picked from commit 69230a2220f673c66b5ab875bfc759b32a241c0d)
|
| |
|
|
| |
Signed-off-by: Simon McVittie <smcv@debian.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The instance in cgierror() is a potential cross-site scripting attack,
because an attacker could conceivably cause some module to raise an
exception that includes attacker-supplied HTML in its message, for
example via a crafted filename. (OVE-20160505-0012)
The instances in preprocess() is just correctness. It is not a
cross-site scripting attack, because an attacker could equally well
write the desired HTML themselves; the sanitize hook is what
protects us from cross-site scripting here.
|
| |
|
|
| |
of modules' APIs
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
banned_users
This was needed due to emailauth, but I've also wrapped all IP address
exposure in cloak(), although the function doesn't yet cloak IP addresses.
(One IP address I didn't cloak is the one that appears on the password
reset email template. That is expected to be the user's own IP address,
so ok to show it to them.)
Thanks to smcv for the pointer to
http://xmlns.com/foaf/spec/#term_mbox_sha1sum
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit feb21ebfacb341fc34244e1c9b8557fd81d1dfc1 added a
safe_decode_utf8 function that avoids double decoding on Perl 5.20.
But the Perl behavior change actually happened in Encode.pm 2.53
(https://github.com/dankogai/p5-encode/pull/11). Although Perl 5.20
is the first Perl version to bundle an affected version of Encode.pm,
it’s also possible to upgrade Encode.pm independently; for example,
Fedora 20 has Perl 5.18.4 with Encode.pm 2.54. On such a system,
editing a non-ASCII file still fails with errors like
Error: Cannot decode string with wide characters at
/usr/lib64/perl5/vendor_perl/Encode.pm line 216.
There doesn’t seem to be any reason not to check Encode::is_utf8 on
old versions too, so just remove the version check altogether.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Bug-Debian: https://bugs.debian.org/776181
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
CGI->param has the misfeature that it is context-sensitive, and in
particular can expand to more than one scalar in function calls.
This led to a security vulnerability in Bugzilla, and recent versions
of CGI.pm will warn when it is used in this way.
In the situations where we do want to cope with more than one parameter
of the same name, CGI->param_fetch (which always returns an
array-reference) makes the intention clearer.
[commit message added by smcv]
|
| |
|
|
| |
This increases the number of situations in which we do the right thing.
|
| |
|
|
|
| |
This solves several people's issues with the CGI trying to be
too clever when IkiWiki is placed behind a reverse-proxy.
|
| | |
|
| |
|
|
|
|
|
| |
this works around a behavior change introduced in Encode.pm 2.53
shipped with the Perl 5.20 release described here:
http://ikiwiki.info/bugs/garbled_non-ascii_characters_in_body_in_web_interface/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As noted in the Try::Tiny man page, eval/$@ can be quite awkward in
corner cases, because $@ has the same properties and problems as C's
errno. While writing a regression test for definetemplate
in which it couldn't find an appropriate template, I received
<span class="error">Error: failed to process template
<span class="createlink">deftmpl</span> </span>
instead of the intended
<span class="error">Error: failed to process template
<span class="createlink">deftmpl</span> template deftmpl not
found</span>
which turned out to be because the "catch"-analogous block called
gettext before it used $@, and gettext can call define_gettext,
which uses eval.
This commit alters all current "catch"-like blocks that use $@, except
those that just do trivial things with $@ (string interpolation, string
concatenation) and call a function (die, error, print, etc.)
|
| |
|
|
|
|
|
|
|
|
| |
Normally, needsignin is called when there is a QUERY_STRING, not when a
form is posted. However, it's certianly possible, and should be supported,
to make a form that invokes an ikiwiki action that checks needsignin.
I encountered this when posting ?do=rename&page=foo. The form is displayed
without checking needsignin, for complicated reasons. Posting the form
is when the true authentication happens.
|
| | |
|
| | |
|
| |
|
|
| |
it. (There does not seem to be a standard here.)
|
| |
|
|
| |
3.20101231.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
cgitemplate is a modified misctemplate that takes an optional cgi object
and uses it to set the baseurl, and also optionally the forcebaseurl,
if a page is provided.
If no cgi object is provided, it will fall back to using $config{url}.
I expect this will only be needed in exceptional cases where
that doesn't much matter, such as cgierror().
showform uses cgitemplate, so there is no more need for showform_preview.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Was broken (in theory) by baseurl changes in last release.
|
| |
|
|
|
| |
Added a showform_preview that is like showform, but sets forcebaseurl
to point to the page being previewed.
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Suppress disiplay of small search for on search results page, and of
Prefrences link on prefs page.
|
| |
|
|
| |
buttons are pressed
|
| |
|
|
|
|
| |
Since all forms are wrapped in a template that defines the actual
stylesheets, formbuilder just has to be told to turn on stylesheet mode,
not what file is the style sheet.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Problem here was that no charset http header was being sent.
I fixed this globally by making cgi_custom_failure send the header.
Required changing its parameters.
|
| |
|
|
|
|
|
|
|
| |
When redirecting to a page, ie, after editing, ensure that the url is
uri-encoded. Most browsers other than MSIE don't care, but it's the right
thing to do.
The known failure case involved editing a page that had utf-8 in the name
using MSIE.
|
| |
|
|
| |
IP address.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is likely a misconfiguration and can cause login to fail as the
browser refuses the send the session cookie back over http.
Not entirely happy with putting the check where I did, since users have to
try to log in, and fail, to see the misconfiguration explained. But I could
not find a better place to put the check.
|
| | |
|
| | |
|
| |
|
|
|
| |
Also make it ignore the 'do' parameter at Joey's suggestion, to have one
less thing to remember when configuring.
|
| |
|
|
|
| |
IE displays its own error responses unless the server's was >= 512 bytes.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807
|