But sometimes you need that kind of access, for example when developing an HTML based mobile app that retrieves dynamic content from a web server. In that scenario the web pages are run locally in the mobile device (smartphone or tablet) and they make requests and posts to your remote web server, which is by default not allowed.
Almost all of the web apps we build nowadays (at least on the circles I usually move around) rely on the beloved and hated session. This artifact, providing a stateful user wide storage, allows us to relate several HTTP requests together and thus implement the concept of authenticated and secure web applications, that “know” who is using them several requests after they authenticated, despite the root stateless characteristic of the HTTP protocol itself.
To provide a very brief recap, sessions are usually implemented using a hash like memory structure on the server, where each session is stored using a unique identifier string. This string is stored also on the users web browser, typically via a cookie or by sending it back and forth on each request as a POST or GET parameter.
I believe it’s time to move away from this approach and start building session-less web applications that still provide the same feature set and security.
Up until today I was convinced that developing with a Java IDE under Linux was synonym of looking all day at a really ugly and disturbing set of widgets thrown on my screen by a 6 year old. But after upgrading my Netbeans installation to 7.2 I decided to do another Google search about it and voila…
This is a part of my web frameworks review series. Check it out if you haven’t already.
Moving on to Django, the Python based all star.
Django was created by the folks at the Lawrence Journal-World and released to the public in 2005. It’s very active and with a strong group of followers, the framework is currently in it’s 1.4 incarnation, and the last release was done in March/2012.
We have an internal Maven repo/mirror in my company, we use it to host the releases of our internal apps and libraries, as well as to mirror all the external packages we use (this speeds up build times, new environments set-ups and reduces bandwidth use).
Our internal repository requires authentication to both read/download packages and to publish new releases.
Play 2.0 provides built-in support for Maven repositories, and it’s quite straightforward to add new ones, but how to configure and use an authenticated one wasn’t documented (at least as far as I could see on the official Play website).
Unless you have been living under a bucket without an RJ45 port (yes, some buckets have Internet access), you have probably heard of Ruby on Rails (RoR), it’s a very popular framework with lots of momentum. RoR started as an extract of the Basecamp product at 37signals and is now used in all sorts of web apps.
A friend recently recommended I take a look at the Mustache templating engine. It’s clean, simple and designer friendly, and promotes logic minimization on the template side (I don’t like the term “logic-less”, I don’t think you can get away with absolutely zero logic).
To try it out I decided to build a simple Struts 2 based web app, but I found that there was no out-of-the-box integration between the two. Thankfully both frameworks are easily extendable so I managed to get them playing along quite easily.
The tutorial and reference documentation used for this article is all available from the Play documentation site.
The first part of the article will go over the set of tasks we proposed to do with each framework, then moving on to evaluate each criteria item.
At my company we are evaluating which web development framework we will use for the next few years.
But we think it’s time to re-evaluate and move on to a newer/better/friendlier framework.
In this post I’ll present you with our candidates and the criteria we are evaluating each framework with. Over the next weeks I’ll post the actual evaluation of each framework and finally what our choice is and why.
Cross-site request forgery attacks (CSRF) are very common in web applications and can cause significant harm if allowed. If you have never heard of CSRF I recommend you check out OWASPs page about it.
Luckily preventing CSRF attacks is quite simple, I’ll try to show you how they work and how we can defend from them in the least obtrusive way possible in Java based web apps.