There's been a lot of talk about NanoWeb (a good article and some blog entries) and it's a nice little project. However, there's one thing that will stop a lot of people using it. Well, perhaps only for big systems and in fact this isn't really just related to NanoWeb because I've seen a few web applications built on custom MVC frameworks that suffer the same problem.
Although most MVC frameworks need to be configured with the mappings between action names and their corresponding implementation classes, one of the benefits is that you explicitly control access to these actions from the outside world. With Struts, you might map login.do to a class called LoginAction. Although it's slightly more work in development, this explicit mapping limits what users can call via their browser. Unfortunately the world has gone XML crazy, but these config files don't have to be XML, as illustrated here.
With dynamic configuration/dispatch, the code users can access via their web browser isn't explicitly limited. Essentially, because of the naming convention, it's possible to call any method on any arbitrary class (or Groovy script in this case) that has been deployed in the right place. This is also the case when you dynamically map from URLs like /actions/LoginAction to LoginAction.class, so it's a wider problem than just NanoWeb.
Of course, for many apps this just isn't a problem. However, if you're going to deploy to the Internet then I'd be wary, particularly if the app is open source. So how do you solve this? Well, to keep in the spirit of simplicity, perhaps you could annotate callable methods with a Java annotation (e.g. @web, @action or something) and have the build process build the mapping to allow dispatch to occur. There's probably a good compromise between security and ease of development yet to be found.
Previous Topic
