NOTE: Just released version 0.2.2 of ngImprovedTesting to fix issue #6 causing chained promises (i.e. .then(...).then(...)) not to executed by a $q.tick(); also see README of the GitHub repo.

After quite a while I finally got round to creating version 0.2 of ngImprovedTesting. The ModuleBuilder API is unchanged and still makes mock testing AngularJS code much easier (be sure to read this blog post if you are unfamiliar with ngImprovedTesting). Version 0.2 of ngImprovedTesting brings you the following interesting improvements:

Continue reading →

As you may already know web components consist out of a set of technologies which are combined to create a custom element for use in your HTML markup. The main additions, as described in several blogposts, are HTML imports, Shadow Dom and Templates combined with isolated scripts and styling. (If these concepts are new to you i suggest you read up on web components at WebComponents.org). This blog post has a living example on plnkr.co. If we look at Angular it already supports html imports and isolated scripts through it's directive approach. This means we can already create custom components by using directives. The downside of this approach however is that there is no true isolation of markup and styling. Meaning both markup and styling may be inadvertently influenced by an outside source. Let's start with a basic directive and template:

angular.module('shadow.app', ['component.api'])
.directive('simpleDirective', function() {
    return {
      restrict: 'E',
      replace: false,
      templateUrl: 'template.html',
      transclude: true,
      scope: {
        dynamic: '='
      },
      link: function($scope, element) {
        // your code here
      }
    };
  })

Continue reading →

This second part of the Stateless Spring Security series is about exploring means of authentication in a stateless way. If you missed the first part about CSRF you can find it here. So when talking about Authentication, its all about having the client identify itself to the server in a verifiable manner. Typically this start with the server providing the client with a challenge, like a request to fill in a username / password. Today I want to focus on what happens after passing such initial (manual) challenge and how to deal with automatic re-authentication of futher HTTP requests.

The most common approach we probably all know is to use a server generated secret token (Session key) in the form of a JSESSIONID cookie. Initial setup for this is near nothing these days perhaps making you forget you have a choice to make here in the first place. Even without further using this "Session key" to store any other state "in the session", the key itself is in fact state as well.  I.e. without a shared and persistent storage of these keys, no successful authentication will survive a server reboot or requests being load balanced to another server.

Continue reading →

Today with a RESTful architecture becoming more and more standard it might be worthwhile to spend some time rethinking your current security approaches. Within this small series of blog posts we'll explore a few relatively new ways of solving web related security issues in a Stateless way. This first entry is about protecting your website against Cross-Site Request Forgery (CSRF).

CSRF attacks are based on lingering authentication cookies. After being logged in or otherwise identified as a unique visitor on a site, that site is likely to leave a cookie within the browser. Without explicitly logging out or otherwise removing this cookie, it is likely to remain valid for some time. Another site can abuse this by having the browser make (Cross-Site) requests to the site under attack. For example including some Javascript to make a POST to "http://siteunderattack.com/changepassword?pw=hacked" will have the browser make that request, attaching any (authentication) cookies still active for that domain to the request! Even though the Single-Origin Policy (SOP) does not allow the malicious site read access to any part of the response. As probably clear from the example above, the harm is already be done if the requested URL triggers any side-effects (state changes) in the background.

Continue reading →

NOTE: Just released version 0.3 of ngImprovedTesting with lots of bug fixes.
Check out this blog post or the README of the GitHub repo for more info.

Being able to easily test your application is one of the most powerful features that AngularJS offers. All the services, controllers, filters even directives you develop can be fully (unit) tested. However the learning curve for writing (proper) unit tests tends to be quite steep. This is mainly because AngularJS doesn't really offer any high level API's to ease the unit testing. Instead you are forced to use the same (low level) services that AngularJS uses internally. That means you have to gain in dept knowledge about the internals of $controller, when to $digest and how to use $provide in order to mock these services. Especially mocking out a dependency of controller, filter or another service is too cumbersome. This blog will show how you would normally create mocks in AngularJS, why its troublesome and finally introduces the new ngImprovedTesting library that makes mock testing much easier.

Continue reading →

