Using <object> and <embed> were forbidden for obvious
security reasons. Instiki now permits embedding video
via the HTML5 <video> element (Ogg/Theora encoded videos
only, with .ogg or .ogv extensions). You can even upload
videos with
[[foo.ogg:video]]
Instiki now support x-sendfile. See the Proxying page for
configuring Apache (with the x-sendfile module). Lighttpd
should work similarly.
Update Rails to latest Edge (hopefully converging on RC2!).
Dunno why this was buggered again. ":back" doesn't seem to function as it used to.
Also, when uploading a file from page "foo", it's important to return to "foo" after
a successful upload, rather than redirecting to the HomePage.
Finally, a favicon tweak.
A Maruku-syntax <div> with an unclosed IAL (and, it seems, at least one equation)
would cause Instiki to hang. Badly. Requiring a 'kill -9' to terminate it.
Reverting the OpenDiv and CloseDiv Regexps to my, more simple-minded, versions
fixes the problem.
Instiki now runs on the Rails 2.3.0 Candidate Release.
Among other improvements, this means that it now
automagically selects between WEBrick and Mongrel.
Just run
./instiki --daemon
On Webs with file uploads enabled, uploaded files were stored
(in version 0.16.1 and earlier) in the public/ directory.
This was a security threat. A miscreant could upload a .html file.
When a user clicked on the link to the file, it was opened (unsanitized)
in the browser.
As of version 0.16.2, uploaded files are stored in the webs/
directory. Now, when the user clicks on the link, the file is sent
with the
Content-Disposition: attachment
header set, which causes the file to be downloaded, rather than opened
in the browser. As always, files downloaded from the internets should be
treated with caution. At least, this way, they are not aoutomatically
opened in the browser.
To move your existing uploaded files to the new location, do a
rake upgrade_instiki
When a Web uses one of the Markdown Text Filters, and you export
all the pages as a zip file, you'd like the MathML and SVG to
render when the pages are viewed locally. This means saving them
with a .xhtml extension. Users of non-XHTML-capable browsers or
Textile users should still get .html files.
Ruby's String.sub!(pattern, replacement) routine is fundamentally
broken. But the block version works fine.
Using the broken routine in the Chunk handler was a subtle mistake.
WikiWord (and the like) could wreak havoc in equations. Protect them
(the way <a>, <pre> and <code> blocks are protected).
For some reason, this doesn't seem to work in inline equations.
Maruku is doing something funny there ... => one failing Unit Test.
For the file_list action, include the pages which link to the given file(s).
This required rejiggering so that that information is actually retained in the database.
Unfortunately, you'll actually need to revise the page(s) in question, because that's the
only time this information is updated in the database.
Some more tests from Clint Ruoho. The main branch of Instiki (and, I guess,
the old sanitizer) are vulnerable.
Also: under Ruby 1.8.x, CGI.unescapeHTML screws up horribly decoding NCRs
which represent high-bit ASCII characters. UTF-8 agrees with 7-bit ASCII,
but CGI.unescapeHTML doesn't seem to know that they disagree for i>127.
Make this version (minimally) usable with Textile Markup:
For Webs with "Textile", "RDoc" or "Mixed" markup option selected,
send text/html instead of application/xhtml+xml. This makes this
software minimally usable with those markup dialects.
"Markdown+itex2MML", "Markdown+BlahTeX/PNG" and "Markdown" should work
as before, sending application/xhtml+xml to capable browsers.
Bump the version number.
Deleting a page removes all revisions of that page.
Deleting a Web removes all pages (and all revisions thereof)
and all wiki_files belonging to that Web.
CMyApp is a WikiWord (at least, on other Wiki systems, like TWiki).
Should allow that here
Also, choose a more obscure name for the thread-local variable tracking
included chunks.
Use "Thread.current[:included_by]" instead of the Class variable,
"@@included_by".
The former will work on some newfangled multi-threaded Webserver stack,
which uses separate threads to handle multiple simlutaneous requests
(one request/thread). Dunno that the rest of the application is
thread-safe, but using a class variable, in this context, probably isn't.
Thanks to Sam Ruby for the suggestion.
