Re: [cgiapp] Dancer
On Tue, 2 Mar 2010 13:38:15 -0500 Mark Stosberg m...@summersault.com wrote: On Thu, 25 Feb 2010 17:51:40 -0600 P Kishor punk.k...@gmail.com wrote: following Mark Stosberg's email about PSGI, I decided to poke around a bit more, and landed up with Dancer. Color me very impressed. Seriously, I have seldom experienced such easy *everything*. Almost instant installation via 'sudo cpan Dancer', a simple 'dancer -a myapp', and I had a working, nice looking application framework [*] with nice URIs and ev'ryting. So, my question is thus -- how is Dancer different from CGI::App, and why should I use the latter instead of the former? I asked this not lightly because I have many years of experience invested in C::A, but Dancer truly shows how apps should be. I had already looked at Dancer myself. As a result, you can see these entries in the Dancer ChangeLog: * Security Fix: protection from CRLF injection in response headers (thanks to Mark Stosberg for the report). * Support for multi-valued params in GET/POST data (thanks to Mark Stosberg for the report). So, in a short review, I found that it lacked support for multi-valued params, and that it had a notable security hole. If you look into it deeper, what else might you find? I should qualify my further comments further. CGI.pm also had a similar issue with allowing CRLF injection attacks in some cases, as did CGI::Simple. It's not what I would call a security vulnerability in any case because you have to write code that would be tainted for their to be a problem-- you would have to take untrusted data and use it to a build a header without first validating it. The issue with Dancer here speaks more to choice of rolling their own instead of re-using. So, when CGI.pm and CGI::Simple get upgraded, CGI::Application is able to take advantage of those improvements automatically, but Dancer does more in-use. That is fine if Dancer turns out to have everything correct and complete. The issue with missing support for multi-valued params I think is just a sign of it being a young and evolving project at the time I reviewed it. Mark # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Dancer
following Mark Stosberg's email about PSGI, I decided to poke around a bit more, and landed up with Dancer. Color me very impressed. Seriously, I have seldom experienced such easy *everything*. Almost instant installation via 'sudo cpan Dancer', a simple 'dancer -a myapp', and I had a working, nice looking application framework [*] with nice URIs and ev'ryting. So, my question is thus -- how is Dancer different from CGI::App, and why should I use the latter instead of the former? I asked this not lightly because I have many years of experience invested in C::A, but Dancer truly shows how apps should be. [*] can something so simple to setup and run be actually called a framework? -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --- Assertions are politics; backing up assertions with evidence is science === # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Dancer
P Kishor wrote: So, my question is thus -- how is Dancer different from CGI::App, and why should I use the latter instead of the former? I asked this not lightly because I have many years of experience invested in C::A, but Dancer truly shows how apps should be. I've taken a quick look at Dancer, haven't played with it yet. It certainly has some interesting things going on. I think when I play with the code I'll be aiming to pull some things into my cgi-app based superclass. I like the way cgi-app does things, I like the way Dancer simplifies some things. I like the statement from Mark (I think, correct me) that cgi-app is a good framework for creating frameworks. I'm building my own cgi-app based superclass for my software, I see Dancers simplicity will likely become a problem for the kinds of things I'm wanting to do, but that isn't to say that I can't incorporate some of the ideas into my superclass. Dancer recent came up on Bristol and Bath perl moungers (http://perl.bristolbath.org), Nigel mentioned a couple of other frameworks Mojo and Tatsumaki. I haven't looked at them yet, but if you are looking at Dancer, it's probably worth checking them out as well. Lyle # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] Dancer
On Thu, Feb 25, 2010 at 6:51 PM, P Kishor punk.k...@gmail.com wrote:
So, my question is thus -- how is Dancer different from CGI::App, and
why should I use the latter instead of the former? I asked this not
lightly because I have many years of experience invested in C::A, but
Dancer truly shows how apps should be.
I haven't used Dancer, but I can tell you a few things about the
example code in the docs that rub me the wrong way. Here's a small
piece:
get '/hello/:name' = sub {
return Why, hello there . params-{name};
};
Note that get() is imported. I hope you never want a method called
get() in code that uses Dancer (or set(), since that's used for
something else). In fact a large number of keywords are imported, as
you'll see if you look at @EXPORT in the Dancer.pm source.
What's the syntax here? It doesn't really look like valid perl, does
it? It's really doing this:
get($url, $sub_ref);
So, it's kind of sneaky, which is another thing I don't like to see in
code. The params thing (it's a function that reads the current
request from a global) is also sneaky for no good reason IMO.
I don't think I'd enjoy writing a lot of code in sub refs either,
especially not when trying to run a profiler or the debugger on them.
I suppose you can get around that with a CGI::App-style construction
like this:
get('process_form' = \process_form);
sub process_form {
[...]
}
OTOH, there are definitely some nice-looking things about this
package. It has a good amount of docs for a new distribution, a lot
of tests, and the code style internally looks good and easy to follow.
It's really just the syntax and the namespace pollution that bother
me.
- Perrin
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
