Apache Etch: Open source, cross-platform, language & transport-independent framework for building and consuming network services

Apache Etch logo

We consume a lot of SOAP web services at work, and frankly, it sort of sucks. SOAP is heavier (and slower) than I would prefer.

From the Apache Etch web page:

Etch is a cross-platform, language- and transport-independent framework for
building and consuming network services. The Etch toolset includes a network
service description language, a compiler, and binding libraries for a variety of
programming languages. Etch is also transport-independent, allowing for a
variety of different transports to be used based on need and circumstance. The
goal of Etch is to make it simple to define small, focused services that can be
easily accessed, combined, and deployed in a similar manner. With Etch, service
development and consumption becomes no more difficult than library development
and consumption.

Etch was started because we wanted to have a way to write a concise, formal
description of the message exchange between a client and a server, with that
message exchange supporting a hefty set of requirements:

  • support one-way and two-way, real-time communication
  • high performance and scalability
  • support clients and servers written in different languages
  • support clients/servers running in a wide range of contexts (such as thin web
    client, embedded device, PC application, or server)
  • support anyone adding new language bindings and new transports
  • be fast and small, while still being flexible enough to satisfy requirements
  • finally, it must be easy to use for developers both implementing and/or
    consuming the service.

Here is a list of the language bindings Etch currently supports:

  • Java – stable
  • C# – stable
  • C – stable
  • C++ – beta
  • Google Go – alpha
  • Javascript – alpha
  • Python – alpha

SQRL: (Secure Quick Reliable Login): Proposed new web login & authentication system

SQRL An Illustrated Guide

I came across SQRL from listening to the Security Now podcast on the TWIT podcast network. When I heard about it, I immediately thought, “I want that!” I’m not sure if it will eventually catch on or not, but there are aspects to SQRL that I find appealing.

You can find details about the proposed SQRL authentication spec on the creator’s page or in the podcast where he announced it.

I recently came across an illustrated guide to SQRL that might help with understanding some of the more gnarly bits.

From the SQRL page on GRC.com:

Wishing to login to an online service where an “SQRL” code appears nearby:

  • The user can tap or click directly on the SQRL code to login,
  • or launch their smartphone’s SQRL app, and scan the QR code.
  • For verification, SQRL displays the domain name contained in the SQRL code.
  • After verifying the domain, the user permits the SQRL app to authenticate their identity.
  • Leaving the login information blank, the user clicks the “Log in” button… and is logged in.

Behind the scenes:

The website’s login presents a QR code containing the URL of its authentication service, plus a nonce. The user’s smartphone signs the login URL
using a private key derived from its master secret and the URL’s domain name. The Smartphone sends the matching public key to identify the user,
and the signature to authenticate it.

Yeah. So the quotes above are probably not adequately explaining why I’m excited by the possibilities of SQRL. It seems like a simpler way to login, and I like that it doesn’t require you to trust a third party. Clicky the links or listen to the podcast to learn more.

Doozer: consistent distributed data store written in Go

Doozer logo

This looks interesting. At work we use a VIP to control which machines are in the live group and which are in the dark (standby) group. We used to use DNS, but the propagation delay caused issues, especially if we needed to roll back a change.

From the Doozer Github Repo:

Doozer is a highly-available, completely consistent store for small amounts of extremely important data. When the data changes, it can notify
connected clients immediately (no polling), making it ideal for infrequently-updated data for which clients want real-time updates. Doozer is good
for name service, database master elections, and configuration data shared between several machines.

Webview Screenshot from Doozer Github page

Repsheet: Local reputation engine for your site implemented as Apache module that stores its data in Redis

From the Repsheet Github repo:

Repsheet is a collection of tools to help improve awareness of robots and bad actors visiting your web applications. It is primarily an Apache web
server module with a couple of addons that help organize and aggregate the data that it collects.

Repsheet attempts to solve the problem of automated defenses against robots and noisy attackers. It collects and records activity of the IP
addresses that access your web sites and helps determine if they are misbehaving. If they are, they are put on the Repsheet. Once there, you can
choose to outright deny them access to your site or warn your downstream applications that the requestor is a known bad actor and that the request
should be handled differently. Essentially, it is a local reputation engine.

FreeMarker: Java Templating Engine

Freemarker image

From the website:

FreeMarker is a “template engine”; a generic tool to generate text output (anything from HTML to autogenerated source code) based on templates.
It’s a Java package, a class library for Java programmers. It’s not an application for end-users in itself, but something that programmers can
embed into their products.

FreeMarker is designed to be practical for the generation of HTML Web pages, particularly by servlet-based applications following the MVC (Model
View Controller) pattern. The idea behind using the MVC pattern for dynamic Web pages is that you separate the designers (HTML authors) from the
programmers. Everybody works on what they are good at. Designers can change the appearance of a page without programmers having to change or
recompile code, because the application logic (Java programs) and page design (FreeMarker templates) are separated. Templates do not become
polluted with complex program fragments. This separation is useful even for projects where the programmer and the HTML page author is the same
person, since it helps to keep the application clear and easily maintainable.

Although FreeMarker has some programming capabilities, it is not a full-blown programming language like PHP. Instead, Java programs prepare the
data to be displayed (like issue SQL queries), and FreeMarker just generates textual pages that display the prepared data using templates.

We use Apache Velocity extensively at work in our web content, but it hasn’t seen much in the way of updates for quite some time.