Being passionate about AngularJS, me and two fellow JDriven colleagues visited the ngEurope conference. The amount of presentations during ngEurope was somewhat overwhelming, especially during the mornings without any scheduled break. Good thing I made some notes, that the slides are already available on-line and that someone published quite detailed notes for all sessions. Without all this I might simply have forgotten about some very interesting and relevant details. During ngEurope there was a all lot of attention for the just released 1.3 version of AngularJS and the coming 2.0 release.
Archive: October 2014
Since version 2.3, Grails supports asynchronous parallel programming to support modern multiple core hardware. Therefore a new Grails command is added to generate asynchronous controllers for domain classes. The generated controller contains CRUD actions for a given domain class. In the example below, we will generate a default asynchronous implementation of a Grails controller. First we create a domain object:
Gradle uses the name
build.gradle as the default name for a build file. If we write our build code in a file
build.gradle then we don't have to specify the build filename when we run tasks. We can create build files with a different name other than
build.gradle. For example we can define our build logic in a file
sample.gradle. To run the tasks from this build file we can use the command line option
--build-file followed by the file name. But we can also change the project settings and set a new default build file name for our project. With the changed project settings we do not have to use the command line options
Since version 2.3 Grails has excellent support for creating REST APIs. This new support comes with some new console commands. Besides the well known
generate-controller command, Grails now comes with a new command which let you generate restful controllers for a given domain class. In the following example, we will create a restful controller using the new
generate-restful-controller command. First we create a domain object
When we write Groovy code there is a big chance we also write some closures. If we are working with collections for example and use the
find methods we use closures as arguments for these methods. We can assign closures to variables and use the variable name to reference to closure. But we can also create a subclass of the
Closure class to implement a closure. Then we use an instance of the new closure class wherever a closure can be used.
If we write a specification for a specific class we can indicate that class with the
@Subject annotation. This annotation is only for informational purposes, but can help in making sure we understand which class we are writing the specifications for. The annotation can either be used at class level or field level. If we use the annotation at class level we must specify the class or classes under test as argument for the annotation. If we apply the annotation to a field, the type of the field is used as the class under test. The field can be part of the class definition, but we can also apply the
@Subject annotation to fields inside a feature method.
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.
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).