DEV Community: Sorin Costea

HTTPS with mutual authentication

Sorin Costea — Fri, 24 Jun 2022 12:51:17 +0000

If you want to secure your existing Tomcat server or don’t use Spring Boot there’s quite a lack of up-to-date configuration information, especially because all existing examples were made invalid by the arrival of Tomcat 10 (yes it already happened).

So because I needed a future proof SSL configuration that is also understandable to the security beginner (also me), here’s what I come up with:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" scheme="https" secure="true" maxThreads="150" SSLEnabled="true" defaultSSLHostConfigName="localhost">
    <SSLHostConfig hostName="localhost" truststoreFile="server-truststore.jks" protocols="all" truststorePassword="changeit" certificateVerification="required">
        <Certificate certificateKeystoreFile="server-keys.p12" certificateKeystoreType="PKCS12" certificateKeystorePassword="changeit" certificateKeyAlias="server" type="RSA"/>
    </SSLHostConfig>
</Connector>

SSL connection
So you want that browsers connecting to your web server to see the trustworthy padlock icon in the address bar, by connecting with HTTPS? This means you need HTTP over SSL, or TLS actually.
For this the server will send the appropriate certificate to the browsers, identifying itself with it. This server certificate is stored in a keystore – named like this because it stores the keys owned by the server. The element describes the location of this keystore, its type (default JKS, can be PKCS12) plus information on what’s inside and how to open it.
Of course the certificate sent by the server must be signed by a CA the client is trusting, otherwise you’ll get SSL with a big warning “self signed certificate” – still protecting the communication from network snooping but saying nothing about the real identity of the server.
Client authentication
So you want that only CERTAIN browsers can connect to your web server? Not a very common requirement, quite unusual for browser connections. But you’ll need it more if you build a REST API server with HTTPS and you must restrict the access to this API.
For this the server will need to trust the client, and the client must identify itself with a certificate. The certificates the server trusts are stored in a, guess what, truststore, which is configured in the SSLHostConfig element. You also need to force this client authentication by mandating certificateVerification.

Of course you can store all the certificates in one store and use it for both above purposes but it’s always easier to explain if theyre split according to role. Most of the time all these certificates will be x509 certificates anyway, thus also the common discussion topic of “x509 mutual authentication”.

Two notes:

if for testing reasons you decide to create your own certificates, do yourself a favor and use only Keytool and namely that one from the Java version you are using on the server. Don’t mix it with different Keytool versions or with OpenSSL.
for all the above to work you’ll need the APR library for Tomcat as only this one supports client authentication. See also the usage of Http11AprProtocol…

Helpful links:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html
https://docs.spring.io/spring-security/site/docs/4.0.x/reference/html/x509.html
https://www.baeldung.com/java-https-client-certificate-authentication
https://medium.com/ing-tech-romania/a-simple-mtls-guide-for-spring-boot-microservices-c6bfc9878369

Lessons learned after losing the Terraform state file

Sorin Costea — Wed, 31 Mar 2021 18:18:25 +0000

Terraform is a infrastructure-as-code (IaC) tool where you describe the desired pieces of infrastructure you need in some config files, then Terraform will create the infrastructure in your cloud provider of choice. Or delete them, or modify them – because Terraform compares the cloud infrastructure state with the expected one. And the expected state is kept in… a state file, right. So if the state file gets lost, Terraform will think it never created those resources in the first place and will try to duplicate everything. Do you see the problem here? Not only your infrastructure will cost double, but you’ll get also all kind of nasty overlappings and cross-pollination between previous and fresh resources and versions. We definitely don’t want that.

That is of course only if you don’t pay attention to what terraform plan and terraform apply are trying to do. And that is of course only if you already lost your state file – which can happen quite easily when you keep the file like me in the project directory and you just wiped that in order to clone the project again (unrelated story). Terraform recommends keeping the state remotely, be it in their (free) Terraform Cloud, in an AWS S3 bucket, anywhere else, where even though still not 100% safe it will still have better chances of recovery.

How did the day went on? After I noticed terraform plan wanted to create a few dozen resources where I expected three at max… ew, I said, and it didn’t take long to figure out what happened. A quick google revealed there’s an official tool for such cases called terraform import which would import the current state of existing resources into the state file, nice stuff apparently. Been there yesterday, done that, got these takeaways:

