No Fluff Just Stuff

This week in #Scala (17/05/2013)

Jan Machacek — Sat, 18 May 2013 08:00:03 CDT

Welcome to another edition of #ThisWeekInScala. My choice chirp this week: @psnively: It’s OK to believe #scala is complex. The problem is believing #java, #csharp, #ruby, #python, #php, #javascript aren’t. …closely followed by: @jessitron: #Scala and F# are like … Read more →

SSL: Another reason not to ignore IPv6, (Fri, May 17th)

Johannes Ullrich — Fri, 17 May 2013 16:00:02 CDT

Currently, many public web sites that allow access via IPv6 do so via proxies. This is seen as ...(more)...

Day 15 of 100 Know You Are Managing Time to Market & How To Do It

Alan Shalloway — Fri, 17 May 2013 13:00:02 CDT

Continuing with the 100 Things You Must Know to Be Effective In Software Development

The purpose of development/IT is to deliver value quickly - not just for a team, but for the entire organization. If you reflect on this, it's not about going fast, it's about removing delays. Delays are typically waiting for folks, getting feedback late, detecting errors late, or just going to work on something else that has come up. Scrum, XP, and Kanban all, in their own way, focus on doing this - eliminating delays. However, instead of listing how these methods do it, let's look at fundamentally at what practice they use to do it. There are (at least) four ways to accomplish this:

remove delays in the workflow by making them visible on a value stream map (Lean)
manage work-in-progress to remove delays in the workflow (Lean, Kanban)
use cross-functional teams that self-organize to remove delays in the workflow (Lean, Scrum, XP)
focus on business value delivery - do what it takes to get the most important thing out the door fastest (Lean, Scrum, XP, Kanban)

These are obviously related, but since one-size does not fit all, if you don't know all of these methods you will certainly not be effective in certain situations.

Let's go through each of these briefly:

Remove delays in the workflow. Sometimes mapping out the workflow is all it takes to get to the root cause of problems. Attending to delays and thrashing at a macro level can lead to insights how to remove them. Acceptance Test-Driven Development is another method to remove delays.

Manage work-in-progress to remove delays in the workflow. Many (most?) delays in workflow are due to working on too many things. If you manage the size and number of things being worked on, the delays you want to eliminate will be reduced significantly.

Use cross-functional teams that self-organize to remove delays in the workflow. Scrum works, when it does, because its core mandate of a cross-functional team provides the structure from which to eliminate delays in workflow. Having all the people you need to get the job done makes it relatively straightforward to eliminate any delays in the workflow. Scrum hits the wall when it is attempted to be used across teams because it provides no viable mechanism to handle cross-team delays.

Focus on business value delivery - do what it takes to get the most important thing out the door fastest. If one focuses on delivering business value, one will do what it takes to:

