Consider the following well-crafted text about the malfunctioning of the collaboration between development and operations, posted anonymously to a developer forum I visit regularly: NoOps: Developer operations manifesto This is not pretty, but it must be said. We are tired. The madness must stop. We create software, the product that identifies our company. We are academic software engineers, trained to understand our work. We show responsible behaviour, creating as much value as possible. We do not like meetings, documentation or other waste in this process. We prevent problems by writing tests and by using versioned environments. We fix problems immediately, reducing the impact of issues dramatically. We are not flawless, but that is neither your problem, nor your duty to solve. ...

In my previous post I announced a attempts at high performance web server implementations in some popular languages (Java, Go, C# and JavaScript). Today I will show you a Java implementation and give you instructions on how to get it running on your own machine. Jetty for high performance Jetty is a Web server and “javax.servlet” container that can be easily embedded in devices, tools, frameworks, application servers, and clusters. Jetty is known to be the web application of choice of Yahoo’s Hadoop Cluster, Google’s AppEngine PaaS and Yahoo’s Zimbra SaaS. Because it was used for such important projects, I expected that it would be hard to implement, but the opposite turned out to be true. ...

In today’s era of web based micro-services (HTTP APIs) building small simple high performance web servers is of vital importance. In this blog post background information is given on the expected performance of implementations in popular programming languages. This post will be followed up by attempts at high performance implementations in some of these languages (Java, Go, C# and JavaScript). Do not expect benchmarks or absolute numbers, but do expect source code that you can easily run on your machine, so that you can do the benchmarking yourself. ...

Today I stumbled upon “PostgREST”, a generated PostgreSQL REST API. I have built PHP-CRUD-API, a similar tool, for MySQL in PHP. PostgREST is a standalone web server that turns your database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations. This great software is written by Joe Nelson and has acquired over 6000 stars on Github and has it’s own website on postgrest.com. ...

I did a basic implementation of a JWT authentication scheme in PHP. It has no dependencies, so you can simply incorporate the two functions below in any existing application. I have been writing about JavaScript Web Token security earlier this month. It is a token standard that is well described on JWT.io. <?php function getVerifiedClaims($token,$time,$leeway,$ttl,$algorithm,$secret) { $algorithms = array('HS256'=>'sha256','HS384'=>'sha384','HS512'=>'sha512'); if (!isset($algorithms[$algorithm])) return false; $hmac = $algorithms[$algorithm]; $token = explode('.',$token); if (count($token)<3) return false; $header = json_decode(base64_decode(strtr($token[0],'-_','+/')),true); if (!$secret) return false; if ($header['typ']!='JWT') return false; if ($header['alg']!=$algorithm) return false; $signature = bin2hex(base64_decode(strtr($token[2],'-_','+/'))); if ($signature!=hash_hmac($hmac,"$token[0].$token[1]",$secret)) return false; $claims = json_decode(base64_decode(strtr($token[1],'-_','+/')),true); if (!$claims) return false; if (isset($claims['nbf']) && $time+$leeway<$claims['nbf']) return false; if (isset($claims['iat']) && $time+$leeway<$claims['iat']) return false; if (isset($claims['exp']) && $time-$leeway>$claims['exp']) return false; if (isset($claims['iat']) && !isset($claims['exp'])) { if ($time-$leeway>$claims['iat']+$ttl) return false; } return $claims; } function generateToken($claims,$time,$ttl,$algorithm,$secret) { $algorithms = array('HS256'=>'sha256','HS384'=>'sha384','HS512'=>'sha512'); $header = array(); $header['typ']='JWT'; $header['alg']=$algorithm; $token = array(); $token[0] = rtrim(strtr(base64_encode(json_encode((object)$header)),'+/','-_'),'='); $claims['iat'] = $time; $claims['exp'] = $time + $ttl; $token[1] = rtrim(strtr(base64_encode(json_encode((object)$claims)),'+/','-_'),'='); if (!isset($algorithms[$algorithm])) return false; $hmac = $algorithms[$algorithm]; $signature = hash_hmac($hmac,"$token[0].$token[1]",$secret,true); $token[2] = rtrim(strtr(base64_encode($signature),'+/','-_'),'='); return implode('.',$token); } $algorithm = 'HS256'; $secret = 'secret'; $time = time(); $leeway = 5; // seconds $ttl = 30; // seconds $claims = array('sub'=>'1234567890','name'=>'John Doe','admin'=>true); // test that the functions are working $token = generateToken($claims,$time,$ttl,$algorithm,$secret); echo "$token\n"; $claims = getVerifiedClaims($token,$time,$leeway,$ttl,$algorithm,$secret); var_dump($claims); Important notes Note that this implementation supports “HS” (HMAC based) signature algorithm with “iat” (issued at), “nbf” (not before) and “exp” (expires) fields. It does NOT support the “RS” (RSA based) and “ES” (Eliptic Curve based) signature algorithms. It also does NOT check the “iss” (issuer), “sub” (subject), “aud” (audience), “jti” (JWT token identifier) or “kid” (key identifier) fields. Please read the documentation on JWT.io to find out whether or not that matters to you. ...

If you are following this blog, then you know I’m working a lot on API software architectures. I noticed that a lot of people that are building an API are actually building the same thing (except for the data model they expose). Typically they simply expose their tables using JSON REST operations (typically Create, Read, Update and Delete) or they expose their more sophisticated stored procedures via their API. This post is about that last category. ...

On c2.com I read a quote by Jeff Mantei on the OnReflection page: I think of reflection as the ability to reason about the structures and processes of a programming system within the programming system itself. - Jeff Mantei I was thinking of another definition saying: Reflection is when the logic of an information system is based on the meta-information of that system. But after giving it some serious thought I believe Jeff is much better. His quote is not only a very concise definition of reflection, but he is also not cheating by using the word “meta”, as I did, which has a lot to do with reflection. ...

This post will discuss how to use JSON Web Token (JWT) to separate your authentication from you API endpoints and how to do so securely in a Single Page Application (SPA). JSON Web Token (JWT) A JSON Web Token is an alternative for the combination of a session cookie and a server side session object. It typically contains the authentication and authorization “claims”. The user identifier (a technical primary key or something uniquely identifying the user, such as an email address) is almost always on of the claims (called the “subject”). Typically you may also have the role of that user in the application as a claim. These claims are sent to the server using a “Authorization” request header and can be trusted, because they are signed by the issuer (typically your authentication service). ...

This post will explain what XSS and CSRF attacks on web applications are and also what the best practices are to counter them. It will explain the mitigation techniques: Output escaping, “HttpOnly” cookie and CSRF-token. XSS and CSRF explained Most web applications that require login use a session cookie that contains the session identifier (and preferably nothing else). This identifier corresponds on the server side with a session object, stored in a central session store. It is used as a proof that you once entered your username/password correct in the session and should therefore be protected carefully. A malicious JavaScript may be executed on your site that “steals” the session cookie and posts it to the attackers website. The attacker will be receiving these session cookies and can start using the application, while being logged in as you. This is called “Cross Site Scripting” or XSS. “Cross Site Request Forgery” on the other hand exploits the behavior of automatically sending the session cookie on every request. It will do something on the logged in web application on your behalf, by cross-posting a form from the attackers website to the web application you are logged in to. In this scenario we protect ourselves against XSS with output escaping and “HttpOnly” cookies and against CSRF with a so-called “CSRF token”. ...

Multitenancy in IT is the concept that you put your customers on shared infrastructure (as opposed to an on-premise solution). This concept is also referred to as “cloud computing”. It may be obvious that multitenancy impacts costs, security, availability and performance. This is also true when multitenancy is applied to database systems. But note that database multitenancy is not a black-or-white thing. 5 levels of database multitenancy You can identify the following 5 different levels of multitenancy in the database world. Customers may share: ...