always name your resources even when names are optional. Also comment them where comments are available (not many). The more info, the easier to recognize what comes from where.
you’ll notice you always have more AWS components than you thought. Especially AWS API Gateway is a can of self-multiplicating quick-growing worms.
tagging is seriously overrated, at least in AWS. Not everything can be tagged, searching by tags doesn’t really exist and anyway the AWS Tag Editor won’t be able to export (aka find) all your resources, so you will still need to go through each service console and fetch resource IDs to import. That’s because terraform import needs the IDs of the existing resources in order to import their current state (makes fully sense).
those IDs are in about half of the cases the known name of the resource. The other half is made out of all kind of crazy naming schemes, which I suspect are required by AWS itself. Sometimes it’s ID/name/scope, sometimes it’s the HTTP method, sometimes it’s the ARN… all nicely documented by Terraform but if you have to search documentation by EACH resource type and you have dozens you’re off to a less than pleasant afternoon.
surprise surprise, not all resources are supported by terraform import. Not the S3 bucket objects, not the permissions… and some things I simply wasn’t able to find in the AWS console (where’s the API GW deployment ffs???). So you can’t get to 100% coverage anyway.
after a while you’ll realize that it’s easier to delete everything which can be recreated and focus to import only the (hopefully) few stateful components, basically those containing data. So I kept only my Elasticsearch domain and everything else, byes. It’s a bit of AWS console work but by orders of magnitude simpler than the above steps.
speaking of stateful components, a good advice is to protect them from accidental deletion anyway when you apply some Terraform changes. Databases come immediately in mind. Tell Terraform to:

lifecycle { prevent_destroy = true }

and you’ll be safe(r) against misplaced command line actions.

The best way is still to NOT LOSE your state file. Put it in another directory, sync it in OneDrive, upload it in Terraform Cloud or S3, do something with it, don’t be me! Just don’t save it in your versioning system or you’ll get a zillion useless versions of your software and your CI/CD (Jenkins or whatever) will go crazy.

Building Quarkus native images. You can do it too!

Sorin Costea — Mon, 30 Nov 2020 16:15:31 +0000

If you read the Quarkus native build page, it should be a breeze: enable -Pnative and there we go! Well… not so fast. Not so fast at all, as they recognize in another “Quarkus native tips” page, unfortunately not linked from the first one (so good luck googling for it). And boy do you need those tips…

I had this application happily running for months and while at the beginning there were some recognized issues with native generation on Windows, nowadays the general expectation was it should work. So I updated all dependencies and started a painful three days long trip, but hey no pain no gain right?

Here’s what it required:

First of all, you do have Docker installed, right? And enabled the container generation in the JVM parameters with
```
-Dquarkus.native.container-build=true
```
ok? Well, if you don’t want to go through the hoops of installing GraalVM too (I did, got a tshirt), use the build JVM parameter to create the image with Mandrel (mentioned on the Quarkus native page, without any explanation what the “Mandrel tags” were)
```
`-Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel:20.3-java11
```
Speaking of JVM parameters, the generation will crash soon running out of memory. Quarkus defaults schmefaults. Add this JVM parameter to increase the Java heap during generation:
```
-Dquarkus.native.native-image-xmx=4096m
```

Actually one of the first errors you’ll see will be the complaint you don’t have the src/assembly/zip.xml file mentioned in the native Maven profile. A good start will be this:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
  <id>function-native-zip</id>
  <baseDirectory>/</baseDirectory>
  <formats>
    <format>zip</format>
  </formats>
  <files>
    <file
      <source>${project.build.directory}${file.separator}${artifactId}-${version}-runner</source>
      <outputDirectory>${file.separator}</outputDirectory>
      <destName>bootstrap</destName>
      <fileMode>755</fileMode>
    </file>
  </files>
</assembly>

You’ll have definitely sooner or later the exception in logs that it cannot find org.apache.commons.logging.impl.LogFactoryImpl. Regardless how you add it to your pom, Quarkus will do some reflection magic and constantly fail at it. Just forget commons-logging and use the recommended JBoss logmanager.
```
<dependency>
  <groupId>org.jboss.logmanager</groupId>
  <artifactId>log4j2-jboss-logmanager</artifactId>
