LoopBack + AngularJS authentication solution

In this article I’m going to describe the way I use LoopBack’s authentication service in connection with an AngularJS app on client side. While primarily based on the LoopBack getting started intermediate  tutorial, I tried to merge in John Papa’s style guidelines as well as a few other blog posts on the matter.

Server side

LoopBack offers a flexible system to build an authentication system that suits the demands of your application. The documentation on Users, Roles, RoleMappings, ACLs etc. is quite comprehensive , so I don’t feel like there is a lot to add on this side. AngularJS will use the automatically generated services in lbServices.js to communicate via the REST API.

Client side

Of course, everything we are going to do here is providing a nice user experience by hiding routes and endpoints the current user has no access on. Since all code can possibly be altered by the client, essential security measures are to be taken on server side.

Status broadcasts

As LoopBack already offers a solid groundwork, the only real addition is a broadcasting system offering authentication status changes so that all parts of the application can adapt to new situations accordingly. I picked up a lot of ideas from a wonderful article by Gert Hengeveld in which he introduces a broadcasting system based on constants for the respective authentication states. Angular’s broadcast system is a controversy topic and according to the widely recognized Angular Style Guide by John Papa , we should avoid using it at all. However, while I see the risks of event-spamming if we talk about inter-controller communication, an authentication state broadcasting system is probably the only case where I opt for Angular events.


The basic idea is that whenever a call to authService is made, we make sure to publish all relevant state changes using Angular broadcasts. These are, among others you might find useful in your application, LOGIN_SUCCESS , LOGIN_FAILED and LOGOUT_SUCCESS .
The following diagram is showing dependencies between the components in the discussed authentication-state broadcasting system. The dashed lines are injects.
Diagram that shows dependencies between components in the introduced authentication system.
Next, I tried to model a basic procedure where a user submits the login form and gets redirected to the application’s main page. Since the user is authenticated after that, the menu bar has to show differing items and maybe include the user name in the upper right corner. The diagram below shows all that.Sequence diagram of a basic login procedure.



StrongLoop, “Controlling data access - LoopBack - Documentation,” Controlling data access. [Online]. Available: https://docs.strongloop.com/display/public/LB/Controlling+data+access. [Accessed: 29-Sep-2015]
StrongLoop, “Defining and using roles - LoopBack - Documentation,” Defining and using roles. [Online]. Available: https://docs.strongloop.com/display/public/LB/Defining+and+using+roles. [Accessed: 29-Sep-2015]
StrongLoop, “Authentication, authorization, and permissions - LoopBack - Documentation,” Authentication, authorization, and permissions. [Online]. Available: https://docs.strongloop.com/display/public/LB/Authentication%2C+authorization%2C+and+permissions. [Accessed: 29-Sep-2015]
G. Hengeveld, “Techniques for authentication in AngularJS applications: A collection of ideas for authentication & access control, Communicating session changes, The AuthService, Restricting element visibility, Restricting route access, The loginDialog directive, Read my other articles:,” Medium, 13-Mar-2014. [Online]. Available: https://medium.com/opinionated-angularjs/techniques-for-authentication-in-angularjs-applications-7bbf0346acec. [Accessed: 27-Sep-2015]
John Papa, “Angular Style Guide,” GitHub. [Online]. Available: https://github.com/johnpapa/angular-styleguide. [Accessed: 25-Sep-2015]
StrongLoop, “strongloop/loopback-getting-started-intermediate,” GitHub. [Online]. Available: https://github.com/strongloop/loopback-getting-started-intermediate. [Accessed: 25-Sep-2015]

Cloud-hosted continuous integration solutions 2015

For a new project at work, we needed to setup a continuous integration routine. As we don’t really have the capacity to host it on our own, I decided to make a brief market analysis of the available solutions in late 2015.

While my research was done with a certain project configuration in mind (a web platform running Node.js with Angular), I’m sure it can be useful for other types of projects as well.

Travis CI

Extremely popular as a lot of open-source projects hosted on Github use their free plan. The documentation is comprehensive and clean [1] plus there are tons of related posts on stackoverflow. I also found a dedicated section on browser testing. They even offer to run your script on Mac hardware [2] allowing to test on the most recent versions of Safari. The downside however is the price. Their plans start from 129$ excl. VAT per month for 2 concurrent build jobs. [3] Also, your sources must be hosted on GitHub as there is no support for any other type of repository.


Codeship is definitely worth a look for small companies as they offer a free plan with 100 builds per month, as well as an unlimited personal plan for 49$ per month. However, this does not allow to reflect organizational hierarchies in terms of account management. The organizational plan is 99$ per month. [4] Codeship supports both Github and Bitbucket, however there is no way to use any other type of repository. [5] They also do not offer builds on Mac hardware. I skimmed over their documentation and it looked clearly arranged and pretty extensive. [6]

Circle CI

Circle CI offers the most generous free plan of all solutions. You get unlimited builds for one repository for free. Any additional container is 50$ [7]. Their documentation looks good with lots of real-world examples and technology-specific tutorials. I discovered a section on iOS builds on Mac hardware. [8] While this feature seems to be experimental at the moment, it might indicate that Circle CI is planning to offer Mac hardware for regular build jobs in the near future. As for SCM, only Github is supported. [9]

Jenkins CI on AWS

This section is hard to evaluate since I don’t have any experience how much resources Jenkins will actually use. However it is possible to answer a few obvious questions. You will have to spend a lot of time setting up and configuring Jenkins, even more so if you plan to use its EC2 features allowing it to scale by launching additional instances on demand. There is clearly no way to use Mac hardware and although there is no actual limit on build jobs, make sure you have set AWS billing alerts.


Since pricing policy differs from company to company, I decided to compare the first plans that offer unlimited builds on 2 concurrent jobs.

Price and feature comparison
Travis CI Codeship Circle CI Jenkins CI on EC2
Github yes yes yes yes
Bitbucket no yes no yes
Private SCM no no no yes
Mac Hardware yes no iOS no
Concurrent Jobs 2 1(2)* 2 ultd.
Ultd. Plans from 129$ 49$(99$**) 50$ ?
Setup easy easy easy hard
SSH Debugging no*** yes yes yes

* Only one concurrent job but 2 parallel test pipelines
** Organization plans including account management from 99$
*** Various blog posts indicate that they will launch a VM for you to debug your scripts


[1] http://docs.travis-ci.com
[2] http://docs.travis-ci.com/user/workers/os-x-infrastructure
[3] https://travis-ci.com/plans
[4] https://codeship.com/pricing
[5] https://codeship.com/documentation/faq/other-scm
[6] https://codeship.com/documentation
[7] https://codeship.com/pricing
[8] https://circleci.com/docs/ios
[9] https://circleci.com/docs/faq#do-you-support-bitbucket-or-gitlab-