One of the greatest things about the Amazon AWS services is that they save a tonne of time on the reinventing the wheel. There are numerous technologies out there and nobody has the time to dive deep, learn, and try all of them. Amazon AWS often provides ready-made templates and configurations for people who just want to try a technology or a tool, without investing too much time (and money) into figuring out all the options and tweaks.
“Get Started with Blockchain Using the new AWS Blockchain Templates” is one example of such predefined and pre-configured setup, for those who want to play around with Blockchain. Just think of how much time it would have taken somebody who just wants to spin up their own Etherium network with some basic tools and services just to check the technology out. With the predefined templates you can be up and running in minutes, and, once you are comfortable, you can spend more time rebuilding the whole thing, configuring and tweaking everything.
This article (in Russian) lists a number of useful payloads (and some tools that work with them) for security testing of web applications. Below is the list of handy GitHub repositories for web server path testing, cross-site scripting, SQL injection, and several other common types of vulnerabilities. These payloads are much richer than basic hand-made tests and can help improve the security of the web application a great deal:
We’re pleased to announce that ACMEv2 and wildcard certificate support is live! With today’s new features we’re continuing to break down barriers for HTTPS adoption across the Web by making it even easier for every website to get and manage certificates.
ACMEv24.0k is an updated version of our ACME protocol which has gone through the IETF standards process, taking into account feedback from industry experts and other organizations that might want to use the ACME protocol for certificate issuance and management some day.
Wildcard certificates5.1k allow you to secure all subdomains of a domain with a single certificate. Wildcard certificates can make certificate management easier in some cases, and we want to address those cases in order to help get the Web to 100% HTTPS. We still recommend non-wildcard certificates for most use cases.
Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv28.5k. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.
Additionally, wildcard domains must be validated using the DNS-01 challenge type. This means that you’ll need to modify DNS TXT records in order to demonstrate control over a domain for the purpose of obtaining a wildcard certificate.
“7 ways to do containers on AWS” covers a variety of different ways to run containers on the Amazon AWS cloud infrastructure. These include most of the usual suspects, like Amazon Elastic Container Service (ECS), Amazon Elastic Container Service for Kubernetes (EKS), and hand-rolled vanilla containers on EC2, as well as a few lesser known ones like templated Kubernetes and Amazon Fargate.
Server Push was one of the most exciting features for me in all of the HTTP/2 specification. But I wasn’t quite sure how it will be implemented, and, most importantly, how it can be made easily available to the web developers, who are often few levels removed from the web server configuration. I think Nginx solves the problem quite elegantly.
On the configuration level, “location” directives are often available to the web developers withing the virtual host / server. But for those who can’t use those or don’t want to mess around with the configuration files, an even easier option is available – Link HTTP header.
I’m sure this will soon be widely supported in all the major libraries and frameworks, much like HTTP cookies are. Great times ahead!
Red Hat issued a press release announcing that it has signed a definitive agreement to acquire CoreOS Inc.
RALEIGH, N.C. — — Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced that it has signed a definitive agreement to acquire CoreOS, Inc., an innovator and leader in Kubernetes and container-native solutions, for a purchase price of $250 million, subject to certain adjustments at closing that are not expected to be material. Red Hat’s acquisition of CoreOS will further its vision of enabling customers to build any application and deploy them in any environment with the flexibility afforded by open source. By combining CoreOS’s complementary capabilities with Red Hat’s already broad Kubernetes and container-based portfolio, including Red Hat OpenShift, Red Hat aims to further accelerate adoption and development of the industry’s leading hybrid cloud platform for modern application workloads.