As a software engineer, it is always interesting to learn a new programming language. At Osprey Security, when it turned out that I would be involved in a project with Go or Golang as it is also referred to, as the primary back-end language, it was a really exciting feeling. The fact that Golang was designed to be a good fit for server side programming added more spice to all this.
Here I’m going to share my first impression on the language. Quite a few features of Golang will be described in the prism of Java which I used a lot last years.
What is striking for a Java developer is that Golang is not an object oriented language in a pure sense of this word. Yes, it has structures and you can call functions on those structures, as if you call methods in OOP language but there is no inheritance. Golang uses composition instead. Go is not functional, but it has anonymous functions, high order functions and so on. As for me, I see Go as procedural language. If somebody asks me to describe Go, I would say… like C. As in C, there is no exception handling, but functions return error codes instead. There is no function overloading as it regarded a bad practice, but there is support for pointers! (more…)
Securing our users has always been a challenge on the web. For years, we’ve found that the traditional usernames and passwords provided a secure method for authenticating users. They enter their credentials, submit the form, and in no time, they gain access to the providers services. Better known as a Single Factor of Authentication, SFA is still used across majority of the sites and has been a reliable security method. But, over time, attackers have been able to expose user credentials applying certain techniques. As a way of protection our users, we started to implement password checks and used well known hashing and salting techniques at the database level. But in most cases, not all password checks are equal and not all hashing techniques are reliable enough to prevent attacks.This is where Two Factor Authentication comes in.
So what is Two Factor Authentication? TFA a method that is based on users providing two factors of information rather than a single credential. Now, why is this a better option? For one, it adds an extra layer of security over the traditional username and password by removing the need to create highly secure password checks and two, introducing a second factor such as a device the user owns, increases the difficultly for hackers to obtain a successful attack. Here at Osprey, TFA was one of the strategies we wanted to integrate for our login portal. With multiple 2F strategies available, we found a new strategy created by the Facebook team called Account kit.
Introducing Facebook’s Account Kit
Introduced at the F8 conference this April, Account kit was a new product that Facebook launched for all developers to secure their mobile and web applications. In short, Account kit is a TFA and Single Sign On method that allows users to login and register using their phone number or email. With Account kit, developers don’t have to create a separate workflow to handle new registrations because their infrastructure handles authentication and managing user accounts. To get a better picture on how it works, let’s take a look at what happens during a simple login using Account kit: (more…)
Docker is perfect to make the developer’s life easier. Thanks to containers, one can engineer the many facilities that make their application into many microservices, dividing their problem into more manageable blocks. For instance, you can trigger a container for a redis database, along with a container fueled by an node.js / express image, and you can have your infrastructure up and running with no hassle.
Docker can prove handy even for optimizing the building pipeline. Indeed, using docker-compose, the Docker orchestration tool, and volumes, you can build your app stage by stage, passing through shared docker data *volumes* the result of any of these build steps to the next one. At the end of the pipe-line, you would have a container, with access to all of the artifacts that have been built so far – via the shared data volumes – launching the very services of your application.
Docker Compose in Action
But let’s see an example in action.
You have two stages of building here:
2. Then, you have to build AND run the *Golang* server, going first through downloading your project’s dependencies (assuming you used Godeps), building and installing the *Golang* service, and running it as a daemon at the startup of your app (containerized or not)
If we want to use containers to approach such a situation, we’d have
- Store these generated front-end assets in a data volume so we can persist and hand them over to the back-end
- And spin off a container running Golang, mount the previously prepared data volume on it, run the dependency fetching, the building and assigning an entry point (that is, the command firing the service upon launch of the container).
As we can proceed to these steps by hand jsut fine, or script them using Shell or whatever, we can use docker-compose, the very useful orchestration tool that comes with the docker toolbox distribution. (Linux users might have to install it by hand) (more…)