[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] lua-users.org alternative wiki demo
- From: Bertrand Mansion <golgote@...>
- Date: Wed, 20 Feb 2008 21:58:18 +0100
Le 20 févr. 08 à 19:12, Petite Abeille a écrit :
On Feb 20, 2008, at 11:45 AM, Bertrand Mansion wrote:
I think there are only a few tags allowed, <code> being one of
them. But I haven't checked in the source. I know that Markdown
doesn't filter this so it has to be added as a filter before
Markdown filtering is launched.
Yes, one would need a filter first. The question is more about how
restrictive one want to be: no html, some html, any html?
The question is more what is markdown not supporting that you might
need later?
Does your markdown version support html tables, definition lists,
footnotes, anchors?
Some markdown implementations do. Still HTML tables are usually a pain
to make.
1. You should probably get rid of Blueprint since it doesn't allow
liquid design and that's what you want.
But... I like blueprint! It's just like using good, old html table :))
Yep, that's exactly what I mean :)
2. Links color : I suggest light blue
Sigh...
Up to you of course :)
5. Filters : I haven't checked in your code but you should have a
safe html filter in order to avoid your site being used for XSS
attacks
Hmmm... wiki should be less prone being such a carrier as their
content is under much more scrutiny, no?
I think that you are underestimating the problem. What people see is
rendered html, not the code behind it. So someone could use the wiki
to prepare an attack against another site, for free and with Lua
blessings since the info would be hosted on a well known lua site.
In any case, better safa than sorry I guess:
-->8--
return markdown( aText:gsub( '(<.*>)', '`%1`' ) )
-->8--
This would indeed solve one part of the problem. Another cleaner
solution consists in escaping special html characters (also in links
urls).
For example, you should make sure that this markdown: [click here](http://example.com/?url=
">) is translated to :
<a href="http://example.com/?url=">">click here</a> and not <a
href="http://example.com/?url=">">click here</a> otherwise, you are
prone to XSS attacks and things related.
since you seem to rely on your HTTP.lua server ?
Yes, Nanoki has its own HTTP implementation. One could emulate such
module with CGI or what not, but... why bother?
I am not an expert at these technologies, I just thought Fastcgi+a
robust http server would be more efficient if the wiki gets lots of
traffic. I don't know how your HTTP server works in this regard, though.
Unless I missed something of course. It might then be interesting
to make it easier to deploy your work in such environments ?
Typically, one has three broad option to run something like Nanoki:
1. Using the build-in TCPServer. The TCPServer module is implemented
in terms of the LuaSocket library.
http://dev.alt.textdrive.com/browser/HTTP/TCPServer.lua
E.g.:
-->8--
local TCPServer = require( 'TCPServer' )
local aServer = TCPServer( '127.0.0.1', 1080 )
HTTP[ '/hello(%a*)' ] = function( aName ) return 'Hello ' .. ( aName
or 'world' ) end
aServer( HTTP )
--8<--
In such scenario, one has a single threaded long running instance of
a HTTP server.
2. Using an external tcp wrapper, such as D. J. Bernstein tcpserver:
% tcpserver 0 1080 lua Hello.lua
In such scenario, the tcp wrapper starts a new lua instance for each
request allowing one to handle multiple request at the concurrently
through multiple processes. This is akin to a CGI setup.
Interesting, I didn't know tcpserver.
3. Using the build-in TCPServer in a cluster configuration
Same as the first option, but with several long running processes
sitting behind a load balancer/reverse proxy of some sort, e.g.
nginx, lighttpd, apache, whatnot.
Something like this for nginx:
http
{
upstream cluster
{
server 127.0.0.1:2081;
server 127.0.0.1:2082;
server 127.0.0.1:2083;
server 127.0.0.1:2084;
}
server
{
listen 1080;
location /
{
proxy_pass http://cluster;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For
$proxy_add_x_forwarded_for;
}
}
}
Which solution would you choose for the Lua wiki given that it might
have growing needs/hits, and why ?
TIA
--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.net