| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
ErrorDocument
|
|
|
|
|
|
| |
IkiWiki page name
Also add a regression test
|
| |
|
| |
|
|
|
|
|
|
| |
redirect to a page
This can replace equivalent functionality in comments and recentchanges.
|
|
|
|
|
|
| |
This redirects to the given page (or if none is given, the page parameter
given to the CGI), or displays an error with a create link if the page
doesn't exist.
|
|
|
|
|
|
|
|
|
|
| |
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.
|