</dependency>
```
Did you know Quarkus offers their own Elasticsearch clients? I didn’t either, and I had to switch to their distribution instead of the official Elasticsearch. Same API luckily, cleaner dependencies (and no commons-logging either)
```
<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-elasticsearch-rest-high-level-client</artifactId>
</dependency>   
```
That Elasticsearch builder will produce a static client (configured via application.properties) which nobody needs. I mean, if you want to configure the host at runtime, if you want request signing as you access an AWS Elasticsearch cluster… you’ll get ambiguous injection all in a sudden. That was easy to fix – produce and use your own @Named client.
```
@Produces
@Named("essigned")
public static RestHighLevelClient getClient(final String url) {
  ...
```
Is it unable to load an HTTP implementation from any provider in the chain? That’s because many AWS SDK v2 clients include the Apache HTTP client only as runtime dependency, for whatever reason – and Quarkus itself does the same (in the above mentioned Elasticsearch client). So add it to your pom AND mention it SPECIFICALLY in the building of your clients!
```
<dependency>
  <groupId>software.amazon.awssdk</groupId>
  <artifactId>apache-client</artifactId>
  <scope>compile</scope>
  <exclusions>
    <exclusion>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
    </exclusion>
  </exclusions>
</dependency>
```
and the Java code:
```
final SsmClient ssm = SsmClient.builder().httpClientBuilder(ApacheHttpClient.builder()).credentialsProvider(chain).build();
```
Oh right, don’t forget to exclude the commons-logging dependency – that little pesky brat keeps crawling back.
Now it’s the moment for your runtime to crash for missing proxies, more precisely because “generating proxy classes at runtime is not supported”. Don’t ask why Quarkus doesn’t handle that at native image generation, or at least warn about it. So just add in your application.properties this line:
```
quarkus.native.additional-build-args=-H:DynamicProxyConfigurationFiles=proxies.json
```
and a new file proxies.json in your src/main/resources, containing exactly those interfaces the error message mentioned. Mine was:
```
[
    ["org.apache.http.conn.HttpClientConnectionManager", "org.apache.http.pool.ConnPoolControl", "software.amazon.awssdk.http.apache.internal.conn.Wrapped"]
]
```
The issue is mentioned in the Quarkus native tips page, but you’re left on your own trying to figure out WHAT and HOW to put into the mentioned file.
While we’re at application.properties, if you have any SSL connection in your code (and unless you do Hello World, you’ll have) place this line there as well:
```
quarkus.ssl.native=true
```

So, this was my adventure so far. The application works now, startup time down from 3.2s to .38s and half the memory footprint… I’m waiting for the next surprise.

Poor man’s static web site protection in AWS S3 (with Terraform)

Sorin Costea — Mon, 13 Jul 2020 21:39:00 +0000

We’re talking internet so arguably the best protection would be to not use it at all, but here we are, serving static files from AWS S3 and hoping not every site and forum is going to link to them. Why? Because we’re the ones paying the AWS bills, aren’t we.

I have this web application – you could call it SPA even though it’s little more than a REST API client – and it uses a few assets like images and the page itself (duh). So here’s the easy way to reach some security:

serve the files with a CloudFront distribution (that’s AWS talk for their own CDN)
restrict only CloudFront to read files from S3 (by setting up OAI – origin access identity)
upgrade always the connection to HTTPS and allow only GET, HEAD and OPTIONS
enable WAF (AWS web application firewall, version 2) ACL to only allow on rules
and finally, restrict that acceptable requests have a custom header with a known value

Did I say easy? WAF killed me an entire day and even now I have no idea what was initially wrong and why it works now. But here’s what works, in Terraform because I hate CloudFormation – but the concepts should be clear.

1) the CloudFront distribution itself, which will reference your S3 bucket where the desired assets lie (you already have your bucket, right?) and the soon to be defined ACL:

locals {
  s3_origin_id = "my_origin"
}

resource "aws_cloudfront_distribution" "my_distribution" {
  origin {
    domain_name = aws_s3_bucket.my_bucket.bucket_regional_domain_name
    origin_id   = local.s3_origin_id
    s3_origin_config {
      origin_access_identity = aws_cloudfront_origin_access_identity.my_oai.cloudfront_access_identity_path
    }
  }
  web_acl_id          = aws_wafv2_web_acl.my_acl.arn
  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"
  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = local.s3_origin_id
    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
    viewer_protocol_policy = "redirect-to-https"
  }
  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }
  tags = {
    maypp = "test"
  }
  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

2) the OAI of course. It's only this, really.

resource "aws_cloudfront_origin_access_identity" "my_oai" {
  comment = "Serve securely S3 assets"
}

Just, don't forget to add it to your S3 bucket policy, otherwise nothing (good) will happen:

data "aws_iam_policy_document" "my_s3_policy" {
...
  statement {
    actions   = ["s3:GetObject"]
    resources = ["${aws_s3_bucket.my_web_bucket.arn}/*"]
    principals {
      type        = "AWS"
      identifiers = ["${aws_cloudfront_origin_access_identity.my_oai.iam_arn}"]
    }
  }
...

3) the connection and method filters can be also noticed in the CloudFront distribution definition.

4) The WAF2 access control list (ACL for the advanced). This is where most of my time got burned, maybe there are better ways to do it but heck if I want to invest more sweat any time soon into it.

Notice it's a "CLOUDFRONT" type and even if CloudFront is global, it MUST be in the us-east-1 region. For this I needed the multi-provider Terraform hack, see below. It also needs for everything and its mother (see also next point) a mandatory "visibility_config" block even if you don't need metrics right now, because if AWS is a mess, why shouldn't Terraform imitate it.

resource "aws_wafv2_web_acl" "my_acl" {
  name     = "my-acl"
  scope    = "CLOUDFRONT"
  provider = aws.us-east
  default_action {
    block {}
  }
  rule {
    name     = "listlik-acl-rule"
    priority = 1
    override_action {
      none {}
    }
    statement {
      rule_group_reference_statement {
        arn = aws_wafv2_rule_group.my_rule_group.arn
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = false
      metric_name                = "my-acl-rule-metric"
      sampled_requests_enabled   = false
    }
  }
  tags = {
    maypp = "test"
  }
  visibility_config {
    cloudwatch_metrics_enabled = false
    metric_name                = "my-acl-metric"
    sampled_requests_enabled   = false
  }
}

As mentioned, Terraform needed two providers - the regular AWS one and a special one for the global CloudFront distribution which you will always refer by alias:

provider "aws" {
  region = var.region
}
provider "aws" {
  alias  = "us-east"
  region = "us-east-1"
}

5) And finally the rule group with no geographical restrictions but a single rule, letting only requests with a custom header containing exactly a custom value. Notice that if the ACL default action (if no rule method matched) was to block, and as the rule group didn't override it, this rule's action is the only thing which can allow you receive the assets.

resource "aws_wafv2_rule_group" "my_rule_group" {
  name     = "my-rule-group"
  scope    = "CLOUDFRONT"
  provider = aws.us-east
  capacity = 2
  rule {
    name     = "my-rule"
    priority = 1
    action {
      allow {}
    }
    statement {
      byte_match_statement {
        positional_constraint = "EXACTLY"
        search_string         = "megasecretstring"
        field_to_match {
          single_header {
            name = "x-my-referrer"
          }
        }
        text_transformation {
          priority = 1
          type     = "NONE"
        }
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = false
      metric_name                = "my-rule-metric"
      sampled_requests_enabled   = false
    }
  }
  visibility_config {
    cloudwatch_metrics_enabled = false
    metric_name                = "my-rule-group-metric"
    sampled_requests_enabled   = false
  }
  tags = {
    maypp = "test"
  }
}

Now you can add to your browser an extension (like Simple Modify Headers if you use Firefox) which for a specific domain - the domain of your CloudFront distribution - will always attach to requests the header as configured above. I know I could have used the standard "X-Referrer" header but then it wouldn't be so obivous that for CloudFront it doesn't matter at all - if will filter the requests by anything you like.

(Published as part of the #100DaysToOffload challenge https://100daystooffload.com/)

AWS SDK for Java v2 - so simple they saved on documentation

Sorin Costea — Wed, 08 Jul 2020 11:04:23 +0000

The version 2 of the AWS Java SDK is much less documented than the first one. Okay it's newer so there are less blogs and projects, obviously, but finding official code examples with v2 on AWS sites is a real struggle. Luckily, using the SDK has become much simpler and straightforward.

Every service will be accessed in a pretty much similar pattern. Let's say, you want to read some data you keep in the parameter store of AWS's SSM (Systems Manager). After you include in your project the BOM of AWS for versions and the SSM dependency:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>software.amazon.awssdk</groupId>
        <artifactId>bom</artifactId>
        <version>${aws.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
  ...
  </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>ssm</artifactId>
    </dependency>
  ...

Note: the biggest challenge is to figure out what is the artifact name for a certain AWS service, there's like zero references to that. But reading through the (huge) BOM with some common sense will let you find it.

The following piece of code will let you read your encrypted parameters by path.

final AwsCredentialsProviderChain chain = AwsCredentialsProviderChain
    .of(ProfileCredentialsProvider.builder().build(), DefaultCredentialsProvider.create());
final SsmClient ssm = SsmClient.builder().credentialsProvider(chain).build();
final GetParametersByPathResponse secretsResult = ssm.getParametersByPath(
    GetParametersByPathRequest.builder().path("/your/secrets").withDecryption(true).build());

The pattern is always the same:

build a client, the AWS builder pattern will always be in the form of YourNeededClient.builder().optionaldata().build()
build a service request, again in the same pattern YourNeededOperationRequest.builder().operationdata().build()
call the operation client.operationName(request)
it will return a result of type YourNeededOperationResult where you can read the requested data. >Note: In my example the SsmClient needed also the credentials provider to grab the account key - the parameters were encrypted remember?

Your homework will be every time to search through the SDK classes: first find the client class name, find out the operation needed, deduce the request class name, and there you go. Sometimes you'll be able to find examples too, but you can try also blindly - most of the time the error messages will be pretty straightforward, like some request needs signing, or you're missing some needed role, or…

(Published as part of the #100DaysToOffload challenge https://100daystooffload.com/)

Handling unknown JSON structures

Sorin Costea — Wed, 01 Jul 2020 11:45:02 +0000

JSON object mapping, marshalling, call it whatever you want, we have you covered with Gson or Jackson. Unless you don't care about structure and want to be able to parse random JSON strings. Oops, THERE come clumsiness.

I'm sure you could

    final JsonObject json = new JsonParser().parse(yourstring).getAsJsonObject();
    final Integer start = json.has("start") ? json.get("start").getAsInt() : 0;

(made possible with Google Gson) but why not go simpler and just

    final JsonObject json = new JsonObject(yourstring);
    final Integer start = json.getInteger("start", 0);

Nice, right? And the same with arrays, just json.getJsonArray("list") with or without providing defaults... Too bad it's just part of the core Vert.x package and not a separate library you could use in any project... so if you have any vertx.core dependencies lying around, for example when using Quarkus Lambda HTTP, or don't mind an extra 1M in size, make sure you give it a try. Cleaner simply doesn't exist in the Java world, at least as far as I know.

Ah yes, and it’s a I-JSON implementation (RFC 7493, Internet JSON) so maybe some fancy number formats won’t be able to fit, but I never hit that wall.

(Published as part of the #100DaysToOffload challenge https://100daystooffload.com/)

Wishful thinking about a Tumblr API v3

Sorin Costea — Tue, 23 Jun 2020 17:43:51 +0000

Let’s say you want to read a Tumblr post information from their API v2. Nothing special at the first look, but beyond the obvious parameters, there’s an interesting one: notes_info. The API designer thought to make this optional (it defaults to false) as to not overload the server and cause unneeded traffic with all the likes and reblogs your requested post might have – especially if popular.

https://api.tumblr.com/v2/blog/your-blog-to-check/posts?api_key=0ABCDEFGH&id=12345678¬es_info=true

And how will those notes look like? Well, the API documentation forgets to document that. Its last update is from 2011, the very year where the Swagger project was started so we can forgive them for the lack of documentation. But if we quickly try the API, it will – somewhat obviously – return only the first 50 notes. Obviously, because what if the post had a million notes?

[{
avatar_shape: "circle",
blog_name: "ablogname",
blog_url: "https://ablogname.tumblr.com/",
blog_uuid: "t:kjhlIU(/OLUGu7g",
followed: false,
post_id: "9873875387587638",
reblog_parent_blog_name: "anotherblog",
timestamp: 1592801102,
type: "reblog"
},
…

Now, HOW on earth could we paginate over these notes? The obvious answer is: no way, it’s an inner structure and the REST idea doesn’t allow for that. I mean, something like

https://api.tumblr.com/v2/blog/your-blog-to-check/posts?api_key=0ABCDEFGH&id=12345678¬es_info=true&offset=50

logically would apply to the response of the call. So, whenever Tumblr does an API update, maybe 2021 to celebrate 10 years since the last one, how about they make the notes first class citizens and let one access them properly.

https://api.tumblr.com/v2/blog/your-blog-to-check/posts/12345678/notes?api_key=0ABCDEFGH&id&offset=50

And as a modern OpenAPI and documented right? Like even the petstore of Swagger is? And while we’re talking about changes, discoverability wouldn’t hurt either – add a Link header! It’s official (together with the types next/prev/first/last) so should be fairly well known, and Spring REST supports it out of the box.

Link = https://api.tumblr.com/v2/blog/your-blog-to-check/posts/12345678/notes?api_key=0ABCDEFGH&id&offset=100; rel=”next”

That was just a silly and frustrated example. It doesn’t have to be offset pagination, it could be cursor pagination or anything. Just have it there, thank you!

(Published as part of the #100DaysToOffload challenge https://100daystooffload.com/)

Vue.js if you’re not a frontend developer

Sorin Costea — Sun, 21 Jun 2020 18:30:42 +0000

Say, you want a simple web page to show you in a nice way some JSON data you loaded from a REST API. Doing it with vue.js is easy: just npm and… heck no! You definitely don’t need to install and/or learn another server stack for a few scripts on your web page. Instead include simply the vue.js in the good old traditional way, here the development version (aka not minified and with useful console logging):

<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

Then, you will use a new component to show looping over data, the pet-item which you’ll define in a second:

<div id="petApp">
    <div>
      <pet-item v-for="item in petList" v-bind:pet="item" v-bind:key="item.id"></pet-item>
    </div>
  </div>

While the pet item definition is a Vue template you will define the simplest way in a script element:

<script type="text/javascript">
      Vue.component('pet-item', {
        props : [ 'pet' ],
        template: `
        <div>
          <h3>{{ pet.name }}</h3>
          <div>ID: {{ pet.id }}</div>
        </div>
      `
      })...

Note: watch for the back quote used to define multiline strings, not all older browsers will support it.

The template will use mostly {{Mustache}} tags (except where it doesn’t, see the v-bind attributes) but even then the whole bunch will look familiar if you are used to Thymeleaf templates – if you’re coming like me from the Spring world (and will have just as Thymeleaf its peculiarities, see again the v-bind attributes).

Note: it’s important to remember that your template must have only one root element (here a div) to contain everything.

Of course in order to see anything you’ll need some data, and while you could add by hand some example data structures, why not bringing it from an API? I’ll use a simple call to the Swagger demo petstore API, namely

https://petstore3.swagger.io/api/v3/pet/findByStatus?status=available

To make REST calls from javascript using Axios is a rather trivial matter, so here is your main Vue application code fetching data with Axios (haha I called this simple thing “application”):

var petApp = new Vue({
  el : '#petApp',
  data () {
    return {
      petList: null
    }
  },
  mounted () {
    axios
      .get('https://petstore3.swagger.io/api/v3/pet/findByStatus?status=available')
      .then(response => {
          console.log(response.data)
          this.petList = response.data
      })
      .catch(error => {
        console.log(error)
      })
      .finally(() => this.loading = false)
  }
})

The only extras there is that I wanted to log to the browser console the response and the errors if any. Also, the API request will be made in the Vue mounted() function which is pretty much the most basic use case (more about Vue lifecycle here).

All this being said and done, when you load the HTML page in your browser you’ll get something working and… as ugly as this:

Works but… ew. Well, as we’re in the middle of trying things, why not throwing some Bootstrap styling around the divs and make them flowing cards? The final page is here and will look like the fragment below, flowing in 1, 2, 4 or 6 columns depending on your screen width.

See? And I didn’t even bother to create a repo for such a small thing. A gist is all that one needs to get started using vue.js. And axios.

(Published as part of the #100DaysToOffload challenge https://100daystooffload.com/)