This year we attended Devoxx 2013 with a total of 9 JDriven colleagues. After more than a week we finally recovered from a vast amount of great sessions, personal encounters and  'some' Belgian beer. Looking back at Devoxx we had a great conference and like to thank the Devoxx team for making this possible. It was also good to notice that the majority of the sessions are related to subjects that drive us at JDriven, during our daily job and while further developing our expertise and craftsmanship, to name a few: Continuous Delivery, AngularJS, RESTful API's, Gradle, Groovy, Grails, Java 8, Java EE.

The Devoxx 2013 sessions will be available at Parleys soon, hopefully just before the holidays. To protect you from infobesity we'd like to share our list of must watch sessions with you:

Continue reading →

NOTE: This blog post is originally written for AngularJS 1.2.x; in 1.3.x the "input not showing invalid model values" has been fixed.
Although 1.3.x still has the "inconsistencies in how AngularJS parses data entry" the solution from this blog post isn't working for 1.3.x but I will try to find a fix for this within the next few weeks.

A while ago I noticed that AngularJS doesn't show invalid model values bound to an <input/> There is also an open bug report about this: issue #1412 - input not showing invalid model values The bug can be easily illustrated through the following example:

Continue reading →

NOTE: this post was written for Karma 0.8 which required a manual installation of PhantomJS.
However this blog post is still relevant for installing the NodeJS and NPM pre-requisites.
As of 0.10 both PhantomJS and Chrome will be automatically installed by the launcher plugins.
Installation instructions for Karma 0.10 can be found here (a "Local installation" is preferred).
Furthermore instructions on how to install plugins (introduced as of 0.10) can be found here.

Recently I decided to switch from the “Jasmine Maven Plugin” (using the Mozilla Rhino JavaScript “emulator”) to the Karma (previously called Testacular) test runner. The big advantage of Karma opposed to the “Jasmine Maven Plugin” is that it uses actual browsers (like Chrome, Firefox, Safari and even IE) to execute the tests. This blogpost describes the installation and configuration of Karma on Windows. To install Karma you first need to install NodeJS and its NPM (NodeJS Package Manager). Additionally you could install PhantomJS, a “headless” web-kit browser, to run your JavaScript tests from the command-line without spawning unwanted browser windows. Instead of using PhantomJS as a replacement for testing against real browsers you could use it to run tests on your local development machine while your continuous integration server could then run your tests on “all” relevant browsers.

Continue reading →

When experimenting with AngularJS features I often create a so-called Plunk on http://plnkr.co/. Although this site provides built-in templates for AngularJS, I found it useful to create my own since:

• The “1.0.x (stable)” / “1.0.2 + Jasmine” templates use old versions of AngularJS;
• “1.0.2 + Jasmine” template solely outputs Jasmine results but no AngularJS content.

Continue reading →

Next to creating controllers and directives, AngularJS also supports “singleton” services. Services, like on the server-side, offer a great way for separating logic from your controllers. In AngularJS anything that’s either a primitive type, function or object can be a service. Although the concept of service is quite straight forward, the declaration of them in AngularJS isn’t:

• There are 4 different ways to declare a service.
  • Registering a existing value as a service
  • Registering a factory function to create the singleton service instance
  • Registering a constructor function to create the singleton service instance
  • Registering a service factory which can be configured
• Only 1 of them is extensively documented

Continue reading →

Having a history as a Java developer I prefer declaring the complete JavaScript object at once through an object literal; in a similar fashion as your would declare a class in Java. In my opinion adding new properties "on the fly" to a JavaScript object is a very bad practice:

var jsLibrary = { name: 'AngularJS' };
// adds a new property "homepage" to the existing object...
jsLibrary.homepage = 'http://www.angularjs.org/';

Continue reading →

AngularJS is an excellent JavaScript web framework offering so-called "directives" to 'teach' HTML some new tricks. Examples of built-in AngularJS directives are:

• "ngView": defines the placeholder for rending views
• "ngModel": binds scope properties to "input", "select" and "text" elements
• "ngShow" / "ngDisabled": for showing or disabling an element based on the result of an expressions

Continue reading →