Grasping AngularJS 1.5 directive bindings by learning from Angular 2

In AngularJS 1.5 we can use attribute binding to allow easy use of input-only, output-only and two-way attributes for a directive or component.

Instead of manually parsing, watching and modifying attribute values through code, we can simply specify an attribute binding by adding a property to the object hash of:

In this blog post we will learn how attribute bindings differ between AngularJS 1.5 and Angular 2 and what we can learn from Angular 2 to make your HTML and JavaScript in Angular 1.5 more descriptive.
Continue reading

Using `$q.defer()` in AngularJS? Try the $q ‘constructor’ instead.

Although I’m a great fan of using the ($q) Promise API in AngularJS, I never really liked using $q.defer() and its Deferred API. I always found using var deferred = $q.defer() together with $.resolve(..) and $.reject(..) to be too verbose.

After recently checking the $q service documentation I stumbled upon the $q constructor that results in way less verbose code.

To illustrate the usage of the $q constructor I will create a function that wraps the result of a Geolocation#getCurrentPosition invocation as an AngularJS $q promise.

Using the traditional $q.defer() approach the function wrapper will look like this.

When using the $q constructor, I could rewrite the code as follows, resulting in less verbose code:

And since in this case we are merely passing through the arguments of the success and error callbacks, I could rewrite the code to be even smaller:

As you can see, using the $q constructor produces code with less boilerplate, making it more readable in the process.

Notice that although it’s being called the “$q constructor” we are not actually doing a new on $q.
Possibly, the AngularJS team calls it this way because it mimics the ECMAScript 2015 Promise constructor API.

Next to the $q constructor there are some other alternatives to using the verbose $q.defer().
In most cases you can probably use a less verbose alternative as is nicely described in this blog post that I stumbled upon while doing some additional research for my own blog post.

Unit testing an AngularJS directive’s private functions.

As we all know Javascript gives us the awesome ability to create functions inside functions. This allows us to create private functions which support the main function. It is also something we do often when creating object functions. This structure is used by angular for the creation of providers and directives alike.

Every once in a while I personally come to a point where I would like to test these private functions. This is especially true for use cases in Angular such as directives. Continue reading

Communication between Angular Controller and Directive

Since I had issues finding a good explanation on how to tie together a controller and a directive with isolated scope I decided to create my own blog post on this subject. This repo contains a runnable example of the solution. It contains a Spring Boot Web Application that can be started to act as a HTTP server but all the interesting stuff is in the src/main/webapp folder.

Problem description

To create modular code with AngularJS you want to create reusable components; directives. Directives should not depend in any way on the parent controller. They should not be able to see any of the parent scope unless it’s explicitly provided to them. To do this Angular directives can have an isolated scope (which in my opinion should be the default). Continue reading

ngImprovedTesting 0.3: improved ModuleBuilder with lots of bug fixes

NOTE: ngImprovedTesting is AngularJS library to make mock testing AngularJS code more easy.
For more information about ngImprovedTesting be sure to read its (updated) introductory blog post.

Just released version 0.3 ngImprovedTesting with a much improved ModuleBuilder.

Prior to 0.3 usage of ngImprovedTesting might be troublesome due to fact that the ModuleBuilder:
Continue reading

Stateless Spring Security Part 3: JWT + Social Authentication

This third and final part in my Stateless Spring Security series is about mixing previous post about JWT token based authentication with spring-social-security. This post directly builds upon it and focusses mostly on the changed parts. The idea is to substitude the username/password based login with “Login with Facebook” functionality based on OAuth 2, but still use the same token based authentication after that.

Login flow

Client-side

The user clicks on the “Login with Facebook” button which is a simple link to “/auth/facebook”, the SocialAuthenticationFilter notices the lack of additional query parameters and triggers a redirect leading the user of your site to Facebook. They login with their username/password and are redirected back, again to “/auth/facebook” but this time with “?code=…&state=…” parameters specified. (If the user previously logged in at facebook and had a cookie set, facebook will even instantly redirect back and no facebook screen is shown at all to the user.) The fun part is that you can follow this in a browsers network log as it’s all done using plain HTTP 302 redirects. (The “Location” header in the HTTP response is used to tell the browser where to go next)

Continue reading

ngImprovedTesting 0.2: adding $q.tick() to improve testing promises

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:

  • ngModuleIntrospector no longer uses internal AngularJS API.
  • mocks can now also be created manually using the (global) “mockInstance” function.
  • features a more descriptive way of testing promises by adding the tick() method to $q.
  • offers an module called “ngImprovedTesting” to be able to use $q.tick() in your tests without having to use the ModuleBuilder API (which automatically includes the module).

Continue reading

Web-components like AngularJS directives

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.

Continue reading

Stateless Spring Security Part 2: Stateless Authentication

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.

Common approaches

Session Cookie based

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

Stateless Spring Security Part 1: Stateless CSRF protection

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).

Recap: What is Cross-Site Request Forgery?

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!

Continue reading