A View Back, and Looking Forward

It’s been both challenging and rewarding publishing these Supply Chain Technology postings on a semi-regular basis, and it is difficult to believe it has already been several months since we started this endeavor.

Our traffic picked up substantially when one of our GTN-MVC posts was picked up by a GWT news aggregator, and our GWT posts remain among the most popular we’ve written.

Scientific Security

While dealing primarily with “real-world” — as opposed to software — security issues, this paper (PDF) outlines some suggestions for improving security by applying scientific principles, including those used to avoid reporting bias and issues with self-reporting.

We’ve recently gone through an upgrade of our security process, and we’ve found that when looking over all potential security issues it can be surprising to find that the issues we thought were very important to address — the issues du jour — don’t always stack up well against less interesting but more potentially severe (or pervasive) issues.

Links:

• Reference to the paper on Bruce Schneier’s Security Blog
• The paper:  “A Call for Evidence-Based Security Tools“  (PDF)

Why GWT?

I’ve recently finished up a series of internal presentations focusing on learning GWT.  We have selected GWT for our UI toolkit and are building our own framework on top of it, using as many mature third party libraries as we can.  We have also already deployed products which use the Google Web Toolkit.

During the presentations one of the most common questions — if not THE most common question — was “Why GWT?”.  I will assume for the moment that it wasn’t just our JavaScript gurus asking the question

Keeping XSS at Bay, Ninja-Style

Perhaps the most commonly discussed web application security issue is Cross-Site Scripting, or XSS.  (While the ‘X’ makes it sound cool, it’s also there to prevent confusion over Cascading Style Sheets, the original CSS.)

The Security Ninja site is doing an overview of various aspects of the OWASP ESAPI toolkit, and the latest post is on output validation — the area of validation and encoding that pertains to preventing XSS attacks.

They take a simple, easy to follow walkthrough approach to common issues in application security while illuminating features of the ESAPI library.

Links:

Security Ninja Post: http://www.securityninja.co.uk/output-validation-using-the-owasp-esapi

OWASP Enterprise Security API (ESAPI): http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

You’re Doing WHAT?

I’m currently in the process of visiting our offices outside the US, which is always a fun, and often intense, thing to do.  Not just for the perk — the company is paying to fly me across the ocean!* — but also because it facilitates communication that just won’t happen otherwise.

One surprise I’ve had during the trip is an introduction to a number of tools that we might want to use across the organization which I had not heard of until I visited our other offices.  Here is a field (tools) that I try to keep up with, and I think I’m mostly aware of… but in fact there are so many tools, large and small, open source, free, and commercial, that unless it’s your full time job to track these things it’s likely that you simply won’t hear about  most of them.

As much as I’d like to see more blogging about such tools internally, or wiki pages describing their use, the fact is that even the best knowledge management system is no replacement for being face to face with someone, getting to know them personally and perhaps knocking out a few details which may (pleasantly, one would hope) surprise you.

 

*Followed not too long after by “…oh, I’m going to have to fly across the ocean.”

Rolling Your Own GWT Remote Logging

In my previous post I suggested a few GWT logging packages that could help you keep track of client activity.  The other option, should those packages not work for you, is to roll your own.

Here is a very basic layout for rolling your own, a scheme we’ve used until integrating the gwt-log package into our application.

First off, this uses standard GWT-RPC for communication with the server.  If for some reason the client can’t communicate with the server, there’s no way to tell the server what’s going on.  While you could try to do something with Gears or HTML 5 client side persistence to queue the log entries headed to the server until a connection was available, that contingency is not covered here.

Keeping Track of GWT Client-Side Activity

Moving a web 1.0-style application to a web 2.0 model — by which I mean one that is Ajax-driven and interaction code is primarily found on the browser (perhaps this is web 3.0?) — can be a daunting challenge.  GWT undoubtedly makes the process of creating a solid client-side application in Javascript easier, but the move to the browser brings some other, less obvious, challenges.

One of those challenges is logging.  In the JSP world it was straightforward to add logging wherever you needed it; if you wanted to know what was happening during the processing of your servlets, it was easy to do:  instantiate your logger and call the appropriate logging methods.  Now much of the interaction happens on the browser and the only interaction you have with it is through RPC calls.  You can log those on the server, but if any issues come up on the client, or you want to know why the RPC call happened in the first place, you suddenly run into one of the difficulties of the new browser-centric world.

Luckily there have been a few projects that aim to bridge the logging gap.  There are several GWT projects that can provide remote logging, and it is also possible to roll your own if necessary.

Watching Application Security Mature Around Us

Despite the goofy name, Security Ninja in the UK — the site’s subtitle is “Security News, Research & Guidance” — has some good resources for application security, and is a solid contribution to the discussion around application security that’s been growing over the last few years.  The primary contributor to the Security Ninja site is a security analyst working with an application called Realex Payments.

At the Security Ninja site they’ve developed 8 secure development principles which include:

Server Restarts, the Great Time Waster

I’ve previously mentioned that a great deal of time spent on development can be attributed to the time taken up waiting for your server/EJB/JEE container to start up.  Now the good folks at ZeroTurnaround have put numbers to the delay.

Using a survey which included over 1,000 developers, they uncovered some interesting statistics, and I encourage you to read their post on the subject for details.

Among the more interesting statistics that even the most un-techie folks can appreciate is this one, which charts how many WEEKS per year is lost to developers waiting for server restarts:

Google Wave does for XMPP what Google Maps did for Ajax

Ever since I attended Google IO 2009 (see my recap here), I’ve had a feeling that Google Wave was a Big Thing.   There’s an elegance in the technology that I immediately saw had implications for vendors providing wikis, forums, blogs and the like, but probably had some implications for supply chain portals as well.

During the last few months I’ve told anyone that would listen to check out the Google Wave demonstration from Google IO so they could understand why it was worth following closely.  The typical reaction I get is “interesting,” with a hint of “not crucially important,”  – not surprising given that it isn’t clear what it has to do with our line of business.

Recently a gentleman named Jason Kolb has made promotion of Wave easier with his passionate post on Google Wave that highlights the technology and its potential.  He points out that the Wave protocol is an extension of an existing, accepted protocol – XMPP.   So — no nothing new here, right?  Wrong.