lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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:

return markdown( aText:gsub( '(<.*>)', '`%1`' ) )

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]( ">) is translated to : <a href=";&gt;";>click here</a> and not <a href="";>">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.



local TCPServer = require( 'TCPServer' )
local aServer = TCPServer( '', 1080 )

HTTP[ '/hello(%a*)' ] = function( aName ) return 'Hello ' .. ( aName or 'world' ) end

aServer( HTTP )


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:

   upstream cluster

       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 ?


Bertrand Mansion
Work :
Blog :