I am choosing a Scala web framework. Among frameworks I am considering are Play, Scalatra and Lift. In the project I am preparing for, security is important. However, web security is a blurry subject for me, and I would like my framework to handle it to a reasonable extent. I seem to be drawn to Play.
I am not asking what is the most secure framework (according to ads – Lift), but, rather, do Scala frameworks handle security for me, and how do they compare in that respect? I don't want to solely rely on my knowledge to make the web-app secure.
I'd vote for Liftweb http://seventhings.liftweb.net/security
The major difference to other frameworks (and especially to java's, like Spring) is what one may call "default behavior". For example, while coding, you can forget to "escape", some html attribute. In a bad framework you'll get errors with corrupt html and security holes. In a good framework you'll have double-escape or an error.
A full list of examples can actually be read in link. What personally I love Lift for is it's statefulness, Scala bindings to HTML like
"#myHtmlNode li div [onclick]" #> ajaxInvoke(...scala code here...)
In the code above, you'll be 100% sure that no one will have access to the contents of ajaxInvoke except for those users you sent the page yourself. And separation of the logic and the view is a relief, of course.
To answer my own question, I have to learn this stuff, no one is going to do it for me. There's OWASP cheatsheets; and also OWASP Enterprise Security API or ESAPI. ESAPI looks promising, though I haven't used it yet.
Related
I have worked on the .NET side of things but I am looking at new open-source based web frameworks for a new project.
I looked at LIFT-web, Play, Ruby on Rails etc. LIFT seems very promising for out of the box security and performance. But it claims to have a new approach "view first" instead of MVC. This sounds very similar to the ASP.net web forms paradigm, which was great for drag and drop development but had challenges in terms of testability and having control on what actually
I am wondering whether testing and having full visibility and control on the runtime behavior of LIFT will be difficult. I will appreciate any feedback from people who have used LIFT, better still if they have used both.
Thanks!
I can see why you think they might be similar, but in practice it's not really the case... not for larger applications anyway. If you're building a trivial application in a similar style to web forms, then you'll see similar issues. Lift snippets are in some respects similar to web forms user controls, but the latter are typically abused with munging all manner or content, request, state and so forth together which can indeed make things difficult to test. It's also possible to do that with Lift, as the framework won't stop you. However, idiomatically I wouldn't do that, as I try to ensure my snippets (user controls if you like) are referentially transparent NodeSeq => NodeSeq (xml to xml) functions. Snippets have an exceedingly close relationship with rendering content, and thats all. In addition, you may be interested to look more closely at the site map feature (many people overlook it), as there are some interesting ways in which that can be employed as a mini-controller w/r/t to the incoming request.
So, to try and qualify somewhat, you could indeed make ugly, untestable code with Lift - many people do - but if you keep your business logic properly separated out from the web tier and employ some developer discipline it's a manageable issue. In the main, the benefits largely outweigh the cons - especially in light of no other Scala web frameworks implementing the kinds of security or comet features Lift has.
The bottom line is that if you're building a CRUD application, then its highly likely Lift isn't for you. However, if you're building a rich, ajax or comet app, then its certainly going to be worth a look.
Hope that helps.
PS: You might be interested in checking out "Lift in Action"; it covers some of these topics - http://www.manning.com/perrett/
Is there a bare-bones Scala web framework? I basically need the essential features such as:
Routing.
GET/POST/PUT parameter handling.
A simple templating engine (content substitution based).
Serialization (JSON, YAML)
I don't like Lift as it does too much for me, as I would like complete control over the generated HTML, meaning that I want to be able to write 100% of the HTML/CSS/JS code.
Is there such a framework? Or is it possible to use Lift in a way that no HTML is generated behind the scenes? Or would I be better of writing a normal servlet?
Perhaps you'd like something like Scalatra or Unfiltered? On a separate note, you need not give up any control of your HTML/CSS/JS in a Lift app if you don't want to.
You can just use Lift to generate services, such as REST ones, is that more or less what you are looking for? http://www.assembla.com/spaces/liftweb/wiki/REST_Web_Services
If we take a look at What Scala web-frameworks are available? none of them have a great simple templating engine, at least to me it seems that way. SweetScala seems the closest though http://code.google.com/p/sweetscala/wiki/GettingStarted
Peter gave a great answer... I'll expand on it a little.
Lift gives you a ton of control and access to raw HTTP requests as well as providing a ton of abstractions on top of the HTTP level. It's your choice on how much or how little you want Lift to do.
You can built a REST-based application using Lift's RestHelper. See http://simply.liftweb.net/index-Chapter-5.html The advantage that Lift's RestHelper gives you over most MVC/Routing based approaches is type-safety and access control at the very edge of your application. But using Scala's pattern matching extractors, you can insure that parameters delivered to the business logic of your application have already been materialized and checked for access control. Further, Lift's REST support will be as concise or more concise than other web frameworks.
In terms of Lift's HTML handling, you have a ton of control over the creation of the HTML, as long as you want to generate HTML as a valid DOM rather than as a series of Strings.
Most web frameworks force you to emit Strings when you're composing HTML. It's up to the developer to properly HTML-escape Strings. It's up to the developer to make sure that closing tags line up correctly. With Lift, you get this kind of thing for free.
You can serve HTML from Lift apps in MVC style. See https://github.com/dpp/hoisted (this is the code that powers http://liftweb.net)
In the "standard" configuration of Lift apps, Lift does some post-processing of the HTML if, and only if, you use certain construct. So, if you put a <head> tag in the body, the HTML page, Lift will take the contents of that <head> tag and move it to the head section of the page. If you include calls to Lift's Comet support, Lift will insert JavaScript on the page to do long polling. But these features are optional and they only happen if you use certain features in Lift.
I hope this helps you understand the benefits of using Lift.
Two more frameworks for you to consider:
Play is a simple REST framework that is gaining in popularity, and has a nice Scala interface. Its templates translate relatively simply into Scala functions. As of a couple months ago there were difficulties with using JSON packages (like lift-json) that unpack data into case classes because Play has a custom classloader for rapid development. Not sure if this issue is resolved. The Scala company Typesafe uses Play for their site. Play integrates with Akka, and one of the Akka lead developers, Viktor Klang, recommended Play a while back.
A little further off the beaten track, there is Spray. I can't speak to the details, but the Wiki looks intriguing. To my eyes, Spray looks to be elegantly designed around Akka integration. I don't think it comes with a templating engine, but it would probably be possible to interface with Scalate (see the mailing list discussion).
Not a Scala framework per-se, but I've had good luck with Jetty+JAX-RS+Scala+Freemarker. These are all pretty heavily battle-tested technologies, and there's no problems with Scala integration. A small shim is necessary to adapt Freemarker to understand Scala collections and properties, but nothing challenging.
Scalatra is pretty bare bones with the scala goodness. Easy to configure, easy to handle Bare HTTP stuff. It is similar to sinatra of scala.
Scalatra also has good Maven support and coexists well with traditional java servlets.
The modern Scala web framework are: Play (on Akka HTTP), Scalatra (Akka Actors) and Finatra.
https://www.reddit.com/r/scala/comments/743zjv/web_framework/
I am looking into something lightweight, that, at a minimum should support the following features:
Support for easy definition of actions through metadata
Wrapper that extracts parameters from request into clojure map, or as function parameters
Support for multiple forms of authentication (basic, form, cookie)
basic authorization based of api method metadata
session object wrapped in clojure map
live coding from REPL (no need to restart server)
automatic serialization of return value to json and xml
have nice (pluggable) url parameter handling (eg /action/par1/par2 instead of /action?par1=val1&par2=val2)
I know it is relatively easy to roll my own micro-framework for each one of these options, but why reinvent the wheel if something like that already exists? Especially if it is:
Active project with rising number of contributors/users
Have at least basic documentation and tutorial online.
First of all, I think that you are unlikely to find a single shrinkwrapped solution to do all this in Clojure (except in the form of a Java library to be used through interop). What is becoming Clojure's standard Web stack comprises a number of libraries which people mix and match in all sorts of ways (since they happily tend to be perfectly compatible).1
Here's a list of some building blocks which you might find useful:
Ring -- Clojure's basic HTTP request handling library; all the other webby libraries (for writing routes &c.) that I know of are compatible with Ring. Ring is being actively developed, has a robust community, is very well-written and has a nice SPEC document detailing its design philosophy. This blog post provides a nice example of how it might be used (reacting to GitHub commits).
Sandbar -- currently an authentication library, more types of functionality planned; under development.
Compojure -- a mature and robust library which provides a nice DSL for writing routes to be used on top of Ring. This will give you the nice URL parameter handling.
Compojure-rest -- "a library for building RESTful applications on top of Compojure". Compojure-rest is, as far as I can tell, in its early stages of development; perhaps you might see this as an opportunity to influence its design. :-)
For dealing with XML, there's clojure.contrib.lazy-xml (and the helper library clojure.contrib.zip-filter.xml) and Enlive (the built-in clojure.xml namespace is currently not very usable); these would be used in tandem (though for your purposes the former might suffice).
For JSON, there a library in contrib and clojure-json (and I think there was at least one other lib I seem to be forgetting now...); pick the one you like best.
All of will be perfectly happy with a REPL-driven development style (see the accepted answer to this SO question for a Ring trick which is very much to the purpose here). I suppose the above collection of links does leave a few blind spots (in particular, the authentication story is still being ironed out, as far as I can tell), but hopefully it's a good start.
1The only single-package solution for building webapps in Clojure that I know of is Conjure, inspired by Rails; unfortunately I have to admit that I don't know much about it, so if you feel interested, follow the link and look around the sources, wiki &c.
While building my first Clojure rest service I found myself asking often the same question. The Clojure Toolbox helped me a lot: http://www.clojure-toolbox.com/
If you are looking for some sample, real-world, illustrative code to get you started, then you could study this clojure-news-feed on github project which demonstrates how to implement a non-trivial RESTful web service with compojure/ring that wraps both SQL (postgresql or mysql) and NoSQL (cassandra), search (solr), caching (redis), event logging (kafka), connection pooling (c3po), and real-time metrics via JMX.
This blog about Building a Scalable News Feed Web Service in Clojure provides a good introduction. I ran some load tests against this service on a humble AWS deployment and got about eighty transactions per second with less than a half second average latency per transaction.
Take a look at liberator library http://clojure-liberator.github.io/liberator/ It's noy a standalone solution, buy very good for rest service definition.
Just to provide an updated answer to this old question, currently (in 2018) I think Luminus provides an excellent starting point. It's using many of the libraries (ring, compojure, etc.) mentioned in previous answers, is modular and as close to "single package" as you can get with Clojure. Specifically for REST, take a look at compojure-api. Luminus recommends buddy for authentication, I've had good success using it both for traditional session-based auth as well as Oauth and stateless JWTs.
By day, I am a front-end web developer but in my off time I dabble with other languages such as C, Objective-C, Python, etc. When I first got into web development the idea of web applications was just getting started.
Since then two amazing frameworks have appeared, SproutIt's SproutCore and 280 North's Cappuccino (+Objective-J). SproutCore is being used by Apple for it's MobileMe application and 280 North released 280 Slides. Both of these applications are amazing and they are a testament to what is possible on the web. So the momentum is shifting. Web applications starting to look and act like desktop applications.
So my question is this: should web based applications follow web standards, separation of markup (content), presentation (design), and behavior (functionality) or no?
I am not sure about SproutCore since I have not look at the source code, but I know that if you go to 280slides.com and turn off the JavaScript everything basically disappears. You are left with some meaningless words.
Let me clarify, I understand that web based applications such as 280 Slides is meant to have JavaScript on and not meant to be functional without it but in my day job my main focus is writing clean markup, separating content, presentation, and behavior so that our site and applications can be used by as many people as possible.
It seems like the other people who have answered so far have no idea what you're talking about.
Like me, you've had it pounded into your head to make your web applications as accessible as possible. That is, they should work without scripting and without stylesheets. JavaScript and CSS should only be used to enhance the experience. They should not be required.
SproutCore and Cappuccino are frameworks for front-end development that require the user to have both JavaScript and CSS enabled. Your question is around how we reconcile this with the dogma of the day.
Unfortunately, I don't have a clear-cut answer. I like the fact that SproutCore and Cappuccino (and probably others) are testing the limits of what's possible within a web browser. I also believe firmly that information and services provided on the web should be available to as many people as possible, given the limitations of the technology.
How you approach your solutions needs to be based on a deep knowledge of your user-base. If you're working on an iPhone app, you don't need to worry about traditional web accessibility because the experience is intensely visual. If you're building a web application for a general audience, these new frameworks are probably a poor choice (if you value the widest possible access to your information and services).
Over time, screen reader software is likely to get better at interpreting JavaScript-heavy interfaces, so perhaps this issue will fade. Thing is, something else is likely to "sprout" up in its place.
Javascript is a Web standard — certainly more so than, say, Flash, which was previously (and still often is) used for rich Web applications. In this regard, SproutCore and Cappuccino are giant improvements in my book.
The question here really seems to be how important accessibility is. And that is largely a personal decision based, as Andrew said, on knowing your users. For some apps, accessibility really doesn't make that much sense — 280 Slides is a good example of this. It's a graphic design app that's largely about visual behaviors. It doesn't make very much sense for it to degrade to plaintext. (At least, a text-based app meant to accomplish what 280 Slides does would be really be a completely different thing.)
Yes. It will be difficult at first, but once the codebase matures you will be thankful you followed those rigorous standards.
Edit: An added benefit will be portability to many web-based platform via CSS profiles and whatnot.
The MVC model can be applied just as easily to desktop applications as it can to web based applications. I don't see much reason to distinguish between the two, especially since the line is more blurred in the case of web applications.
I don't know about these particular frameworks, but a lot of web frameworks these days are structured around the MVC model, such as ASP MVC, CakePHP, Ruby on Rails, etc.
Separate as much as you can and it will pay out in the end. When things get complicated and hairy :)
I think they should. Following that type of MVC design allows for changes to be more easily implemented, provides good separation of concern, and is generally easier to understand for newcomers to a project.
A few years ago I did a lot of work with CGI.pm. I'm evaluating using it again for a quick project. Can someone bring me up to speed on the current state of developing with CGI.pm in the "Web 2.0" world? What are the best libraries on CPAN to use with it? Are there clean ways to include jQuery, YUI, other CSS libs, etc, and do some AJAX. There are of course lots of libraries on CPAN but what works and what is commonly used?
We aren't still doing this?
$JSCRIPT<<EOF;
...
EOF
I realize people are going to offer Catalyst as an answer. However, many people may have legacy CGI.pm apps they simply want to enhance. Is starting over really the best answer?
Personally, I'm no fan of Catalyst (too heavy for my taste) or Mason (mixing code and HTML is bad ju-ju), but I do quite well using CGI.pm for input[1], HTML::Template for output, and CGI::Ajax to provide AJAX functionality where called for.
If you're looking at frameworks, you may also want to consider CGI::Application, which is a widely-used and lighter-weight alternative to Catalyst/Mason.
[1] I can't recall the last time I called anything other than $q->param or $q->cookie from CGI.pm. There are still a lot of tutorials out there saying to use its HTML-generation functions, but that's still mixing code and HTML in a way that's just as bad as using here docs, if not worse.
Consider using something more modern, for example Catalyst. It will make your life much easier and you won't have to reinvent the wheel. I understand that it is just a small project, but from my experience many small projects in time become large ones :)
The "web 2.0" apps that I've worked with usually use client-side JavaScript to request JSON data from the server, then use that data to update the page in-place via DOM.
The JSON module is useful for returning structured data to a browser.
As far as including JavaScript, HTML, or whatever in a here doc - that was never a good idea, and still isn't. Instead, use one of the plethora of template modules to be found on CPAN. For a CGI, I'd avoid "heavy" modules like Mason or Template Toolkit, and use a lighter module for quicker startup, such as Text::Template, or Template::Simple.
Yes, you can write perfect web2.0 web applications WITHOUT using any framework on the server side in any language Perl, Python, Java, etc and WITHOUT using any JavaScript libraries/framework on the client side. The definition of web 2.0 is kind of a loose definition, and I'm guessing by web2.0, you mean Ajax or partial page refresh, then all you would really need is to focus on the following:
Know about the XmlHttpRequest object.
Know how to return JSON object from the server to the client.
Know how to safely evaluate/parse the JSON object using JavaScript and know to manipulate the DOM. Also, at least know about innerHTML. InnerHTML is helpful occasioanally.
Know CSS.
Having said that, it's a lot easier to use some framework on the server side, but not because it's required by web2.0 and it's a lot easier to use some JavaScript on the client like jQuery, mootools, YUI. And you can mix-and-match depends on your needs and your tastes. Most JavaScript provides wrapper around the XmlHttpRequest so that it works across all browsers. No one write "naked" XmlHttpRequest anymore, unless you want to show some samples.
It's perfectly possible to write "Web 2.0" apps using CGI.pm, but you'll have to do the work yourself. From what I've seen, the focus in the Perl development community has been on developing successor frameworks to CGI, not on writing helper modules to let legacy apps get bootstrapped into modern paradigms. So you're somewhat on your own.
As to whether to start over, what are you really trying to accomplish? Everyone's definition of "Web 2.0" is somewhat different.
If you're trying to introduce a few modern features (like AJAX) to a legacy app, then there's no reason you need to start over.
On the other hand if you're trying to write something that truly looks, feels, and works like a modern web app (for example, moving away from the page-load is app-state model), you should probably consider starting from the ground up. Trying to make that much of a transformation happen after the fact is going to be more trouble than it's worth for anything but the most trivial of apps.
I agree with Adam's answer, you probably want to use Catalyst. That being said, if you really don't want to, there's nothing preventing you from using only CGI.pm. The thing is, Catalyst is a collection of packages that do the things you want to make Web 2.0 easy. It combines the various templating engines such as Template Toolkit or Mason with the various ORM interfaces like DBIx::Class and Class::DBI.
Certainly you don't have to use these things to write Web 2.0 apps, it's just a good idea. Part of your question is wondering if javascript and CSS frameworks like jQuery, or prototype require anything from the server-side code. They don't, you can use them with any kind of server-side code you want.
For new apps, if you don't find Catalyst to your taste, Dancer is another lightweight framework you may like. There are also plenty of others, including CGI::Simple, Mojo/Mojolicious, Squatting...
Any of these lightweight frameworks can take care of the boring parts of web programming for you, and let you get on with writing the fun parts the way you want to.
If the jump from CGI.pm to Catalyst seems too daunting then perhaps something like Squatting might be more appropriate?
Squatting is a web microframework and I have found it ideal for quick prototyping and for replacing/upgrading my old CGI scripts.
I have recently built a small "web 2.0" app with Squatting using jQuery with no issues at all. Inside the CPAN distribution there is an example directory which contains some programs using jQuery and AJAX including a very interesting [COMET](http://en.wikipedia.org/wiki/Comet_(programming)) example which makes use of Continuity (which Squatting "squats" on by default).
NB. If required then you can later "squat" your app onto Catalyst with Squatting::On::Catalyst
There is also CGI::Ajax.