deepu-sasidharan

Deepu is a polyglot developer, Java Champion, and OSS aficionado. He mainly works with Java, JS, Rust, and Golang. He co-leads JHipster and created the JDL Studio and KDash. He's a Principal Developer Advocate at Okta. He is also an international speaker and a published author.

Principal Developer Advocate

Deepu K Sasidharan

Discover why standard prompt injection is evolving into a greater threat with AI browsers. Learn about indirect injection risks and how to secure your LLM applications.


Hiding Prompts in Plain Sight: A New AI Security Risk

We know not to trust user input, but what about AI output? Learn how improper output handling leads to XSS, SQL injection, and RCE, and how to prevent it.

Trusting AI Output? Why Improper Output Handling is the New XSS

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Andrea Chiarelli

Learn what Dependency Injection and IoC are and what .NET Core provides you to support them.

Understanding Dependency Injection in .NET Core

matthew-casperson

Technology enthusiast since my first C64. I love writing about new ideas and working with great people.

Product Manager at Octopus Deploy

Matthew Casperson

Learn how to implement common dependency injection scenarios with Koin and Kotlin

Inversion of Control (IoC) is a broad term to describe how responsibility for some aspect of a system is lifted out of the custom code written by the end developer and into a framework. [Martin Fowler describes a framework in terms of IoC](https://martinfowler.com/bliki/InversionOfControl.html):

> Inversion of Control is a key part of what makes a framework different from a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built-in. In order to use it, you need to insert your behavior into various places in the framework, either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

Dependency injection (DI) is one specific example of IoC where classes no longer directly instantiate member properties by creating new objects but instead declare their dependencies and allow an external system, in this case, a dependency injection framework to satisfy those dependencies.

[Koin](https://insert-koin.io/) is a dependency injection framework for Kotlin. It is lightweight, can be used in Android applications, is implemented via a concise DSL, and takes advantage of Kotlin features like delegate properties rather than relying on annotations. 

In this post, we'll look at a simple application taking advantage of Koin to inject dependencies into our custom classes.

## Prerequisites

To build the sample application, you'll need to have JDK 11 or above, which is available from many sources, including [OpenJDK](https://openjdk.java.net/install/), [AdoptOpenJDK](https://adoptopenjdk.net/), [Azul](https://www.azul.com/downloads/), or [Oracle](https://www.oracle.com/au/java/technologies/javase-jdk11-downloads.html).

The code for the sample Koin application can be found [here](https://github.com/mcasperson/KotlinKoinExample).

## The Gradle Project Definition

We start with the Gradle build file, which includes dependencies for Kotlin and Koin, and makes use of the [shadow plugin](https://github.com/johnrengelman/shadow) to create self-contained uberjars:

```groovy
buildscript {
    repositories {
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }
    dependencies {
        classpath 'com.github.jengelman.gradle.plugins:shadow:6.1.0'
    }
}

plugins {
    id "org.jetbrains.kotlin.jvm" version "1.5.21"
}

apply plugin: 'kotlin'
apply plugin: 'com.github.johnrengelman.shadow'

repositories {
    mavenLocal()
    mavenCentral()
}

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:1.5.21"
    implementation "io.insert-koin:koin-core:3.1.2"
}
```

To build the uberjar, run this command from Bash or PowerShell:

```bash
./gradlew shadowJar
```

## Registering Singletons

The first demonstration of Koin will register a class as a singleton, ensuring each time we request a new instance of the class, we are returned a single, shared object. Here is the code from the file `single.kt`:

```kotlin
// src/main/kotlin/com/matthewcasperson/single.kt

package com.matthewcasperson

import org.koin.core.context.GlobalContext.startKoin
import org.koin.dsl.module

class SingleInstance {
    companion object {
        var count: Int = 0
    }

    init {
        ++count
    }

    fun hello() = "I am instance number $count"
}

fun main() {
    val singleModule = module {
        single { SingleInstance() }
    }

    var app = startKoin {
        modules(singleModule)
    }

    println(app.koin.get<SingleInstance>().hello())
    println(app.koin.get<SingleInstance>().hello())
    println(app.koin.get<SingleInstance>().hello())
}
```

This class is run with the command:

```bash
java -cp ./build/libs/KotlinKoinExample-all.jar com.matthewcasperson.SingleKt
```

We start by defining a typical class, but with a companion object containing a variable called `count`. The `count` variable is incremented by 1 each time we create a new `SingleInstance` object, which we will use to track how many new `SingleInstance` objects have been created:

```kotlin
class SingleInstance {
    companion object {
        var count: Int = 0
    }

    init {
        ++count
    }

    fun hello() = "I am instance number $count"
}
```

Inside the `main` function we create a [Koin module](https://insert-koin.io/docs/reference/koin-core/modules/). Modules are used to group related Koin definitions, and here we use the `single` definition to instruct Koin to create a single instance of the supplied object:

```kotlin
fun main() {
    val singleModule = module {
        single { SingleInstance() }
    }
```

Next we call the `startKoin` function, which is part of the `GlobalContext` object. `GlobalContext` is a singleton (defined as an [object declaration](https://kotlinlang.org/docs/object-declarations.html#object-declarations-overview)), and is typically used as the default context for applications. Here we register our module into the global context:

```kotlin
    var app = startKoin {
        modules(singleModule)
    }
```

We're now able to request instances of any of our registered objects with `app.koin.get`. To demonstrate that our `single` definitions are working as expected, we get an instance of the `SingleInstance` class three times and print the message containing the instance count to the console: 

```kotlin
    println(app.koin.get<SingleInstance>().hello())
    println(app.koin.get<SingleInstance>().hello())
    println(app.koin.get<SingleInstance>().hello())
}
```

The output shows we have been given the same `SingleInstance` object each time:

```bash
I am instance number 1
I am instance number 1
I am instance number 1
```

## Registering a Factory

There are times when you want a new instance each time you request a dependency from Koin. To support this, Koin has a `factory` definition. This is demonstrated in the file `factory.kt`:

```kotlin
// src/main/kotlin/com/matthewcasperson/factory.kt

package com.matthewcasperson

import org.koin.core.context.GlobalContext.startKoin
import org.koin.dsl.module

class FactoryInstance {
    companion object {
        var count: Int = 0
    }

    init {
        ++count
    }

    fun hello() = "I am instance number $count"
}

fun main() {
    val factoryModule = module {
        factory { FactoryInstance() }
    }

    var app = startKoin {
        modules(factoryModule)
    }

    println(app.koin.get<FactoryInstance>().hello())
    println(app.koin.get<FactoryInstance>().hello())
    println(app.koin.get<FactoryInstance>().hello())
}
```

This class is run with the command:

```bash
java -cp ./build/libs/KotlinKoinExample-all.jar com.matthewcasperson.FactoryKt
```

This code is almost a line for line copy of the previous example, with some different class and variable names. The most significant difference is how the module is built, where we use the `factory` definition:

```kotlin
    val factoryModule = module {
        factory { FactoryInstance() }
    }
```

Whereas the `single` definition registered a singleton dependency, the `factory` definition calls the supplied lambda every time a dependency is requested.

This is reflected in the console output, which shows that we have indeed constructed three instances, one for each call to `app.koin.get`:

```bash
I am instance number 1
I am instance number 2
I am instance number 3
```

## Registering Interfaces

The previous two examples registered concrete classes with Koin, but good object-oriented practice is to work with interfaces rather than classes. The example below from the file `interfaces.kt` shows how to register a class via its base interface with Koin:

```kotlin
// src/main/kotlin/com/matthewcasperson/interfaces.kt

package com.matthewcasperson

import org.koin.core.context.GlobalContext.startKoin
import org.koin.dsl.module

interface HelloService {
    fun hello(): String
}

class HelloServiceImpl : HelloService {
    override fun hello() = "Hello!"
}

fun main() {
    val helloService = module {
        single { HelloServiceImpl() as HelloService }
    }

    var app = startKoin {
        modules(helloService)
    }

    println(app.koin.get<HelloService>().hello())
}
```

This class is run with the command:

```bash
java -cp ./build/libs/KotlinKoinExample-all.jar com.matthewcasperson.InterfacesKt
```

We start with a basic interface:

```kotlin
interface HelloService {
    fun hello(): String
}
```

We then implement the interface in a class:

```kotlin
class HelloServiceImpl : HelloService {
    override fun hello() = "Hello!"
}
```

To make the class available to Koin via its interface, we cast the new object back to the interface with the `as` operator while building the module:

```kotlin
    val helloService = module {
        single { HelloServiceImpl() as HelloService }
    }
```

We then retrieve a dependency from its interface:

```kotlin
    println(app.koin.get<HelloService>().hello())
```

## Resolving Nested Dependencies

All the previous examples have resolved objects with no additional dependencies. A more typical scenario is where Koin is used to resolve classes that themselves have additional dependencies. This is demonstrated in the file called `nested.kt`:

```kotlin
// src/main/kotlin/com/matthewcasperson/nested.kt

package com.matthewcasperson

import org.koin.core.context.GlobalContext.startKoin
import org.koin.dsl.module

data class HelloMessageData(val message : String = "Hello from wrapped class!")

interface HelloServiceWrapper {
    fun hello(): String
}

class HelloServiceWrapperImpl(private val helloMessageData:HelloMessageData) : HelloServiceWrapper {
    override fun hello() = helloMessageData.message
}

fun main() {
    val helloService = module {
        single { HelloMessageData() }
        single { HelloServiceWrapperImpl(get()) as HelloServiceWrapper }
    }

    var app = startKoin {
        modules(helloService)
    }

    println(app.koin.get<HelloServiceWrapper>().hello())
}
```

This class is run with the command:

```bash
java -cp ./build/libs/KotlinKoinExample-all.jar com.matthewcasperson.NestedKt
```

We start with a data class defining a string property:

```kotlin
data class HelloMessageData(val message : String = "Hello from wrapped class!")
```

As with the previous example, we define an interface and then implement the interface with a class. This time, however, the class has a constructor that takes an instance of `HelloMessageData`:

```kotlin
interface HelloServiceWrapper {
    fun hello(): String
}

class HelloServiceWrapperImpl(private val helloMessageData:HelloMessageData) : HelloServiceWrapper {
    override fun hello() = helloMessageData.message
}
```

When defining the module, we register an instance of the `HelloMessageData` class, and then resolve that class in the `HelloServiceWrapperImpl` constructor with a call to `get`, which will return the appropriate dependency for us. Note the order is not important here, and `HelloServiceWrapperImpl` could have been defined in the module first:

```kotlin
    val helloService = module {
        single { HelloMessageData() }
        single { HelloServiceWrapperImpl(get()) as HelloServiceWrapper }
    }
```

## Creating a KoinComponent

We noted earlier that Koin creates a default global context that our dependencies are registered with. Koin uses this global context, in conjunction with Kotlin [delegated properties](https://kotlinlang.org/docs/delegated-properties.html), through the `KoinComponent` interface to allow classes to resolve their own dependencies without an explicit reference to the `KoinApplication` returned by `startKoin`. An example of this is shown in the file `koinComponent.kt`:

```kotlin
// src/main/kotlin/com/matthewcasperson/koinComponent.kt

package com.matthewcasperson

import org.koin.core.component.KoinComponent
import org.koin.core.component.inject
import org.koin.core.context.GlobalContext.startKoin
import org.koin.dsl.module

data class GoodbyeMessageData(val message : String = "Goodbye!")

interface GoodbyeService {
    fun goodbye(): String
}

class GoodbyeServiceImpl(private val goodbyeMessageData: GoodbyeMessageData) : GoodbyeService {
    override fun goodbye() = "GoodbyeServiceImpl says: ${goodbyeMessageData.message}"
}

class GoodbyeApplication : KoinComponent {
    val goodbyeService by inject<GoodbyeService>()
    fun sayGoodbye() = println(goodbyeService.goodbye())
}

fun main() {
    val goodbyeModule = module {
        single { GoodbyeMessageData() }
        single { GoodbyeServiceImpl(get()) as GoodbyeService }
    }

    startKoin {
        modules(goodbyeModule)
    }

    GoodbyeApplication().sayGoodbye()
}
```

This class is run with the command:

```bash
java -cp ./build/libs/KotlinKoinExample-all.jar com.matthewcasperson.KoinComponentKt
```

This example draws from the features demonstrated in previous sections to define a class called `GoodbyeServiceImpl`, with a nested dependency on the data class called `GoodbyeMessageData`, and which implements an interface called `GoodbyeService`:

```kotlin
data class GoodbyeMessageData(val message : String = "Goodbye!")

interface GoodbyeService {
    fun goodbye(): String
}

class GoodbyeServiceImpl(private val goodbyeMessageData: GoodbyeMessageData) : GoodbyeService {
    override fun goodbye() = "GoodbyeServiceImpl says: ${goodbyeMessageData.message}"
}
```

We then define a class called `GoodbyeApplication` implementing the `KoinComponent` interface. This class has a delegate property called `goodbyService` initialized by the `inject` function made available through the `KoinComponent` interface:

```kotlin
class GoodbyeApplication : KoinComponent {
    val goodbyeService by inject<GoodbyeService>()
    fun sayGoodbye() = println(goodbyeService.goodbye())
}
```

The module is defined in much the same way as it has been in previous examples. Note however that the `GoodbyeApplication` class is not defined in the module:

```kotlin
    val goodbyeModule = module {
        single { GoodbyeMessageData() }
        single { GoodbyeServiceImpl(get()) as GoodbyeService }
    }
```

In this example, we don't assign the result of the `startKoin` function to any variable; registering the module with the global context is enough here:

```kotlin
    startKoin {
        modules(goodbyeModule)
    }
```

We then create a new instance of the `GoodbyeApplication` class and call its `sayGoodbye` function. By implementing the `KoinComponent` interface, the `GoodbyeApplication` class can resolve its own dependencies from the global context and will resolve its `GoodbyeService` dependency in order to print a message to the console:

```kotlin
    GoodbyeApplication().sayGoodbye()
```

The `KoinComponent` interface is convenient, but be aware that it means your classes are now dependant on the Koin framework. Constructor-based injection is recommended when you wish to share code without any explicit dependency on Koin. 

## Conclusion

Koin is a lightweight dependency injection framework with a concise DSL taking advantage of Kotlin's modern syntax and features. In this post, we looked at how Koin creates singletons and factories, registers dependencies against their interfaces, and allows classes to resolve their own dependencies with delegated properties.

Dependency Injection with Kotlin and Koin

marcin_hoppe

Marcin is a software engineer with deep expertise in information security. He leads the Product Security team at Auth0 by day and contributes to the security of the Node.js ecosystem by night.

Senior Manager, Product Security

Marcin Hoppe

Attackers can use Node.js apps to hack into your systems. Learn how to stop them.



When Node.js was first released, it was a revolution. It allowed developers to run JavaScript, the primary programming language of the browser, on the server-side. Over time it grew in popularity to become a go-to tool for building Web applications and APIs.

Node.js consists of a small and stable core runtime and a set of built-in modules providing basic building blocks such as access to the filesystem, TCP/IP networking, HTTP protocol, cryptographic algorithms, parsing command line parameters, and many others. The built-in modules are robust, well tested, and performant.

Unfortunately, they do not cover all the needs of Web application developers. Sometimes we need to use programs outside of Node.js to implement the functionality we are working on.

## Extending Node.js Modules With CLIs

One of the built-in Node.js modules is `child_process`. It allows JavaScript code to run other programs and communicate with them using standard input/output (I/O) mechanisms provided by the underlying operating system. Such programs can often be started interactively by the users using the command-line interface (CLI for short). This is why we sometimes refer to such programs as CLIs.

Modern operating systems like Linux have many utility programs that implement functionality not included in the set of modules built-in Node.js. Using the `child_process` module to start an external program to implement specific functionality is a simple and effective way of extending the Node.js standard library.

### Retrieving git history

Let's take a look at how we might implement a simple Node.js program that prints the history of changes of a file from git. We will use the Express framework to handle the HTTP request and response handling for us. Node.js has no built-in support for running git commands, so we will have to run the git command ourselves to retrieve the data we need. To do that, we need to use the `exec` function from the `child_process` module:

``` javascript  
const exec = require('child_process').exec;

app.get('/history', (req, res) => {
  // Read file name from the URL query string.
  const file = req.query.file;

  // Prepare command to run
  const command = `git log --oneline ${file}`;

  // Execute the external program and send the response back
  exec(command, (err, output) => {
    // Respond with HTTP 500 if there was an error
    if (err) {
      res.status(500).send(err);
      return;
    }

    // If the program ran successfully, send the output in
    // the HTTP response
    res.send(output);
  });
});

```

We can now send an HTTP request to the program to read the file history using the `curl` program, another popular CLI:

``` bash  
$ curl http://localhost:3000/history?file=app.js
```

The program will print out an abbreviated history of changes:

``` bash  
f38482b Call git log command
5444afb Initial commit
```

Looks like our short program is running fine. We needed just a few lines of code to implement a pretty complex operation.

## Invoking Commands

Our program is simple and flexible. We can pass a path to any file on the server running our program, and if this file is under version control using git, we will get its history. Can we always trust the users to provide harmless input?

### Untrusted data in parameters

Our applications, especially the Internet-facing ones, are exposed to users with a variety of motivations and different levels of technical skills. Some users may try to abuse the functionality of our application for their own purposes. Some will do it for fun and learning, some for fame, and some will do it for money.

It is a recommended programming practice to treat all input coming from users as untrusted unless proven otherwise. In Web applications, attackers may use all available components of the HTTP request to try to force our application to do something it was not designed to do. Possible attack vectors are the HTTP request body, the headers (including cookies), and query string parameters.

The effects of a successful abuse of such a modified input parameter may range from disclosing sensitive information, through denial of service, all the way up to complete server takeover. If you are suspecting that our application may allow a user with malicious intent to abuse the `file` parameter, you are absolutely right.

### Invoking malicious commands

Our program prepares the full command to be executed by using JavaScript template literal:
``` javascript  
const command = `git log --oneline ${file}`;
```

If the provided `file` parameter value is `app.js`, the executed command is:
``` bash  
$ git log --oneline app.js
```

The attacker might provide a value that _changes the structure of the executed command_. Let's see what happens if the value of the `file` parameter is `app.js; ls`:

``` bash  
$ git log --oneline app.js;ls
```

Our program executes the git log command and then executes the `ls` command. The output sent to the user in the HTTP response is the combined output of **both commands**:

``` bash  
f38482b Call git log command
5444afb Initial commit
app.js
bin
node_modules
package-lock.json
package.json
public
routes
views
```

This type of security vulnerability is called **command injection**. Can we cause even more damage using such an attack technique? Let's try to obtain the source code of our application:

``` bash  
$ curl http://localhost:3000/history\?file\=app.js\;cat%20app.js
```

The result contains not only the history of the `app.js` file but also its entire content as printed to the standard output by the `cat app.js` command.

We can use the same approach to exfiltrate the content of any file on the server that the application has access to, including configuration files. Attackers can also read the values of environment variables via the `env` command.

This will be very useful for many types of malicious actors, but there is more they can do.

## A Realistic Attack

Technically sophisticated attackers seek to gain control not only over the application but over the entire server. This allows them to gain persistent access to the compromised machine.

### Minimalist shell

Many server operating systems have a utility program called `nc` (or `netcat`). If the attacker has the ability to run this program using a command injection vulnerability, they can execute arbitrary commands on the compromised server. The simplest way to do it is to force the vulnerable application to run the following command:

``` bash  
$ nc -l 6667 | /bin/bash
```

This command starts to listen for incoming connections on port 6667 (chosen by the attacker) and passes all the incoming data directly to the `bash` shell for execution. The port can bear. Let's see if this is possible to do with our vulnerability git history program:

``` bash  
$ curl http://localhost:3000/history?file=app.js;nc%20-l%206667%20|/bin/bash
```

Now the attacker can send arbitrary commands to the compromised server:

``` bash  
$ echo 'killall node' | nc localhost 6667
```

In this particular case, the attacker also used the `nc` program to send the `killall node` command to the `bash` shell setup by the attacker. The effect is a denial of service attack that terminates all the Node.js processes on the server.

### Privilege escalation and lateral movement

Having the ability to run arbitrary commands on the server is a really attractive target for the attacker. In a typical attack scenario, compromising a server in this way is just the first step attackers take. The next step is to install malicious software that persists on the attacked machine and allow attackers to communicate with it over a longer period of time, ideally even after the compromised Node.js application has been restarted.

Ideally, our Node.js applications run with a minimal set of privileges. Command injection attacks allow attackers to run a reconnaissance of the infrastructure and steal administrative credentials or look for other vulnerabilities and misconfigurations that will allow them to escalate their privileges to allow attackers to further spread through the compromised network.

Having access to one compromised server allows the attackers to move to other hosts on the network, a process known as lateral movement. This allows the attacker to compromise more hosts on the network, gather more credentials, and look for other interesting targets and data to exfiltrate from our infrastructure.

If undetected, such attacks can go on for weeks or even months, leading to serious data breaches. How do we harden our Node.js applications from command injection vulnerabilities to prevent malicious actors from exploiting them?

## Preventing Command Injection

There are several techniques that can prevent or at least greatly minimize the chance of command injection vulnerabilities sneaking into our code.

### Do not execute arbitrary commands

The `exec` function from the `child_process` module that we used passes the commands it received in the first parameter directly to the shell to execute. This is very flexible but leads to vulnerabilities we have just seen.

A better option is to use the `execFile` function from the same module that starts a specific program and takes an array of arguments:

``` javascript  
**const execFile = require('child_process').execFile;**

app.get('/history', (req, res) => {
  // Read file name from the URL query string.
  const file = req.query.file;

  // Prepare command to run
  const command = `/usr/local/bin/git`;
  const args = ["log", "--oneline", file];

  // Execute the external program and send the response back
  execFile(command, args, (err, output) => {
    // Respond with HTTP 500 if there was an error
    if (err) {
      res.status(500).send(err);
      return;
    }

    // If the program ran successfully, send the output in
    // the HTTP response
    res.send(output);
  });
});
```

This way, our application is resilient to command injection attacks:

``` bash  
$ curl http://localhost:3000/history\?file\=app.js\;ls
```

Raises the expected error on the server-side:

``` javascript  
{"killed":false,"code":128,"signal":null,"cmd":"/usr/local/bin/git log --oneline app.js;ls"}
```

What to do in cases where we need the flexibility afforded by the `exec` function? Are those cases a completely lost cause?

### Input validation or output sanitization?

Ideally both!

The root cause of command injection attacks is that when we manually assemble the command to be executed, some special characters (metacharacters) might change the structure of the command, and what we think of as data is going to be executed by the shell. The most commonly used metacharacters are:

``` bash  

& ; ` ' \ " | * ? ~ < > ^ ( ) [ ] { } $ \n \r 

```

The best way to ensure such characters are not abused by attackers is to perform strict validation of untrusted input data. Input validation can verify things such as origin, size, or lexical structure of the data. Make sure you narrow down the set of acceptable values as much as possible.

In cases where input data may contain metacharacters, preventing command injection attacks requires proper escaping of those characters before passing them to the shell for execution. Doing so yourself is extremely difficult, and it is best to use a trusted and well-tested library. One such library is shell-quote, which can be installed using the npm package manager and used to format the entire command:

``` javascript  
const quote = require('shell-quote').quote;

// ...

// Prepare command to run
const command = quote(["git", "log", "--oneline", file]);

// Execute the external program and send the response back
exec(command, (err, output) => {
```

It looks like a simple fix, but shell metacharacter encoding is a difficult problem, and latent bugs can be found even in established libraries.

## Summary

If your Node.js application is extending the functionality provided by the built-in set of modules by calling external programs, you are at risk of introducing command injection vulnerabilities. Such vulnerabilities allow attackers to abuse our applications and move laterally throughout our infrastructure.

If this sounds scary, you are right! This is a serious risk.

The good news is that we have several defensive coding techniques to help us build libraries and applications that are immune to command injection attacks. Using `execFile` helps prevent arbitrary shell commands from being executed and is the recommended defense. Input validation and proper encoding of shell metacharacters are also valuable protective measures.

<include src="asides/AboutAuth0" />


Preventing Command Injection Attacks in Node.js Apps

5e074956ee8ba1fea26e30d28c190495?s=300 avatar

5e074956ee8ba1fea26e30d28c190495?s=300

Full stack developer creating content at Auth0. I love taking a deep dive into hard-to-understand concepts and creating content that makes them easier to grasp. In my free time you can usually find me reading, hanging out with my dogs, or curling in the squat rack.

Former Developer Content Manager

Holly Guevara

Learn how to prevent common vulnerabilities such as XSS, injection, and third-party vulnerabilities

Developer's Guide to Common Vulnerabilities and How to Prevent Them

9d2e715baab928f5bedb837bfcb70b2b

Guest Author

Gabor Soos

Learn how to test services in Angular. We will start with setting up the environment and finish with using Dependency Injection.



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-664"></i>
  <strong>Get the "Migrating an Angular 1 App to Angular 2 book" for Free.</strong> Spread the word and <a href="https://auth0.com/e-books/migrating-to-angular2">download it now!</a>
</div>

When I started developing and writing tests for Angularjs applications,
everything felt natural. The tools were mature and I easily got used to
developing applications in TDD ([Test-Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)).
It gave me a high level of confidence, knowing that my application was working as I had imagined.
Just after Angular 2 came out and I learned the basics, I knew that the next step was to testing.

This article is the first part of a series in which
I share my experiences testing different building blocks of an Angular application.
We will start with simple use cases and then head for more complex ones.

- Services (this article)
- [Http Services](https://auth0.com/blog/angular-testing-in-depth-http-services/)
- [Components](https://auth0.com/blog/angular-testing-in-depth-components/)
- Pipes
- Routing

You may wonder why it is so important to write tests.

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/tdd_guilty.png" alt="Angular Testing Driven Development"/>
</p>

With tests, we can ensure the correctness of our application: that the code does what it was designed to do.
We can guard against someone breaking our code by refactoring or
adding new features. This might have happened to you when someone added a small feature
or equivalent code transformations and nothing worked afterwards.
Writing tests can clarify the intention of the code by giving usage examples.
It can also reveal design flaws. When a piece of code is hard to test,
there might be a problem with the underlying architecture.

If you are new to Test-Driven Development, I would recommend reading the Test-Driven Development book by Kent Beck.
It gives a nice overview about the concepts and best practices.

### Choosing the framework to test Angular

<p align="center">
  <img src="https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/jasmine-mocha.png" alt="Angular Testing Framework"/>
</p>

The first thing we have to choose is the framework. The one suggested by Angular's core team is
[Jasmine](http://jasmine.github.io/edge/introduction.html).
For a long time it was the only supported testing framework, because test setups were hard wired into the framework.
Thanks to refactoring, now tests can also be written in [Mocha](https://mochajs.org/), or any other framework
that supports the ```beforeEach``` hook. This hook runs before every test run.
If your framework of choice doesn't support it, you have to add the following code snippet to your setup:

```typescript
import { resetFakeAsyncZone, TestBed } from '@angular/core/testing';

beforeEveryTestHook(() => {
  TestBed.resetTestingModule();
  resetFakeAsyncZone();
});
```

The first line within the hook resets the internal state of the Dependency Injection container.
It clears out any given provider or module.
If you are not familiar with Dependency Injection, I would recommend reading the
[official documentation](https://angular.io/docs/ts/latest/guide/dependency-injection.html) about it.

The second one clears out any remaining zone that fakes asynchronous operations like ```setTimeout```.
Detailed articles can be found on the Thoughtram blog about zones:
[Understanding zones](http://blog.thoughtram.io/angular/2016/01/22/understanding-zones.html) and
[Zones in Angular](http://blog.thoughtram.io/angular/2016/02/01/zones-in-angular-2.html).

For this series, we will be using Jasmine as the test framework.

### Writing the first Angular test

Let's look at our first service that will be tested.

```typescript
import { Injectable } from '@angular/core';

@Injectable()
export class Engine {
  getHorsepower() {
    return 150;
  }

  getName() {
    return 'Basic engine';
  }
}
```

It has two getter methods and the ```Injectable``` decorator.
The tests will check whether these getter methods work as intended.
The decorator is needed to utilize dependency injection.

In Jasmine, we can group our tests with the ```describe``` method.
Within this method, we can create test cases with the ```it``` function.
It is advised to place one class per file (the service) and group the tests around it (with ```describe```).
We can further group test cases around methods of the class
by placing ```describe``` statements inside the top ```describe``` block.
For now we will only group our tests around the class.

```typescript
import { Engine } from './engine.service';

describe('Engine', () => {
  it('should return it\'s horsepower', () => {
    let subject = new Engine();

    expect(subject.getHorsepower()).toEqual(150);
  });
});
```

In this setup, only plain instantiation is used; we will introduce dependency injection later.
For basic services, plain instantiation can be enough.

We call the ```getHorsepower``` method of the engine and check that it's equal to the expected value.

The first test is green and has been passed. Let's write another one for the ```getName``` method.

```typescript
it('should return it\'s horsepower', () => {
  let subject = new Engine();

  expect(subject.getName()).toEqual('Basic engine');
});
```

If you run the tests, a similar output will be on the terminal.

![Angular First Tests](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/first_test_run.png)

Both tests have been passed; it is time to refactor.
There is duplication at the start of each Angular test. Instantiation is exactly the same,
we can move it out into a setup block.

```typescript
describe('Engine', () => {
  let subject: Engine;

  beforeEach(() => {
    subject = new Engine();
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getHorsepower()).toEqual(150);
  });

  it('should return it\'s horsepower', () => {
    expect(subject.getName()).toEqual('Basic engine');
  });
});
```

The ```subject``` variable is declared at the start of the ```describe``` block, and the creation of the service
is moved to the ```beforeEach``` block. This way we don't have to do it manually every time.
It is common to move the creation of the test case subject to a separate method,
because it offloads the tests and makes them more readable.

### Using Dependency Injection

Creating services directly can be good if the subject under test has no or few, dependencies.
But if it has multiple dependencies, or a deeper dependency tree, setting up all the classes becomes tedious.
For these situations, we can use Angular's dependency injection management.

The ```Car``` class uses the ```Engine``` class in the constructor and its instance in the ```getName``` method.

```typescript
import { Injectable } from '@angular/core';
import { Engine } from './engine.service';

@Injectable()
export class Car {
  constructor(private engine: Engine) {}

  getName() {
    return `Car with ${this.engine.getName()}(${this.engine.getHorsepower()} HP)`;
  }
}
```

We check for the ```getName``` method's output in the test after we set up the dependency injection container.

```typescript
import { TestBed, inject } from '@angular/core/testing';
import { Engine } from './engine.service';
import { Car } from './car.service';

describe('Car', () => {
  let subject: Car;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [Engine, Car]
    });
  });

  beforeEach(inject([Car], (car: Car) => {
    subject = car;
  }));

  it('should display name with engine', () => {
    expect(subject.getName()).toEqual('Car with Basic engine(150 HP)');
  });
});
```

The difference here is that we configure the ```TestBed``` with the provided
services in the ```configureTestingModule``` method.
Only these classes can be instantiated with the ```inject``` method.
If we try to request something else, we get an error saying it is an unknown provider.

![Angular Testing Error](https://github.com/blacksonic/articles/raw/master/img/angular2-testing-services/test_failure_missing_dep.png)

We can request instances of the services in an array from the ```inject``` method.
In the callback, we get the instances in the same order as in the dependency array with the first parameter.
The type hint inside the  callback is only for IDE completion; it also works without it.
In the example, it is placed inside the ```beforeEach``` function, but it can also be added to the ```it``` block.

```typescript
it('should display name with engine', inject([Car], (car: Car) => {
  expect(car.getName()).toEqual('Car with Basic engine(150 HP)');
}));
```

### Mocking

In unit tests for Angular, we want to execute the code in isolation.
This means it is not dependent on big, complex objects and is not calling methods that rely on external systems
(like [HTTP calls](https://auth0.com/blog/angular-2-series-part-3-using-http/) or database access).
In these cases, we want to simulate the original behavior while skipping the underlying implementation.

When achieved, it is called mocking.
We don't have to do it manually. Jasmine provides tools to make it work.
Let's assume that the method of the ```Engine``` class has a call through to the server
and we want to mock it.

```typescript
...
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [Engine, Car]
  });

  spyOn(Engine.prototype, 'getHorsepower').and.returnValue(400);
  spyOn(Engine.prototype, 'getName').and.returnValue('V8 engine');
});

...

it('should display name with engine', () => {
  expect(subject.getName()).toEqual('Car with V8 engine(400 HP)');
});
```

We mock the class methods by calling the ```spyOn``` method on the class's prototype.
We also alter the return value of the function. This way the original method never gets called.
When mocking the prototype, it affects every instance of the class.

### Using Dependency Injection for Mocking

The previous solution for mocking can be achieved also with Angular's dependency injection mechanism.
We pass the ```Engine``` class as the provider token, but create the instances with a fake class.

```typescript
@Injectable()
class V8Engine {
  getHorsepower() {
    return 400;
  }

  getName() {
    return 'V8 engine';
  }
}
```

Then we pass this fake class to the setup.

```typescript
beforeEach(() => {
  TestBed.configureTestingModule({
    providers: [
      { provide: Engine, useClass: V8Engine },
      Car
    ]
  });
});
```

With this setup, the ```inject``` call will return an instance of ```V8Engine``` when asked for ```Engine```.
We can also use ```useFactory``` with a callback, or ```useValue``` with an instance, to accomplish the same result.
The only drawback here is that every method of the class must be implemented and changed
whenever the original class changes.
The original class can be extended optionally in order to override only specific methods.

<include src="asides/Angular" />

## Conclusion: What we've learned about Angular Testing

In this tutorial, we managed to:

- create a basic service and write tests for it
- use dependency injection in tests
- fake dependencies with Jasmine
- fake dependencies with dependency injection

If you follow the steps introduced in this article and write tests for your Angular application, you can sleep safe and sound.
The code will work as intended and when someone accidentally breaks it,
the tests will warn him that those changes are unsafe and shouldn't be committed until the tests are green again.

Jasmine will help you along the way with its easy syntax and batteries included (assertion and mocking library).

I hope this has convinced you that writing tests in Angular is not an overly complicated thing.

To make the start even easier, the code is available in
[this GitHub repository](https://github.com/blacksonic/angular-testing-ground "Angular testing ground").


Angular Testing In Depth: Services

ryan-chenkie

Ryan is a full-stack JavaScript developer and trainer who mainly works with React, Angular, Node, and GraphQL. He runs a consultancy where he builds apps for companies and also helps established dev teams with their modern JavaScript challenges.<br /><br />Ryan is a Google Developer Expert, the host of the Entrepreneurial Coder Podcast, the author of Securing Angular Applications, and an all-around fanatic about application security.

Developer

Ryan Chenkie

Learn about Angular 2's new Dependency Injection system and how to use models to organize your app.

---

**TL;DR:** Domain models are important for defining and enforcing business logic in applications and are especially relevant as apps become larger and more people work on them. In this article, we show how this can be done in an Angular 2 app by moving logic out of the component and into a model. We also cover how to inject model classes using Angular 2's new Dependency Injection system. Check out the [repo](https://github.com/auth0/angular2-models-di) for the article to see the code.

This is the second part of our Angular 2 series. You can also check out the first part about [Angular 2 pipes](https://auth0.com/blog/2015/09/03/angular2-series-working-with-pipes/).

---

> Auth0's Angular 2 series brings you tutorials on how to implement the latest features from the framework using the most recent Alpha release at the time of writing.

As applications grow in size, it becomes increasingly important that they be well organized with a solid structure in place. This is especially critical as increasing numbers of developers are added to the team. Application architecture should also strongly focus on the business rules that govern the application and protect sensitive methods from being exposed where they shouldn't be.

<include src="TweetQuote" quoteText="As applications grow in size, it becomes important that they be well organized with a solid structure in place"/>

At the same time, it is important that we keep our applications DRY and maintainable by moving logic out of components themselves and into separate classes that can be called upon. A modular approach such as this makes our app's business logic reusable.  

One way we can achieve this type of structure in Angular 2 applications is by using models to organize our business logic. Whereas the term "model" in Angular has typically been used to refer to the View-Model, what we're discussing here is the domain model-or the set of rules and business logic that an application implements for it to adhere to the organization's needs.

The term "domain model" is, of course, a generic one. Domain models are relevant in any kind of application. In this tutorial, we will see how we can abstract business logic to a model in an Angular 2 app and use the new **Dependency Injection (DI)** system to call upon these models. We will also explore the DI system's features and various ways it can be used.

## Getting Started with an Angular 2 app

We'll be writing our app in TypeScript, but everything will work just fine in ES6. If you'd like an Angular 2 starter app in ES6, checkout [Pawel Kozlowski's](https://twitter.com/pkozlowski_os) [ng2-play](https://github.com/pkozlowski-opensource/ng2-play/) repo.

Our sample app will take a user's details as input and use a model to handle those values. Let's start with a simple component called `UsersAppComponent`.

```js
// app.ts

/// <reference path="typings/_custom.d.ts" />

import {Component, View, bootstrap, bind, FORM_DIRECTIVES} from 'angular2/angular2';
import {Inject} from 'angular2/di';

@Component({
  selector: 'users'
})
@View({
  // Form directives to be used in the template
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  constructor() {}

}

bootstrap(UsersAppComponent);
```
Our template has some simple inputs for the user to provide their information, including checkboxes for them to select which programming languages they know.

```html
  

  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    
    <input type="text" placeholder="Enter your name" [(ng-model)]="user.name">
    <input type="text" placeholder="Enter your email" [(ng-model)]="user.email">
    <h3>Languages</h3>
    <input type="checkbox" [(ng-model)]="user.javascript">JavaScript
    <input type="checkbox" [(ng-model)]="user.ruby">Ruby
    <input type="checkbox" [(ng-model)]="user.php">PHP
    <button>Submit</button>
  </form>
```

## Handling User Data

For our app, we'll want to take the user's input to see how it can be handled with a model. For simplicity, we'll just log the info to the console in these examples, but you would typically be doing HTTP requests to send the user data off to a server to be persisted.

We could set up a simple `User` class that acts as a model for our data and have some additional methods in our `UsersAppComponent` that act upon the form data. We can do this right within our component, but as will become evident later, there are some drawbacks to this. Let's see what it would look like for now. The class arrangement will be:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/6o3tJOtNbC96nlsVPqjeLs/a54fc2b4d2955d66f1b84410801b03d6/classes-at-start)

```js
// app.ts

...

class User {
  name: string;
  email: string;
  rating: number;
}

@Component({
  selector: 'users'
})
@View({
  directives: [FORM_DIRECTIVES],
  templateUrl: 'userTemplate.html'
})

class UsersAppComponent {

  // We instantiate the user class.
  user = new User();

  submit(userInfo) {
    // HTTP request would go here
    console.log(
      this.user.name,
      this.user.email,
      this.calculateRating(this.user)
    );
  }

  // Method to calculate the user's points
  calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }
}

...
```
We have two-way data binding set up on our form inputs, and they are bound to the instance of our `User` model. The `submit` method in our component's constructor logs the all the data to the console, including a calculation for the user's rating that it runs with the `calculateRating` method. How the heck did PHP get to be worth 50 points? I guess we'll never know.

## Improving the Model

While this approach works sufficiently well when an application is small, the way we have set things up does have a few drawbacks:

1. The `User` class isn't enforcing which values should be present or not. This can have implications if some operation downstream expects certain values to always be present.
2. The model doesn't have methods of its own to handle the calculation of the user's rating or the submission of the data. What if we wanted to have this same functionality in another of our app's components? We would need to duplicate the code in those other components.
3. While `calculateRating` is trivial in this example, what if we had some important and sensitive method with business logic that is meant only for specific circumstances? We need a way to be certain that such methods can't be used in places they're not supposed to be.
4. We currently have no ability to potentially share models with a JavaScript backend.

Let's see how we can tackle some of these issues. We'll start by moving the model to its own file. We'll eventually want to end up with classes that look more like this:

![angular2 models dependency injection](https://images.ctfassets.net/23aumh6u8s0i/2AZ4VJnqch6kcfIL6DlYlv/6fc64e402d51f1a5e9c12975324c0ac3/classes-at-end)


```js
// models/user.ts

export class User {
  name: string;
  email: string;
  rating: number;

  constructor(userInfo:any) {
    this.name = userInfo.name;
    this.email = userInfo.email;
    this.rating = this.calculateRating(userInfo);
  }

  private calculateRating(userInfo) {
    var rating = 0;
    if(userInfo.javascript) {
      rating += 30;
    }
    if(userInfo.ruby) {
      rating += 20;
    }
    if(userInfo.php) {
      rating += 50;
    }
    return rating;
  }

  save() {
    // HTTP request would go here
    console.log(this.name, this.email, this.rating);
  }
}
```

We're now using a constructor in our `User` method, which will set the values for `name`, `email`, and `rating` when the class is instantiated. We've got our `calculateRating` method in our class now, along with a `save` method to take care of making an HTTP request to save the data.

In our template, let's switch from using `ng-model` for two-way data binding to `ng-control` to get the form values when the form is submitted.

```html
  
  <form role="form" #form="form" (ng-submit)="submit(form.value)">
    <input type="text" placeholder="Enter your name" ng-control="name">
    <input type="text" placeholder="Enter your email" ng-control="email">
    <input type="checkbox" ng-control="javascript">JavaScript
    <input type="checkbox" ng-control="ruby">Ruby
    <input type="checkbox" ng-control="php">PHP
    <button>Submit</button>
  </form>
```

We can now modify the `UsersAppComponent` to instantiate and save a new instance of the model when the form is submitted.

```js
// app.ts

...

import {User} from 'models/user';

...

class UsersAppComponent {

  submit(userInfo) {

    // Instantiate and save when the form is submitted
    this.user = new User(userInfo);
    this.user.save();

  }
}

...

```

The model and the methods that it relies on are now in the same spot and can be used in other parts of the application as well. In the model, we specified that we want `calculateRating` to be `private`, but as it stands, we would still be able to gain access to it from outside the `User` model. This is part of [TypeScript's design](http://typescript.codeplex.com/discussions/451129), but we can put a workaround in if we really wanted to protect `calculateRating`. Although it might not work as an architectural approach in every situation, we could define `calculateRating` as a function within the class constructor, which would prevent it from being accessed elsewhere. The downside here is that the function is not available to other methods within the class.

```js
// models/user.ts

...

constructor(userInfo:any) {

  this.name = userInfo.name;
  this.email = userInfo.email;
  this.rating = calculateRating(userInfo);

  // Function is only available inside the constructor
  // when the logic really needs to be protected.
  function calculateRating(userInfo) {...}
}

...
```

## Moving to Factories

We've seen how we can instantiate a new model and access methods on it, but what if we wanted to take the factory approach? In this approach, instead of instantiating the model directly in our components, we would call a method like `create` on the factory. As applications grow and classes become increasingly complex, this can have certain advantages, especially for maintainability. For example, if we wanted to change the name of a class that gets instantiated, the factory approach allows us to make a change solely to the factory itself and not all the instantiation points around the app.

This is also where Angular 2's Dependency Injection comes in, as we'll need to inject the factory to make use of it.

```js
// models/userFactory.ts

import {User} from './user';

export class UserFactory {

  // Uses the User model to create a new User
  create(userInfo:any) {
    return new User(userInfo);
  }

}
```

We'll need to inject the `UserFactory` into our component's constructor. Angular 2 comes with an `@Inject` decorator, which is used to attach metadata to the component. We also need to include `UserFactory` in an array when the app is bootstrapped so that it is included as a binding.

```js
// app.ts

...

import {UserFactory} from 'models/userFactory';

...

class UsersAppComponent {
  userName: string;
  userRating: number;
  rating: number;

  // We inject the UserFactory
  constructor(@Inject(UserFactory) UserFactory) {  
    this.UserFactory = UserFactory;
  }

  ...
}

// We bind the UserFactory when the component is bootstrapped
bootstrap(UsersAppComponent, [UserFactory]);

```

With `this.UserFactory` pointing to the `UserFactory`, we can now make use of its methods. Let's adjust the `submit` method to use the factory.

```js
// app.ts

...

submit(userInfo) {
  this.user = this.UserFactory.create(userInfo);
  this.user.save();
}

...


```

Now when the user submits the form, `create` and `save` are called with the form data.

We can also use the model approach to get the data for the user that just submitted the form. For example, we could add a `get` method to the `User` class that returns (or in this case logs to the console) the user's data.

```js
// models/user.ts

...

get() {
  console.log(this.name, this.email, this.rating);
}

...
```

Then within the component we can create a `getUser` method to retrieve it.

```js
// app.ts
...

getUser() {
  this.user.get();
}

...
```

## More on Dependency Injection

We used the `@Inject` decorator to bring in `UserFactory` above; however, TypeScript also allows us to use type annotations, which means the constructor can be written as:

```js
// app.ts

...

constructor(UserFactory: UserFactory) {...}

...
```

The array syntax we used to bind `UserFactory` to our component is the shorthand way of doing it. We can also explicitly state what we want to bind to, which gives us the option of binding to other classes. For example, we could bind `User` to `UserFactory` directly.

```js
// app.ts

...

// The UserFactory can be bound to another name, in this case, User
bootstrap(UsersAppComponent, [bind(User).toClass(UserFactory)]);

...
```

With this, `UserFactory` becomes `User` when used in our component.

## Aside: Using Angular with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [Single Sign On](https://auth0.com/docs/sso/single-sign-on), User Management, support for Social (Facebook, Github, Twitter, etc.), Enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code. We implemented a tight integration with Angular 1. Angular 2 integration is coming as soon as it's on Beta! You can read the [documentation here](https://auth0.com/docs/client-platforms/angularjs) or you can checkout the [SDK on Github](https://github.com/auth0/auth0-angular).

<img src="https://images.ctfassets.net/23aumh6u8s0i/4PnRDegulvaccUIfNyaAtn/8342312355dc6af44a69c07c66f58be7/pub_w_1219_amp_h_559" style="border: 1px solid #ccc;padding: 10px;"/>

## Wrapping Up

It's important that thought be given to how applications are architected so that they are easier to maintain and can be collaborated on by more developers as team sizes grow. It's also important to protect business logic and keep sensitive methods from being accessed outside the class to which they belong. These effects can be achieved by moving logic into models.

Angular 2 gives us a new Dependency Injection system that allows us to inject classes into our components easily. We had a brief look at how the new DI system works, but for a more thorough overview, we recommend you check out [Pascal Precht](https://twitter.com/PascalPrecht)'s post on [Dependency Injection in Angular 2](http://blog.thoughtram.io/angular/2015/05/18/dependency-injection-in-angular-2.html).

"Injection"