eliminate delays in the workflow
will focus on the most important work - managing how much work is being done to not lose focus from the most important stuff
will have all the people necessary to get the job done quickly (notice what you do when you have a high priority, severity one issue

These are essential the first 3 items on the list.

The bottom line is don't get hung up on your method - understand why each can work and use them when that practice is most effective.

Want to learn how to do this in your company? Send me a note.

Al Shalloway
CEO, Net Objectives

Take the 100 in 100 Challenge. I'm committing to add one entry each day. I'm asking people to accept the challenge of reading them. If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn

Author:

alshall

e-netprotections.su ?, (Fri, May 17th)

Johannes Ullrich — Fri, 17 May 2013 11:00:12 CDT

Like with .biz, I sometimes have the impression that ...(more)...

ISC StormCast for Friday, May 17th 2013 http://isc.sans.edu/podcastdetail.html?id=3314, (Fri, May 17th)

Johannes Ullrich — Fri, 17 May 2013 08:00:09 CDT

...(more)...

Unfolding brains at FITC Amsterdam

Denise Jacobs — Thu, 16 May 2013 16:00:02 CDT

There are some experiences that are so good that they set the bar for any other experience past or future to try to match or emulate. Facilitating my first full day workshop on creativity at FITC Amsterdam goes on record as being one of the best days of my life. Yes, it was that good. Seriously.

For starters, I was bolstered by the fact that I had been in contact with a few of the attendees beforehand. One woman emailed me in advance to tell me how excited she was about the workshop. Another gentleman flew in to Amsterdam for the day in from Madrid, Spain expressly to take the workshop (he further interviewed me afterwards to get Inside the Creativity), then left soon after it was over to catch his flight back home.

I was further encouraged by the number of attendees: 16, which was more than I thought would be there. Because the workshop focused on more “soft skills”, I figured that at a technical conference it would be the least well-attended out of all the workshops offered. Much to my surprise and delight, it turns out that The Unfolded Brain had the highest number of attendees of the four workshops that day.

There was minor hiccup to the day: my computer’s hard drive completely died at 6am, four hours before the workshop was about to start. However, my new method of preparation not only put me in good stead, but totally saved me. Having used the Post-it Big Pads to organize my ideas and work out the course flow, I was able to use them as my workshop notes with all of the reminders of the content that I wanted to cover, the exercises to do in class, and the practices for the attendees to work on at home.

The attendees were ready, eager to do some work, and eager for the content. In order to get an idea of what people were hoping to get out of the day, I had everyone write some of their goals for the workshop on post-it notes and put them at the front of their desks. Everyone had great ideas, and it was great for me to see them and know that my content was in alignment with what folks were looking to get out of the course.

After that, I intro-ed the content, and dove in with the first exercise. Despite not having any slides and doing the whole day “analog”, the information flowed and everyone delved into the assignments with gusto. Some of the exercises were individual, some required a partner, a few required small groups, and one exercise included everyone in the class at once.

For me, the experience was amazing. I felt very honored to be able to share my process for enhancing and expanding creative productivity. Workshops are truly my element, as it was through teaching a hands-on handmade herbal soapmaking workshop back in 1998 that showed me my gift for teaching and love for sharing practical information. And from the feedback, no slides was no problem:

“Nice job presenting ad-hoc (broken computer)”

“Great work solving the session without your computer.”

“Laptop was broke, so no slides could be shown, but I didnt miss them.”

At the end of the workshop, the students seemed buzzing with positivity and possibility, and many lingered past the end of the course to chat with each other and stay in the zone of the day. The blogger for the conference was one of the workshop participants, and he wrote up a really nice recap of the day for the conference site.

But that only partially explains why the day was so poignant for me. You know those moments when you have a vision of how your life could be better in the future than it is at the moment? Well, doing this work was part of a vision that came to me at the end of February 2010, when it became clear to me that I wanted to help people feel that incredible surge of energy that you get when you’ve created something amazing and have been in “the zone” creatively. This day and this workshop represented the culmination of three years of work in creating this experience, not just for myself, but for the people in the workshop as well. And seeing that I have the power to create something like this was phenomenal.

If you are wondering what happened to my computer, it turns out that had to spend all of the next day at the Apple Store working to get it fixed. But that did not impede on the great feelings that I had from the workshop the day before, which carried me through the rest of the week, right up to the next amazing experience that I had in Frankfurt, Germany the last week of February. That, however, is an entirely separate blog post.

Full disclaimer: This blog post is sponsored by Post-it Brand Big Pads.

ISC StormCast for Thursday, May 16th 2013 http://isc.sans.edu/podcastdetail.html?id=3311, (Thu, May 16th)

Johannes Ullrich — Thu, 16 May 2013 13:00:05 CDT

...(more)...

Day 14 of 100 There is more than customer value

Alan Shalloway — Thu, 16 May 2013 11:00:05 CDT

Continuing with the 100 Things You Must Know to Be Effective In Software Development

While adding value to the customer is the ultimate goal, there is more than customer value. There are actually at least five different types of business value:

knowing what will be of value to the customer
knowing how to build this
building this
deploying this value so it is consumed by the customer
being able to do any of the above faster

All of these are of business value. The last one is valuable to the customer and can provide a unique selling proposition to them. For example, a company may not have the most features, but if they are in a position to add new features faster when requested, they may be more attractive to customers than businesses with lots of features (many likely not used) that can't add new ones quickly enough.

If you are doing Scrum and you realize that the team should be about delivering business value every sprint, many insights present themselves. When one is not able to deliver quickly, one still wants to discover and buidl thin, vertical slices of funcationality quickly. If one is doing Kanban and there is no timebox, the need to deliver business value quickly requires you to slice stories up into smaller chunks. One should not build what one is not sure of.

A customer centric focus is a good thing since it keeps the customer in mind when we are building our software instead of looking at the systems we are building. Software, in itself, is useless. It becomes useful only if it assists the customer. But that does not mean we don't have value in learning how to achieve customer value.

Enjoy, and, of course, ask questions on our user groups.

Al Shalloway
CEO, Net Objectives

Cisco TelePresence Supervisor MSE 8050 Denial of Service Vulnerability, (Thu, May 16th)

Johannes Ullrich — Thu, 16 May 2013 08:00:01 CDT

Cisco TelePresence Supervisor MSE 8050 contains a vulnerability that may allow an unauthentica ...(more)...

Microsoft Security Advisory overview, (Tue, May 14th)

Johannes Ullrich — Wed, 15 May 2013 16:00:01 CDT

Malware Protection Engine

Microsoft released

The Case Against Synchronous Worker APIs

Alex Russell — Wed, 15 May 2013 11:00:09 CDT

Several times in the past few months I’ve been presented with this question: is it good or useful to provide synchronous APIs to web workers?

Having considered the question at some length, it seems to me the answer must now be “no“.

Consider IndexedDB. Despite being un-implemented in any browser, somebody did the arduous work to specify a second synchronous version of its API which is meant to be only available inside of Workers. That’s in addition to the still-available asynchronous API, of course. I came across this while attempting to rework the async IDB API to use Futures, an attempt to fix the hideous usability of the current async API in a backwards-compatible way.

So why not the sync version? At least 2 reasons:

The async version doesn’t have to be as nasty as the current API would lead you to believe. Yes, IDB is hideously deformed: it abuses events for one-time operations and in order to do so creates non-obvious control flow contracts in order to give users time to set up listeners. It makes you dig delivered values out of event objects. It misses obvious API conveniences and makes things implicit that shouldn’t be (transaction closure, etc.).
There’s very little you want to do that is really long running and truly synchronous. Even things that look like they’re a good fit at first blush break down quickly. Just think of the user experience: who wants their laptop fan spinning up, their lap getting warm, and their precious battery indicator slipping towards a powerless coma without being able to either find what is causing it or, better, some UI that communicates what work is being done on their behalf and a way to cancel it if necessary. Getting work off the main thread is what allows apps to do work for users without locking up those UI indicators, but to provide any ability to interrupt the task or broadcast progress, it must yield to the main event loop.

It’s this second concern that I think it truly fatal to the cause of sync worker APIs: assuming they work and are popular, they will create a world in which it’s necessary to put limits on their overall running time…limits that will be circumvented by breaking up the work into smaller chunks and dealing with it asynchronously inside the worker. Likewise, anyone building a serious app that’s trying to do the right thing by the user will factor their worker’s tasks into small enough chunks that they can both service “stop” messages and distribute progress notifications to the UI. There might be scenarios where such messages aren’t necessary and where users aren’t coveting CPUs and batteries…where sending SIGHUP doesn’t matter. But the intersection of those scenarios and the client-side web seems mostly to be a happy accident: your code might not have encountered enough data to create the problems. Yet.

This is particularly clear in the IDB cases: upgrading, iterating over, and updating hundreds of thousands of rows of data is the sort of thing that will take a while, and is likely in response to some application semantic the user cares about: synchronizing mail, migrating to a faster schema layout in the process of some upgrade, etc. All of this might work fine in a dev environment with a (small) staging set of data…but it’s recipe for disaster when power-users with tons of data encounter it. What then? If the APIs an app depends on are all synchronous, it’s a huge boulder to roll up a hill to provide notifications, chunk up work, and refactor around async-ish patterns that chunk work up. If the work was async in the first place, the burden is much lower. So even apps that aren’t Doing It Right (TM) are likely to reap some benefit down the line from thinking in terms of async first.

There are other arguments that you can field against these sorts of APIs, particularly ones that double-up API surface area, but it doesn’t seem to me that they’re necessary. The person attempting to justify synchronous workers to provides a good argument for ergonomics and learnability still has all their work ahead of them: they must show that these APIs are not harmful to the experiences the addition of works Workers to the platform were justified by in the first place. And I fear they cannot do so without violating core JS semantics.

So let’s pour one out for our sync API dreams: we’re gonna miss you, control flow integration. But not for too long. Generators, iterators, and yield will see you avenged.

ISC StormCast for Wednesday, May 15th 2013 http://isc.sans.edu/podcastdetail.html?id=3308, (Wed, May 15th)

Johannes Ullrich — Wed, 15 May 2013 08:00:03 CDT

...(more)...

GlassFish 3.1 Is Now Available

Jason Lee — Tue, 14 May 2013 16:00:04 CDT

Merry Christmas!

“Do not be afraid; for behold, I bring you good news of great joy which will be for all the people; for today in the city of David there has been born for you a Savior, who is Christ the Lord.” — http://www.biblegateway.com/passage/?search=luke%202:1-20&version=NASB[Luke 2:1-20]

Day 13 of 100 Systems Thinking From Individual to Organization

Alan Shalloway — Tue, 14 May 2013 13:00:04 CDT

Hi everyone. To pick the pace back up I'm going to write either shorter blogs or, as in today, I will take some previous work and mold it into this work. I appreciate your patience and will get things going again.

Continuing with the 100 Things You Must Know to Be Effective In Software Development

I blieve that one of the essential components of successful Agile adoption across teams is systems thinking. “Systems thinking” is the process of understanding how things, regarded as systems, influence one another within a whole. In software development, this means looking at: product selection, product prioritization, requirements, architecture, design, code, test, quality assurance, delivery, integration, management, HR, and more. In other words, it means looking at the development workflow as a whole. Optimizing one part of the workflow may have no impact overall and can even be harmful to the whole.

Lean offers a particular way to look at the system: the value stream. The value stream is the flow of work from when an idea is first conceived through implementation, deployment and eventual use or consumption. The time from start to finish is called “cycle time.” Lean thinking says that actions that lower cycle time are usually good and those that lengthen cycle time are probably not. Lean thinking looks for ways to remove delays which results in eliminating unnecessary work. This leads to improved quality and lowers costs.

When multiple teams and products are involved, this holistic approach extends to the entire set of projects being worked on. For example, it may be that delaying one project is worthwhile if another project can deliver more value, more than the cost of delaying the first project. This gives us helpful questions for deciding whether to start a new project: “Will this new project add to the value being delivered?” and “Will adding this project slow down or negatively impact the ability of existing projects to deliver value?”

While systems thinking is essential for scale, it is also useful in the adoption of Agile at the team. Here's a blog from August of last year that discusses how systems thinking can be useful when difficulties in adopting an Agile method arise:

August 31, 2012 — Posted by Al Shalloway

At Net Objectives we’ve trained tens of thousands in Scrum and Kanban. We don’t really play sides in which method we use. Our own experience is that hybrid methods are typically needed in large scale transitions – which is our specialty. Regardless of which method our clients employ, we always suggest a system-thinking approach within the context of Lean-thinking.

Lean-thinking is actually a kind of systems thinking. It suggests that most of the problems that are encountered are due to faults in the system. That we should not blame people for errors, but rather look to see how the system they are in is working.

A variant of this would be to look how a systems thinker would approach the problem of Scrum-but and Kanban-but. As an aside, I want to point out the Kanban community discourages the use of the term Kanban-but since it focuses on the people aspect of not doing Kanban. Systems thinkers would also discourage the use of Scrum-but as a derogatory term for the people not doing Scrum properly. He wouldn’t suggest that people are doing Scrum-but because they aren’t motivated enough, he would ask “why are they not doing Scrum properly?” Is it they don’t understand the benefit of the Scrum practice they are not doing? Is it that it would be too difficult to do it? What is it about Scrum itself that contributes to these challenges?

By focusing on the system, we avoid putting the blame on the people. Now it may be that the people aren’t motivated enough. But as soon as you draw that conclusion, you have lost all power in helping them. It is one reason the Fundamental Attribution Error is so deadly and being aware of it can be so powerful. Regardless of whether the judgment is true, once it has been made there is little that can be done.

Instead of finding what is wrong with someone that is not doing what they are supposed to, systems thinkers look for what the people experiencing challenges are looking at (or not looking at) that has them make poor choices. We assume they are a good, intelligent, motivated person looking at the wrong things and therefore making bad decisions. Not that there is something wrong in their character such as a lack of motivation or persistence or courage.

In software development, the “system” is often the workflow they find themselves in. In other words, if we’re talking about a developer, when do they get the opportunity to talk to customers, to testers? Do they get requirements and the validation for these requirements at the same time via Acceptance Test-Driven Development or not? These are choices often outside of their control.

My suggestion is that if you are using a method that has a common set of challenges, that perhaps one should look at modifying the method to avoid the challenges instead of trying to motivate your people into putting more effort into overcoming them. I’m not suggesting motivation isn’t important – it is. And sometimes working harder and having more courage is the only route to success available. But my experience is that people in this field are very motivated. The question is, how can we best take advantage of that motivation?

For more on systems thinking, I highly recommend The Systems Bible by John Gall.

Android Panel and Kiosk Apps

James Harmon — Tue, 14 May 2013 11:00:07 CDT

One advantage of doing business in the Chicago area is getting to see lots of manufacturers. The Midwest still builds stuff.

As an Android developer who gets to talk with many of the local companies I've recently noticed a pattern in the Android space that I wanted to share.

High end tools and machines often contain some kind of display that describes the status of the tool or provides a way to configure or operate the tool. And by "tools and machines" I'm covering a huge variety of products.

Look at the control panel for the new LifeFitness exercise machines below.

It is pretty clear that this could be done using an Android device (and I believe it is).

I call this kind of application a "Panel" app.

What 6 qualities differentiate this from a typical app.

Fixed in place (built into the machine or tool)

Custom user interface (doesn't follow the Android UI guidelines)

Other apps are unavailable or hidden (the user can't run their own apps)

Targeted to a very small set of devices (only runs on the tablet built into the machine)

Users engage with it frequently and over a long period of time (so they can learn custom interface)

interface with underlying machine or tool

The other similar, but slightly different, kind of device runs a single purpose app also. I call it a "Koisk" app.

The 4 characteristics of a Kiosk app

Public (think shopping mall)

Wider audience (user has brief use of it, so must be easy to use which means that it should work like apps the user is familiar with) follow design guidelines

Fixed in place (mounted on a wall)

Locked down (can only run target app)

These apps never appear in the marketplace but are great opportunities for Android developers. Keep them in mind when you search for your next consulting gig.

ISC StormCast for Tuesday, May 14th 2013 http://isc.sans.edu/podcastdetail.html?id=3305, (Tue, May 14th)

Johannes Ullrich — Tue, 14 May 2013 08:00:02 CDT

...(more)...

Central Ohio Software Symposium - Jun 7 - 9, 2013

Mon, 13 May 2013 15:00:00 CDT

No Fluff Just Stuff is pleased to announce the Central Ohio Software Symposium, Jun 7 - 9, 2013.

Catch these Featured Sessions

Introduction to Virtual Machines and Interpreters
by Douglas Hawkins

Have you ever wondered what goes on inside the virtual machines and interpreters that we use every day? In this session, you'll see some of the inner workings of Python, PHP, Java, and JavaScript and learn that at the lowest level these languages really are not as different as they may seem.

Android Fundamentals
by Kenneth Kousen

The basics of developing for the Android platform will be explored, from setting up your development environment to using the SDK to working with activities, intents, and fragments. No previous experience is required, other than a basic knowledge of Java.

Turtles, Architecture, & Agility
by Kirk Knoernschild

A little old lady once challenged a well-known scientist’s explanation on the structure of the universe, countering that the world is really a flat plate supported on the back of a giant tortoise. The scientist rebutted the little old lady’s challenge with one of his own by asking what the tortoise was standing on. The little old lady’s sly reply was that it’s, “turtles all the way down.” So too is software architecture “turtles all the way down”.

Securing Single Page Apps and REST Services

James Ward — Mon, 13 May 2013 13:00:05 CDT

The move towards Single Page Apps and RESTful services open the doors to a much better way of securing web applications. Traditional web applications use browser cookies to identify a user when a request is made to the server. This approach is fundamentally flawed and causes many applications to be vulnerable to Cross-Site Request Forgery (CSRF) attacks. When used correctly, RESTful services can avoid this vulnerability altogether. Before we go into the solution, lets recap the problem.

HTTP is a stateless protocol. Make a request and get a response. Make another request and get another response. There is no correlation (i.e. “state”) between these requests. This poses a problem when you need to identify a user to the system because one request logs the user in and another request needs to tell the server who is making the request.

Web browsers have an automatic way to store some information (i.e. “state”) on the user’s machine and then add that information to every request. This is called “cookies” and they provide a convenient way to create a correlation across HTTP requests. Most web frameworks have a built-in concept called “session state” which uses a unique token for each user. That token is stored in a cookie and automatically sent to the server on each request. Now the server knows how to identify a user across requests.

This approach is simple and works great until you realize the dark truth of CSRF. Usually a user is doing something that tells the browser to make a request to server and because the cookies are sent, everything is good. But suppose the user gets an email that says “Check out these funny kittens!” with a link to a malicious website. No one can avoid seeing funny kittens, so the user clicks the link. It turns out that the funny kittens website is a malicious website which now makes some requests to an application that only uses cookies for authentication. Perhaps the malicious request is to transfer money out of your bank account. Or perhaps it posts something on a social network. These requests will be identified AS THE USER because no matter what causes the request, the browser will send the cookies. This is CSRF and many web apps are vulnerable to it.

The root of the problem is using cookies as the sole method of identifying a user since no matter how the request is initiated, the cookies which include the authentication token are always sent to the server. One way to protect against this type of attack is to force each request to contain another token which is not automatically sent. Most web frameworks provide a way to do this but they are error prone because it often requires developers to explicitly enable it and the approach doesn’t always work well with Single Page Apps.

The Way Forward

The easiest way to do authentication without risking CSRF vulnerabilities is to simply avoid using cookies to identify the user. However each request must still send a token to the server to identify the user. This requires a token to be somehow “remembered” so that each request can manually send it. Luckily Single Page Apps provide a way to keep a token in memory across requests because the page never reloads.

But what if the page does reload and the authentication token is lost because that in-memory state has been cleared? Does the user have to log back in to get a new authentication token? That would not be a very good user experience. Browsers have a few ways to store data locally across requests. The easiest is to simply use cookies. Wait… aren’t cookies the root of the problem? Cookies themselves are not the cause of CSRF vulnerabilities. It’s using the cookies on the server to validate a user that is the cause of CSRF. Just putting an authentication token into a cookie doesn’t mean it must be used as the mechanism to identify the user.

When a Single Page App loads it can read the cookies (via JavaScript), grab the authentication token, and then manually send that token on each request through a custom HTTP header. This is safe because that malicious funny kitten site does not have access to the cookies. If it did, every website would have a severe security issue.

The flow with this approach may go something like this:

The user navigates in their browser to the application
The server returns a basic web page and a JavaScript application
The JavaScript application can’t find an authentication token in the web site’s cookies
The JavaScript application displays a login form
The user enters correct login credentials and then submits the form
The server validates the login information and creates an authentication token for the user
The server sets the authentication token in a cookie and returns it to the JavaScript application
The JavaScript application makes a request for some protected data, sending the authentication token in a custom header
The server validates the token and then returns the data

At step 3 if the JavaScript application does find an authentication token in a cookie then it can skip ahead to step 8.

At step 9 the server may not be able to validate the token in which case it should return a 401 (Unauthorized) response which the JavaScript application can handle by going to step 4.

There are a variety of ways to implement this approach but the real key is that the server doesn’t validate a user based on a cookie, it instead validates the user with a customer HTTP header.

This approach can be used over HTTP or HTTPS. But it is highly recommended that authentication tokens are only passed over encrypted connections which means you should probably only be using this approach over HTTPS connections. Whenever an application is not being used for local development it should automatically redirect HTTP connections to the corresponding HTTPS connection. In this setup make sure that the cookie containing the authentication token can’t be inadvertently transmitted over the HTTP connection by forcing the cookie to only be sent over HTTPS (an option which is typically available in cookie APIs).

Sample App

To better explain this approach lets walk through an example application. You can get the full source for the application from: http://github.com/jamesward/play-rest-security

This application is built using Play Framework, Java, jQuery, and CoffeeScript.

To run the application locally, download Play 2.1.1, extract the zip and optionally add the extracted directory to your system’s path. Then using a command line, navigate into the play-rest-security directory and run the following (assuming the play command is in your path):

play run

This will start the application which you can connect to in your browser at: http://localhost:9000/

You should see a login form which you can test out and once logged in, you will see the protected data and can add new data.

There are also a number of functional and unit tests for the application which validate the security of the application. You can run the tests locally by running:

play test

RESTful JSON Back-End Services

Starting with User.java you will see this is a typical database-backed entity using JPA. The User class has a property authToken which will store a single authentication token. In a real-world application you will probably want to allow a user to be logged in from multiple clients (e.g. different browsers). To enable this you could simply turn this into a list. You may also want to have some tracking on when authentication tokens are used, what IP address used them, and when they were created. The tokens could also be encrypted in the database.

The Todo.java file contains the Todo entity which stores a user’s Todos. Access to the Todo objects happen via the TodoController.java class. In this case the TodoController only has two methods, getAllTodos() and createTodo(). These methods are exposed via HTTP through the routes file. The TodoController has the @With(SecurityController.class) annotation which setups up a request interceptor so that every request made to the controller must go through the call method in the SecurityController.java class.

The call method in the SecurityController tries to find an authentication token in a custom HTTP header. If it finds a token then it tries to find a user with that token. If found the user is added to the HTTP Context (a place to store data for the duration of the request) and then the original controller method is called. Otherwise a 401 response is returned.

Both getAllTodos() and createTodo() in the TodoController use the authenticated user that was stored in the HTTP Context to either fetch the user’s todos or create a new todo.

The SecurityController class also has login and logout request handlers which are mapped to URLs in the routes file. The login method tries to locate a user by the provided username and password. If it succeeds then it creates a new authentication token for the user, then creates a cookie containing the token, and returns the token in a JSON response. The logout method uses the SecurityController interceptor to validate the user and then deletes the cookie that stores the authentication token and set’s the user’s authToken to null.

That is the RESTful back-end of the example app. Now lets explore the front-end.

CoffeeScript + jQuery Front-End UI

In the routes file you will see that requests to / are handled by returning public/index.html. This file doesn’t do much other than load jQuery and also load the index.min.js file which is compiled and minified by Play’s asset compiler. The source for that file is index.coffee and it provides the whole UI for the application. This example uses CoffeeScript because it provides a more concise and readable syntax for writing JavaScript applications.

When the page is ready the init function is called and the application attempts to find the authentication token in a cookie. If it can’t be found then a login form is displayed. If the cookie can be found then the displayTodos function is called. This function tries to fetch the user’s list of Todo objects and then display them. The request to fetch the Todo objects is a normal Ajax JSON request except that the user’s authentication token is sent in a custom HTTP header. If the server responds with a 401 error then the application calls displayLoginForm otherwise the user’s Todo objects are displayed. The createTodo function also sends the authentication token in custom HTTP header and the JSON data for the Todo within an Ajax request.

That is really all there is to the front-end UI. Most of the code in the CoffeeScript is displaying data and forms in the HTML through jQuery DOM manipulation. This DOM manipulation could also be done through one of the many client-side templating libraries.

Further Learning

The important point to remember is that using cookies for authentication opens up the possibility of CSRF attacks. Custom HTTP headers provide a more secure method of identifying users than cookies alone do. The combination of Single Page Apps and REST services provide the perfect opportunity to move away from cookie based authentication. This simple application illustrates how to implement this approach.

Learn more:

Individuals and Interactions With Gil Broza

Johanna Rothman — Mon, 13 May 2013 11:00:03 CDT

My friend and colleague, Gil Broza, is interviewing me for his Individuals and Interactions virtual training event. My topic? “Focus Keeps You Going.”

If you read my personal kanban series a couple of weeks ago, you saw how my focus kept me going. Even with a big interruption last week, due to a death in the family, I was able to maintain my focus, because I knew exactly what I had to do, to finish my work, to get ready for my trip today.

Gil has other great people in his event: Doc List, Ellen Gottesdiener, Mary Gorman, David Spann, Christopher Avery and Bob Schatz might be names you recognize. How about Rick Ross? David Spann? Caren DesBrisay? You might not recognize these names, and you should listen to what they have to say, too.

Check out Gil’s Individuals and Interactions training. Sign up. It’s a steal.