Forem: Carmine Zaccagnino

Does Kubernetes support SELinux?

Carmine Zaccagnino — Thu, 07 Jul 2022 10:39:56 +0000

In my previous post about setting up a Kubernetes cluster using Fedora CoreOS nodes I mentioned the fact that SELinux should not be disabled when creating Kubernetes clusters.

That is in complete contradiction to what many online tutorials¹²³⁴⁵ will tell you. But why is that?

Generic "SELinux is just a PITA" myth

One reason is the idea, common among those who might have jumped across to RedHat-based system administration from other distributions, that SELinux breaks things and it's just easier to disable it. It isn't, really, not for servers. Maybe for a workstation that could be an acceptable compromise: you might do unpredictable things on it, so you might end up spending a lot of time troubleshooting a tool that feels like it's getting in the way of your work most of the time without much of a tangible security benefit.

But servers are different: you use them to perform a job that is somewhat pre-defined: you're either running software directly on it, and you should know what that software is supposed to do with the network and the file system, or you're running containers, in which case what you're doing is still somewhat predictable, and you should regulate to the extent to which the workload is predictable.

The "SELinux doesn't work with K8S because kubelet doesn't support it" myth

Another reason that originated this idea that one should disable SELinux for Kubernetes clusters is that Kubernetes specifically doesn't play nice with SELinux because the Kubernetes official kubeadm setup tutorial says so in the tab about RedHat-based distributions which states, talking about disabling SELinux, that

This is required to allow containers to access the host filesystem, which is needed by pod networks for example.

Digging deeper, one will find, however, that SELinux is being used by people in production Kubernetes clusters, and there really aren't many issues, at most what is reported is the need to set SELinux labels on a few files and directories on some setups, but other setups may not even require any additional work. You can test this yourself with the example Kubernetes setup tutorial I wrote and mentioned at the start of this post.

As Daniel Walsh himself wrote in a blog post, CRI-O integrates very well with SELinux and prevents dangerous actions like a container loading an old, unmaintained and therefore potentially vulnerable kernel module and breaking out of the isolation. Additionally, the Kubernetes API itself contains resources to specifically configure SELinux labels for containers. Doesn't sound like something they would do for a tool that "doesn't work with Kubernetes", according to some. Also, the CNCF security whitepaper mentions SELinux as a tool that can be used to provide isolation and limit privileges, which is as much as we could expect from an high-level, architecturally-minded document.

Kubernetes DOES work with SELinux enabled, so you shouldn't disable it, certainly not before even trying

In conclusion, try things for yourself before giving up on a tool that could end up providing a critical security benefit. If you want to share a story about your own experience with SELinux and Kubernetes, it would be really appreciated in the comments to this post here on dev.to or directly to my email carmine@carminezacc.com

Creating a Kubernetes Cluster with Fedora CoreOS 36

Carmine Zaccagnino — Sat, 02 Jul 2022 08:51:07 +0000

In this post I'm going to explain how to create a Kubernetes 1.24 cluster on Fedora CoreOS 36 nodes.

I will assume that, if you're reading this, you already know that Fedora CoreOS is a great choice as a Kubernetes node OS because of both the ease of maintenance provided by RPM-OSTree and Zincati and the really easy way to automate provisioning of new nodes thanks to the use of Butane and Ignition.

I believe it is necessary to write a tutorial on this because existing tutorials on this topic are somewhat outdated and, in my opinion, fail to address some aspects, even though they're really good in many ways (the one linked here is very good in my opinion for example).

In particular, I'm going to show a multi-node cluster that keeps the taint on the control plane and, to give an example that can be directly replicated, I'll provide scripts that aid in creating virtual machines for the nodes using libvirt. You can, of course, apply just Ignition scripts and node configuration steps to your environment if that's what you're looking to get from this tutorial.

Preliminary considerations about container runtimes and SELinux

The aforementioned existing tutorial on creating Kubernetes clusters with Fedora CoreOS chooses to use CRI-O instead of the preinstalled containerd runtime. I believe this choice merits some further attention, even though I agree that it's the correct choice.

CRI-O's strengths are in added features, particularly the integration with SELinux (but that is disabled in that tutorial) and the fact it's the same runtime used by OpenShift, but it is slower than containerd, even if marginally, as the linked paper shows, so one could be tempted to just stick with containerd.

My experience with the exact setup that will be shown in this tutorial, even if one disables SELinux by overriding /etc/selinux/config in the Ignition file, is that the choice to use containerd results in a really unstable and unusable cluster, and that's why I'll be showing steps to install and enable CRI-O instead in this tutorial.

I will not be disabling SELinux, on the other hand. That's because, in the current state and for what I've seen, there's no need for that and I'll gladly take the increased security, even if it means having to troubleshoot the few instances in which it gets overzealous, and doing that with setroubleshootd (that can be installed on Fedora CoreOS using rpm-ostree as part of the setroubleshoot package) it's not hard at all.

Creating a virtualized Kubernetes cluster using Fedora CoreOS VMs

For the full example, we are going to create a three-node cluster with one control plane and two workers, which is the least demanding sensible (even though it misses out on HA) virtualized setup that even a mid-range laptop could run, as long as it runs a (ideally RedHat-based) Linux distribution with podman, libvirt and virt-install.

Another prerequisite is an extracted qcow2 image of Fedora CoreOS, which can be downloaded as an XZ archive from the Fedora CoreOS official website, or retrieved by coreos-installer.

The steps have been tested on x86 systems with Fedora Workstation 36 and Red Hat Enterprise Linux 9 as the host operating system.

Create an Ignition script

To inizialize the VM, a JSON Ignition script is used, which can be derived from the following fcos.bu YAML file using Butane:

Before doing that, generate an SSH key pair using ssh-keygen or locate an existing one you'd like to use for the VMs we're about to create and replace <PASTE YOUR SSH PUBLIC KEY HERE> in fcos.bu with the public key content, all on one line.

Use the butane OCI container to generate the Ignition file by running


podman run --interactive --rm \
quay.io/coreos/butane:release \
--pretty --strict < fcos.bu > fcos.ign

Take note of the path of the generated fcos.ign file, and set it as the value assigned to the IGN_CONFIG variable in the following file, which I'll refer to as start_fcos.sh from now on:

In that file, also change the IMAGE variable to the path to the downloaded QCOW2 Fedora CoreOS image (e.g. $HOME/Downloads/fedora-coreos-36.20220505.3.2-qemu.x86_64.qcow2).

In three different terminals or tmux panes or windows run ./start_fcos.sh 1, ./start_fcos.sh 2 and ./start_fcos.sh 3 to create three nodes called node1, node2 and node3. The Virtual Machine Manager (virt-manager) GUI tool can be used to manage these three VMs after the initial setup.

Look for lines like


Fedora CoreOS 36.20220505.3.2
Kernel 5.17.5-300.fc36.x86_64 on an x86_64 (ttyS0)
SSH host key: SHA256:70h+0L1lAfXChOpmBH1odArSLRCMJY2v9sOM45XThyM (ECDSA)
SSH host key: SHA256:M3Tcq1tebp+uFKAXqo6kD+PWIzzz03ndwreIEhFR5IQ (ED25519)
SSH host key: SHA256:EnywjztiwTBK9nLy47wj/gaus3wgAflI11j2ckXE0QM (RSA)
enp1s0: 192.168.122.146 fe80::cc38:c8c:7c38:c0fc

in the three terminals and add the IP addresses to /etc/hosts on the host system like in this example:


192.168.122.146 node1
192.168.122.96 node2
192.168.122.87 node3

to then be able to more easily access the nodes from the host PC.

Log in via SSH as the core user on the three nodes (for example in three panes in another tmux window) using ssh core@node1, ssh core@node2 and ssh core@node3.

Set the hostname on each node to node1, node2 and node3 by creating the /etc/hostname file on each as root, for example like this in the first node (run the two commands one by one or it won't work):


sudo -i # become root
echo "node1" > /etc/hostname # set the hostname

On the first node (which will be the cluster's control plane) install CRI-O and the required tools to create and manage the cluster with:


sudo rpm-ostree install kubelet kubeadm kubectl cri-o

On the other nodes, only the CRI-O runtime, kubelet and kubeadm are needed, and they can be installed with:


sudo rpm-ostree install kubelet kubeadm cri-o

reboot using sudo systemctl reboot to apply the hostname change and the updates (Fedora CoreOS uses OSTree which only updates system files on reboot to ensure atomic updates).

After the reboot, log in to all the nodes again and start CRI-O and kubelet using


sudo systemctl enable --now crio kubelet

Create a clusterconfig.yml on the control plane just like the following (using vi in the SSH console for example):

and then run:


kubeadm init ––config clusterconfig.yml

to initialize the cluster.

After it's done, configure kubectl on the control plane by running the suggested commands:


mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

The ~/.kube/config file can be copied to the host system as well to be able to run kubectl commands on the host directly instead of logging in to the control plane via SSH.

Set up Pod networking with kube-router, which is on the simpler side of CNI plugins without missing out on important features, by running:


kubectl apply -f \
https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml

Add the other nodes (node2 and node3 in our example) as workers to the cluster by running on each (as root, therefore with sudo) the kubeadm join command shown at the end of the kubeadm init output. If it was lost, you can run:


kubeadm token create –-print-join-command

to have kubeadm generate a new token and get a new join command.

If all was done correctly, the cluster should be ready for action. Confirm this by running kubectl get nodes and verifying that all three nodes are shown as Ready.

You can create a test deployment of three NGINX instances with:


kubectl create deployment test --image nginx --replicas 3

and a Service to be able to access it externally (in a file called testsvc.yml, for example):


apiVersion: v1
kind: Service
metadata:
  name: testsvc
spec:
  type: NodePort
  selector:
    app: test
  ports:
    - port: 80
      nodePort: 30001

that can be added to the cluster with kubectl create -f testsvc.yml and that allows us to test that everything works correctly by navigating to node1:30001 with a browser or cURL and verifying we get the NGINX welcome page.

Next steps

I have a few containers and Kubernetes example files of varying complexity in a GitHub repository (github.com/carzacc/thesis-files), maybe you'll find something of interest there to complement reading the official Kubernetes documentation.

In particular, in the README for directory 3/morra I show an example deployment of a REST API that interacts with a Redis store and a MySQL cluster. For production applications, remember to use namespaces and create accounts that follow the principle of least privilege.

In the past, I've been very happy to write tutorials after having a topic requested or suggested in an email. In those cases, they were Flutter tutorial ideas. The same could happen with Kubernetes as well, so feel free to write to me at carmine@carminezacc.com to ask anything.

I have a blog at carmine.dev, too, where you can also find this post!

One year of Programming Flutter, DevTalk and a 35% discount on the book!

Carmine Zaccagnino — Tue, 23 Feb 2021 17:18:51 +0000

It's been a year since the Pragmatic Programmers published Programming Flutter, my Flutter book.

There have been many people saying great things about it, and many more asking me to guide them through the Flutter journey they started by reading my book.

My blog and my presence on dev.to is designed to help with common things people want to do with Flutter, but if you have any question, in addition to emailing me at carmine@carminezacc.com, you can post about issues with the book or questions about Flutter on its DevTalk page, where you can also find a 35% discount on the price of the book.

I will resume publishing tutorials on dev.to and on my blog over the next few weeks.

The Current State of Flutter for the Web

Carmine Zaccagnino — Tue, 17 Nov 2020 20:03:46 +0000

Long time no see! It's been a while since I've last posted something on my blog, and that's been for several reasons, with the bottom line being that I've run out of ideas and haven't really had the time to sit down and think about great blog post ideas.

I'm coming back with a post that's going to be a little shallower than usual, but that I find to be important nonetheless.

If you don't follow me on Twitter, you might have missed the two articles I've written for Smashing Magazine on Flutter for Web and desktop.

Those were introductions and tutorials which didn't mention the current state of Flutter for the Web much, and this post is here to give an overview of just that.

It's split in two parts, each answering a question:

How hard is it to make it work?
How well does it work?

How hard is it to make it work?

This section is going to overlap with the first of my Smashing Magazine articles, but just a little bit.

First of all, Flutter Web development is not available on the stable channel, and this means you need to switch to the beta channel. In addition to that, you need to run the

$ flutter config --enable-web
~~~

command to enable Web development, but you probably already knew all of that. Still, I can't really take anything for granted when I'm writing to the whole of the Internet, and I'm already making it hard enough to understand what I'm talking about to people who don't even know what the heck Flutter is, and if that's you I know a book you should read. Ask me about that, or maybe just take a look at [my Twitter @carminezacc](https://twitter.com/carminezacc) or [my blog at carmine.dev](https://carmine.dev).

Anyway, after you've done that the Web browser will become a device Flutter will try to use to debug and you will be able to run `flutter build web` to get a bundle delivered to the `build` folder containing what the browser needs to show your beautiful Web app to your users, in particular your Dart code will be compiled to JS and the `index.html` file will be built based on the `index.html` in the `web` directory, which is the Web equivalent of the `android` and `ios` directories: you can modify it to change the app name and favicon, for example.

One thing you might not know is that Flutter for the Web has another build target: a WASM target using Skia running on WebGL.

# How well does it work?

That build target is as experimental as it gets, and it currently causes some very severe rendering issues on some clients that means it's completely not fit for a production app that's meant to be used on devices that you don't have complete control over.

On the other hand, the Skia target is the one that will usually cause fewer issues overall with the app and will give a more predictable, mobile-like behaviour on the devices it works well on.

Just use the JS target if you need to support any device.

Talking about how well the app works, I also have to mention that the initial loading time can be quite slow, and you may find it unacceptable, so check it out with something simpler before you invest too much time into a project.

Also, `TextField`s sometimes don't get in focus again right away when clicking on them after they go out of focus.

There are some general usability tradeoffs that need to be kept in mind, especially when running the Web app on desktop devices. You won't get a scrollbar from the browser because Flutter handles scrolling itself, so you need to create a scrollbar yourself, perhaps aided by something like the [draggable_scrollbar package on Pub](https://pub.dev/packages/draggable_scrollbar).

Another one is that text isn't even selectable by default. You can use `SelectableText` instead of `Text` to fix that, but the users still won't be able to copy the text so it's not going to cut it for a blog or other text-rich websites.

An easily fixable drawback is the lack of routing. Even named routes don't really cut it if you show content from a database on different pages: everything is still passed under the hood and not through the URL. That's very easily fixable using the [fluro package](https://pub.dev/packages/fluro).

In general, you'll have to think about other differences  between mobile apps and websites, for example clicking and dragging has the same effect as tapping and dragging on a mobile device, and Flutter doesn't allow you to handle scrollwheel scrolling events differently than dragging events.

Also, if you use cookies, remember to use the `BrowserClient` and to set [the `withCredentials` option](https://pub.dev/documentation/http/latest/browser_client/BrowserClient/withCredentials.html) to `true`, otherwise they won't be stored for subsequent requests.

# Conclusion

Flutter can be used successfully to build Web apps, but it's still got a few drawbacks. It's up to you to decide whether or not it's a good fit for your next project but, whatever you decide, remember that Flutter is still in very quick development and the situation may get better at any point.

Securely Storing JWTs in (Flutter) Web Apps

Carmine Zaccagnino — Wed, 29 Apr 2020 13:50:26 +0000

I recently wrote a post about how to implement JWT Authorization in Flutter apps. I only considered the use case of writing a mobile app, so I recommended the use of the flutter_secure_storage package to store the tokens.

As it later emerged, some people wanted to use that tutorial as a guide for Flutter Web apps. flutter_secure_storage doesn't work for Web apps.

This first post about this topic will simply look to address that, later I'll post a more general overview of what needs to be taken in consideration when writing cross-platform apps in Flutter, including a deeper dive into storage on the different platforms. This will be more of a hands-on tutorial like the ones I previously posted, whereas the other one will be more of an opinion/overview post that I hope will help understand the thinking that is required before trying to deploy on multiple platforms.

For the sake of keeping each post focused, I'll keep this one more practical and focused on how to make that example work on the Web.

The Basic, Compromising, Simple Approach

The simple solution to that problem that will work on every platform is to use the shared_preferences package, which uses SharedPreferences on Android, NSUserDefaults on iOS and localStorage on the Web.

This is actually only one half of a solution, as using localStorage means that the value can be retrieved by any JS (or Dart code compiled to JS like Flutter Web code) on your page. This means you have to be extra careful with user input to avoid XSS attacks, and that comes into play especially if you have non-Flutter Web content on the same domain (which can access the same localStorage), which can access the same data.

Also, you need to keep in mind that the user can actually very easily access the token through JavaScript, so if their end gets compromised in any way that token can be easily read.

This should already give you an idea of the kind of issues you might have to deal with when writing cross-platform apps. Also, especially NSUserDefaults on iOS is not supposed to be used for sensitive information (nor is SharedPreferences actually), so you should use flutter_secure_storage on those platforms anyway, and at that point you can just use dart:html directly for the Web part and skip having shared_preferences as a dependency entirely.

The Better Approach

flutter_secure_storage on mobile should be your first and only choice. It uses the proper Keychain API on iOS and it encrypts the data, stores the encrypted data in SharedPreferences and the cryptographic key is stored in the Android KeyStore, which is a safe approach.

On the Web though, you need to use a Web-based solution, so you need to think about our Flutter app as if it was any old boring HTML, CSS and JavaScript website.

The place where tokens are stored in Web apps are httpOnly cookies, which are sent to the backend automatically along with each request, but aren't accessible by JavaScript.

The issue with that is that automatically part. It makes you vulnerable to CSRF, which is an attack that sends requests to your server from one of your users clients when they visit a page that isn't yours. GET requests are particularly vulnerable because a GET request query is just a link that can be clicked by your users.

This can be prevented by having another token (which shouldn't be the same token you use for authorization, obviously, but it can be generated based on that) that is stored in localStorage (so only your website's code can access it) and send that along with each request in a dedicated header.

You still MUST NOT be vulnerable to XSS because, even though your token can't be read, an attacker can still send requests through your own page, take your CSRF token, and bypass your CSRF protection entirely, but at least the JWT isn't in their hands so they haven't permanently stolen your user's identity. Escape all user-provided data before ever doing anything with it both on the front-end if you have another website running and on the back-end when you put data in a database: many libraries to interact with databases have that feature built-in, you just need to use them properly instead of just concatenating strings. If you really have to use string concatenation because of your stack, remember to sanitize the input before doing anything with it.

Now, let's get hands-on and see the code needed to make everything work!

Putting It In Practice

If you're new to my posts (and there will be a few of you), you might not be aware of my earlier post about JWT authentication with Flutter and Node (which supposed you were writing a mobile app), which I'll use as a starting point, and that you therefore should at least be aware of in case something confuses you. I won't be starting from scratch here.

The Node Side

Before we can build the app, we need to get the backend API straight. Remember, I won't explain the stuff I already covered in my previous post. The starting point is this repository

carzacc / jwt-tutorial-backend

Backend for a blog post about User Authentication+JWT authorization with Node and Flutter

The code we're going to end up with is in this repository

carzacc / jwt-tutorial-backend-web

The usual Node imports and the signup route don't require any changes:

The login route, though, is where the fun part starts (you're reading this because you find this all fun, don't you?). The way I'm going to do this is the following: I'm going to generate two tokens: an access token and a an anti-CSRF token, and we're going to send the first as a cookie and the second in the response body. I'm not setting the Secure flag because this code isn't meant for production, but that should be set in production code given that your app would run with TLS in a production environment:

The data route needs to get both values, one in the cookies and one as a header in order to work:

and here is the entire index.js:

The Flutter Side

On the Flutter side, the starting point is this repository

carzacc / jwt-tutorial-flutter

https://carmine.dev/posts/jwtauth/

The code we're going to end up with is in this repository

carzacc / jwt_tutorial_flutter_web

The approach is going to be the following, in order to make it as obvious as possible we're actually building a Web app: the JWT is going to be in the cookies, so it's beyond our control, whereas we're going to store the anti-CSRF token in the localStorage directly using dart:html.

This means that we are going to add to our imports import 'dart:html' show window; and take out the flutter_secure_storage dependency given that we are not using it:

MyApp is, as always, where we decide whether we need to show the data page or the login page. In order to change as little as possible from the original, I switched the home from a FutureBuilder to a Builder (we don't need Futures in the case of HTML localStorage) and moving from calling a jwtOrEmpty getter to generating our very own csrfTokenOrEmpty. The rest stays the same: if it's expired, the access token has expired too, so we need the user to log in again, if we don't have one we need to show the user the login page:

The LoginPage gets changes in the callback to log in, as that needs to store the JWT to local storage too.

window.localStorage can be accessed just like any Map like you see in the following snippet we're going to use in the login page:



var username = _usernameController.text;
var password = _passwordController.text;
var jwt = await attemptLogIn(username, password);
if(jwt != null) {
  window.localStorage["csrf"] = jwt;
  Navigator.push(
  context,
  MaterialPageRoute(
    builder: (context) => HomePage.fromBase64(jwt)
  )
);

I kept the variable names as they were for maximum comparability with the previous post.

here's the entire LoginPage:

The data (home) page is going to be the simplest one, as all that needs to change is the name of the header at which we send the anti-CSRF token, given that the access token is sent along with the request as a cookie automatically and the rest it taken care of by the backend:

Here's the full main.dart for that:

In order to make that Flutter app look and behave nicer on bigger screens and browsers in general, you might want to check out the tutorial on responsive and Web development with Flutter I wrote for Smashing Magazine.

Onwards: Your Next Steps

You might have found this post useful, and perhaps you'd like to see more Flutter content from me. What you can do is:

follow me on Twitter @carminezacc;
subscribe to my newsletter
check out my blog at carmine.dev;
check out my book, for which paperback copies are available in many places, including Amazon (when and if they deliver given the current pandemic).

Flutter Notifications Without Firebase

Carmine Zaccagnino — Sat, 28 Mar 2020 14:03:15 +0000

We are going to discuss how to display notifications using the flutter_local_notifications plugin.

As always with these posts, you can be sure you've got all of the basic knowledge you need by reading my Flutter book, but not all of you like that way of learning, so I'll list the topics which are considered prerequisites for this post.

For the local notifications part, you need to know the following:

basics of Flutter app development, including knowledge of basic Material Design widgets, but also UI composition and basic state management;
asynchronous programming with Streams and listening to them (StreamSubscription);

The backend for our app will be the one we wrote for the previous post in the series. The app itself will be based on that, so I highly recommend you read the last part of that post if you want to understand how we've got topics a fully working example app at the end of this post. One way or another, here's the GitHub repository with the example Flutter code:

carzacc / flutter_notifications_example

Flutter app sending notifications used for a carmine.dev blog post about Flutter local notifications

and, for your convenience, here's the repo for the Node.js backend code:

carzacc / websocketsbackend

Backend for a Flutter app used as example code in a carmine.dev blog post about WebSockets

The flutter_local_notifications Package

In Flutter apps, you can show notifications to the user while the app is running using the flutter_local_notifications package. It is fairly easy to use.

Initializing the Plugin

Before being able to use the plugin, you need to initialize it. This requires two different configuration steps: Android configuration and iOS configuration. Even though this is platform-specific, this is all done in Dart code. More specifically, plugin initialization works the following way:

FlutterLocalNotificationsPlugin notifications = FlutterLocalNotificationsPlugin();
AndroidInitializationSettings androidInit = /* ... */;
IOSInitializationSettings iOSInit = /* ... */;
var initSettings = InitializationSettings(androidInit, iOSInit);
notifications.initialize(initSettings);
~~~

Now we are going to focus on `AndroidInitializationSettings` and `IOSInitializationSettings`.

## Android Initialization Settings

Android configuration requires the creation of a drawable asset to use as the app icon displayed in the notification. To do that in Android Studio, get to the `android/app/src/main/res/drawable` directory in the left *Project* panel, right-click, and select New->Vector Asset. This will guide you through the creation of a drawable vector asset.

Take note of its name because, in order to initialize the `flutter_notifications` package, you need an `AndroidInitializationSettings` object, which is created in the following way:

var androidInit = AndroidInitializationSettings('name_of_the_drawable');


## iOS Initialization Settings

The configuration for iOS is at the same time simpler and harder: there is no required argument, but there are a bunch of optional ones, which are fine to be left to default values and that you can find on the [official API reference for the package](https://pub.dev/documentation/flutter_local_notifications/latest/flutter_local_notifications/IOSInitializationSettings-class.html). By default, it will ask the user to give permission to the app to show notifications when the plugin is initialized.

This means you can get a simple {% raw %}`IOSInitializationSettings` with default settings with

var iOSInit = IOSInitializationSettings();


## Showing Notifications

The notifications can be shown with {% raw %}`plugin.show(id, title, body, NotificationDetails);`.

`title` and `body` are self-explanatory, `id` can just be set to 0.

`NotificationDetails` is constructed with ` NotificationDetails(AndroidNotificationDetails android, IOSNotificationDetails iOS) `. The required (positonal) arguments for the `AndroidNotificationDetails` constructor are `AndroidNotificationDetails(String channelId, String channelName, String channelDescription)`, whereas the `IOSNotificationDetails` constructor has no required parameters. Both take many optional named arguments, which I won't cover here (also because I can't be sure they will stay the same for long and we won't use them in this tutorial), but that you should check out on the official API reference for the plugin ([click here to see the options for iOS](https://pub.dev/documentation/flutter_local_notifications/latest/flutter_local_notifications/IOSNotificationDetails-class.html) and [here for those for Android](https://pub.dev/documentation/flutter_local_notifications/latest/flutter_local_notifications/AndroidNotificationDetails-class.html)).

The `AndroidNotificationDetails` constructor requires all of the arguments Android requires to show notifications. More specifically, Android Oreo (8.0, API level 26) and successive releases allows users to have different settings for different notification channels originating from the same app. The `channelId` can be any integer, you use the same number for notifications to be sent on the same channel and you use different numbers for different channels. `channelName` and `channelDescription` are names the user will use to differentiate your app's channels, so they should be descriptive of the purpose of each notification channel if you plan to use multiple channels (e.g. a social networking app could have a channel for follow requests, one for direct messages received, one for likes to posts, etc.).

Here's what the app-level notification settings look like:

![](https://carmine.dev/img/notificationsettingschannel.png)

and here's what the channel-specific settings look like:

![](https://carmine.dev/img/notificationsettingsapp.png)

Here's an example, where `notifications` is the `FlutterLocalNotificationsPlugin` object:

void showNotification(String title, String body) {
notifications.show(0, title, body, NotificationDetails(
AndroidNotificationDetails(
"my_app_channel_id_0",
"User-Visible Notification Channel Title",
"Useful, user-visible description of the notification channel"
),
IOSNotificationDetails()
));
}


# Using It In The App

This second part of the post is going to be about using the plugin in an app, more specifically changing [the app we built in the previous post](https://www.carmine.dev/posts/flutterwebsockets/) to also display notifications to the user. If you don't want to read that but still want the code we are starting from here's the GitHub repo of the previous post's app:

{% github carzacc/websockets_flutter no-readme %}

whereas this is the one for the app we'll build in this post:

{% github carzacc/flutter_notifications_example no-readme %}

## Importing

First of all, add {% raw %}`flutter_local_notifications` to the `dependencies` in `pubspec.yaml`:


  


and import it at the start of main.dart. You'll  notice we are also importing the status codes for the WebSocket library, which we'll need when we close the connection to the server in the dispose() method of the State of the AnnouncementPage:


  


  
  
  Summary of The Changes


The AnnouncementPage becomes a StatefulWidget, we don't use a StreamBuilder, instead we wait for new data, change what's displayed and also show a notifications. here's the entire AnnouncementPage and AnnouncementPageState that we'll analyze in more detail in the next section of the post:


  


One of the changes you need to keep in mind is that we now have a text String variable that we will update as we get data from the server, and that text is what's going to be displayed on the user's screen.

  
  
  Using the Plugin


The flutter_local_notifications package has to be initialized. This can be done in multiple places. You could to do it in main and have a global variable to be able to access the notifications plugin from anhywhere within the app without having to use InheritedWidgets or the Provider. In our case, though, we don't really need that, as there really is only one widget that's going to cause notifications to be displayed, which is our app's AnnouncementPage. What we need to do is define a StreamSubscription that listens for changes in the stream received from the WebSocket and, if there are any, both updates the AnnouncementPage to show the new announcement (by calling initState and setting the text variable) and displays a notification.

All of this is done in the initState method:


  


  
  
  The New build Method


The build method now simply needs to display the text we already get using the StreamSubscription, without requiring the use of a StreamBuilder. If the connection hasn't been established yet, which would mean text is still null, we display a CircularProgressIndicator as we did when we used a StreamBuilder and we had no data yet. Given that the nickname is now defined inside the AnnouncementPage StatefulWidget definition, we need to access it using the this.nickname syntax in the onPressed callback for the FloatingActionButton that sends announcements.


  


  
  
  The dispose Method


The dispose() method needs to close the WebSocket, letting the server know it's being closed and freeing resources on both ends of the connection, and cancels the StreamSubscription because it's not necessary anymore to listen for new announcements.


  


  
  
  Wrapping It Up


That's it! The app now sends notifications when it gets new announcements (including when it's the one generating them, but for this app this is intended)!

The entire main.dart is going to be the following:


  


  
  
  Receiving Notifications in The Background


People have complained that I focused on Firebase too much in my book, so I'm trying to compensate here on my blog by focusing on more traditional backend implementations and ways to do things.

One caveat is that, for example, the only way to be able to send notifications to closed apps on both Android and iOS is to use Firebase Cloud Messaging, which can send notifications directly to Android devices (what used to be called Cloud to Device Messaging and then Google Cloud Messaging) and uses the Apple Push Notification Service to send notifications to iOS devices.

  
  
  Onwards


You can now subscribe to my newsletter to get email updates about new posts and, as always you can follow me on Twitter if you are active on there and want to be updated, and remember to check out my Flutter book in case you haven't yet.

Subscribe to my newsletter!

Carmine Zaccagnino — Tue, 17 Mar 2020 11:38:07 +0000

You can subscribe to my blog's newsletter at carmine.dev/newsletter!

At the moment it's more a mailing list I'll use to send handcrafted emails about new posts, and at the moment I'm not even doing input validation as I can filter the emails manually when I send the email since I don't expect a huge amount of subscribers (I'd be very glad to be proven wrong, though). In case you're wondering, you can't do an SQL injection attack on that form. I'm lazy but I'm not mad, and being vulnerable to SQL injection in 2020 is a sign madness and recklessness, not ignorance.

For that I've built a little Flutter web app using Cupertino Widgets so that, when I want to show people what Flutter for the Web looks like, I also have a demo of that given that my carminezacc.com Flutter home page uses Material Design widgets.

Check it out at carmine.dev/newsletter and subscribe if you'd love to receive emails about new Flutter tutorials I'll post! As always, follow me on Twitter if you prefer to get new posts delivered to you that way.

Two-Way, Real-Time Communication with WebSockets in Flutter Apps (+ Node backend Implementation)

Carmine Zaccagnino — Thu, 05 Mar 2020 18:06:03 +0000

Hi everyone, in this post I'm going to show you how to use WebSockets in Flutter apps and write a Node backend to test the app.

In this post we’re not going to worry about authentication/authorization, as that was the focus of the previous post in the series. As always, this is meant for people with a decent understanding of the basics of Flutter. I've written a book about Flutter that will get you up to speed reasonably quickly and with ease but, in case you really need to do this now and either don't like learning from the book or don't want to read the whole thing, here's the concepts I'm going to suppose you know how to use in order to follow this post:

basic structure of a Flutter app (MaterialApp, Scaffold, Column, definition of custom widgets etc.);
getting input from the user using a TextField and managing it with a TextEditingController;
basic navigation using Navigator.push;
asynchronous programming with Streams and the usage of the StreamBuilder.

WebSocket and Socket.io

This post is about WebSockets. It won't be about Socket.IO, which might be the focus of another post. WebSocket is a protocol (just like HTTP) and there are some packages and libraries to use it directly, but a very popular alternative to doing that is using Socket.io, which is a library that may or may not use WebSocket as its communication protocol, given that it has its own real-time communication engine that is used in case there is no way to establish a WebSocket-based connection.

The way Socket.io does it is rather the other way around, using its own engine to initiate the connection, upgrading to WebSocket if it's possible. This is of particular importance to web developers, whose apps may run on browsers that don't support the WebSocket API, even though this is less and less of a concern as time passes. The main difference you would notice in the example in a tutorial is that Socket.io supports server broadcasting by default, meaning you don't have to manually iterate over the connected clients to send the message to each, as that is a feature of Socket.io itself.

What We're Going to Build

A very common application for WebSockets is building a chat app. That's a very good example but, in my view, it's not a great example for a blog post, unless what one wants to teach is how to build a chat app and not how to use WebSockets. I used the example of a chat app in my book to show how to use Firebase, but that was to show as many aspects of Flutter and Firebase as possible in one example, and it is a cool example.

What I'm going to do in this post, though, is show you everything you need to know in order to build a real time app, leaving the rest to you and avoid showing how to interact with a specific database, how to build a very specific complex user interface: the example is simply going to be an app showing the latest message sent by an user as an announcement to every connected user.

WebSockets in Flutter

The web_socket_channel Dart WebSocket package is Google-developed and very easy to use. That's what we're going to use in this post.

Opening a Connection

A connection can be opened by creating an object of class WebSocketChannel, and you can connect to a WebSocket server by using the WebSocketChannel.connect contructor: channel = WebSocketChannel.connect(URI); where URI is an Uri, that you could get from a String containing an URL (something like ws://myserver.mydomain.com:3000) by using Uri.parse(URL).

Sending and Receiving Data

The WebSocketChannel.stream is used to listen for messages. As the name implies, it's a Stream, which is exactly the best data type for incoming data from a WebSocket. It returns any new messages coming from the WebSocket as soon as they are received.

The WebSocketChannel.sink is used to send messages. As the name implies, it's a StreamSink. If you've read my book or have worked with the Firebase Cloud Firestore before, this is used in a similar way to the Firestore's CollectionReference object: WebSocketChannel.sink.add(data) sends data through the WebSocket.

Closing the Connection

If channel is the WebSocketChannel, you can close the connection usingchannel.sink.close(statusCode);. A list of status codes is available in web_socket_channel's status.dart:

  @override
  void dispose() {
    super.dispose();
    channel.sink.close(statusCodes.goingAway);
  }
~~~

## Building an Example App

You can find the complete source code for this app [on this GitHub repository](https://github.com/carzacc/websockets_flutter).

Let's start with the `pubspec.yaml`, which needs to have as a dependency the `web_socket_channel` package:


  


In lib/main.dart we're going to import package:web_socket_channel/web_socket_channel.dart to use the WebSocketChannel, then we set the server IP and port, and then start an app that has as its home page a class called FauxLoginPage:


  


  
  
  The FauxLoginPage


The FauxLoginPage is going to be, as the name implies, a fake login page: it's not going to be a proper login page for the user to authenticate, but just a page for the user to set an username. As I wrote above, we're not going to worry about authentication because that was the focus of the previous post. If you know how to use TextFields (and especially if you're familiar with the Firebase chat app example in my book, which has a login page that works a bit like this one but actually authenticates the user) this is all going to be self-explanatory and simple:


  


The AnnouncementPage is going to simply be a StatelessWidget: we're going to let a StreamBuilder take care of the changes in values returned by the Stream of data from the WebSocket. Below the text coming from the WebSocket, we're going to have a TextField that allows the user to send a message. We convert the data to a string so that it could technically be anything, and be shown to the user as is, to make debugging easier:


  


The entire main.dart is going to be the following, then:


  


  
  
  Building the Backend for the App


We're going to build the backend for the app with Node.js and the ws npm package.

  
  
  The ws Package


There's a very popular and easy-to-use WebSocket client/server package for Node called simply ws, so you can install it using

$ npm install ws


You can start a WebSocket server that listens to a given port with the following code:{% raw %}

var server = new WebSocket.Server(
{
port: port,
}
);


you can wait for a connection and define a callback to be ran when a client connects with the following code:{% raw %}

server.on('connection', function connection(client) {
// code to execute when a client connects
});


This gives us a {% raw %}`client` object we can use to send messages to the connected WebSocket client using `client.send()`:

client.send(msg);


We can also listen for messages sent by the client over the WebSocket and run a function when that happens:{% raw %}

client.on('message', function incoming(message) {
// code to execute when a message is received
});


An useful member of the {% raw %}`server` object is `server.clients`, which is an array of the connected clients. This means we can send a message to each connected client with the following:

for(var cl of server.clients) {
cl.send(message);
}


### Implementing the Backend

You can find source code for the backend at [this GitHub repository](https://github.com/carzacc/websocketsbackend).

The first thing we need is to import the *ws* package:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=imports.js %}

Then set a port and start the WebSocket server:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=startserver.js %}

let's also define a default message to send to the client the first time:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=letmsg.js %}

When a client connects for the first time, we send them that message so the client has something to display to the user when they connect:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=connection.js %}

Now, let's handle the reception of a message:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=onmessage.js %}

What we should do is broadcast the received message to all connected clients:

{% gist https://gist.github.com/carzacc/430d50943715dfbde2bd2082992af9a3 file=broadcast.js %}

If we also log to console each received message the final {% raw %}`index.js` is the following:


  


As always, if you enjoyed this post, consider following me on Twitter @carminezacc.

User Authentication + JWT Authorization With Flutter and Node

Carmine Zaccagnino — Tue, 18 Feb 2020 15:37:55 +0000

Cover Photo by James Sutton on Unsplash

The series of posts about advanced networking topics applied to Flutter apps continues. As always, this is meant for people who already have a good understanding of Flutter and know how to use Flutter widgets and the basics of the http library.

That's the kind of stuff you can learn by reading my Flutter book.

In particular, this post supposes you know how to make HTTP requests, how to use the most basic widgets (Scaffold, Column, Text, FlatButton, etc.) and that you know how to use a TextField with a TextEditingController, the basics of asynchronous functions and Futures and how to use them with a FutureBuilder, how to display dialogs and how to work with JSON.

You can learn about them online too, if you hate books. I won't be judging you.

Regarding the backend, I'm going to suppose you know about how to use the Express Node.js framework, and that you know how to use basic SQL commands like CREATE, INSERT, and SELECT.

What We’re Going to Build

The app we’re going to build is the simplest example of an app that requires authentication: it allows anyone to sign up, and any logged in user can access a piece of data. We’re going to implement the back-end with Node and the front-end with Flutter.

What is JWT

JWT (JSON Web Token) is a standard that specifies a very secure way to transmit session tokens between an user-accessible front-end (that we’ll write using Flutter) and a back-end (that we’ll write using Node).

Unlike a more traditional user session implementations, in which the session token is stored both on the server and on the client, the client sends the token along with every request and the server can check whether a session exists with that token for that user and decide whether to grant access based on that and what the user is actually allowed to do.

JWT is different. The server doesn’t store the token: at the time of authentication, it sends a signed token, but it doesn’t store it, instead relying on the signature it attaches to the token (obtained either with RSA, ECDSA or HMAC with SHA256 usually), which allows it to verify both the authenticity of the token and whether it was tampered with.

This means the token's payload can contain both data the front-end needs, since it can be freely accessed by it, and data (like the user name/ID and/or an expiration date) the server needs to validate the request and the token.

The actual structure of the JWT is made of three base64-encoded strings separated by a . character: the first contains information needed to verify the signature, the second contains the payload, the third contains the signature.

Analyzing an Example

I've taken an example of a JWT generated by the backend we'll build as an example in this post. It is eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXJuYW1lIiwiaWF0IjoxNTgxOTY2MzkxLCJleHAiOjE1ODMyNjIzOTF9.IDXKR0PknG96OyVgRf7NEX1olzhhLAiwE_-v-uMbOK0.

If you pay attention, you'll notice there are two dots. The first (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) can be decoded to ASCII to {"alg":"HS256","typ":"JWT"}, which is a JSON object, which can be formatted like this:

{
  "alg": "HS256",
  "typ": "JWT"
}
~~~

`HS256` is short for `HMAC`+`SHA256`, and `typ` is quite self-explanatory, it tells us what the string we're looking at is.

The second string (`eyJ1c2VybmFtZSI6InVzZXJuYW1lIiwiaWF0IjoxNTgxOTY2MzkxLCJleHAiOjE1ODMyNjIzOTF9`) can be decoded and formatted to:

{
"username": "username",
"iat": 1581966391,
"exp": 1583262391
}


This is a JWT for an user called {% raw %}`username`, issued at (`iat`) second 1581966391 after the Unix epoch (the 17th of February 2020 at 19:06) and that expires at (`exp`) second 1583262391 (03/03/2020 at the same time as when it was created).

The third string is just the signature obtained as an HMAC with SHA256.

# Our API Interface

Our backend is going to have three routes:

* `/signup`, which accepts POST requests in urlencoded format, containing two self-explanatory text fields: an *username* field and a *password* field and either responds with status code 201 if it was able to create the user, or status code 409 if it wasn't; 
* `/login`, which accepts POST requests in urlencoded format and accepts the same fields as `/signup`, and either responds with status code 200 and the JWT in the body of the response, or with status code 401 if there is no user with the given username and password;
* `/data`, which accepts GET requests, which must have a JWT attached to the `Authorization` request header, and which will either return the "secret data" only authenticated users can access (with status code 200) or a response with status code 401, meaning the JWT is invalid or has expired.

# Implementing the Front-End App with Flutter

You can find the code for this Flutter app [on GitHub by clicking here](https://github.com/carzacc/jwt-tutorial-flutter).

## Using The flutter_secure_storage Package

The *flutter_secure_storage* package is very easy to use: it's simply key-value pair storage, but using iOS's Keychain directly or by encrypting the data, storing the encrypted data in Android's Shared Preferences.

You can write the *myvalue* and associate it to the *mykey* key using it by using `storage.write()` in the following way:

var storage = FlutterSecureStorage();
storage.write(key: "mykey", value: "myvalue");


{% raw %}`storage.write` is asynchronous (it has a return type of `Future<void>`), so you should use `await` if you need to pause execution while it executes.

You can read the value associated to the *mykey* key by using `storage.read()`, which is also asynchronous, so you need to wait for it to return in order to be able to read the value.

var storage = FlutterSecureStorage();
var value = await storage.read(key: "mykey");


You can use {% raw %}`storage.delete()` to delete a value (it's also asynchronous):

var storage = FlutterSecureStorage();
storage.delete(key: "mykey");


Two methods exist, called {% raw %}`readAll()` and `deleteAll()` (both asynchronous), which respectively return a `Map` of all the stored values and delete all of the stored values.

## Implementation

The Flutter app doesn’t need to be particularly complicated to be able to work with JWT: it’s mostly about writing an authentication flow, storing the JWT token and sending it with each request.

In addition to that, for this example we’ll check whether the token has expired on the front-end and we’ll show the username after the user logs in, so we’ll actually have to decode the payload. 
We are going to store the JWT using the *flutter_secure_storage* package, which is the simplest way to access the secure storage interfaces provided by iOS and Android from a Flutter app.

Here are two screenshots of what we want to achieve:

![](https://carmine.dev/img/Screenshot_1581601687.png)

![](https://carmine.dev/img/Screenshot_1581601694.png)

Add the *flutter_secure_storage* and *http* packages to the app's dependencies in `pubspec.yaml`:

 
  


Then, set the minimum supported Android version to SDK level 18 (Android 4.3) because that's required by flutter_secure_storage.





  



Create the usual lib/main.dart, import the packages, initialize a FlutterSecureStorage object and insert the IP and port where the Node server backend will be running, so that we can use that going forward without having to change anything else from the example code I provided:





  



  
  
  The Structure of Our Flutter App


The structure of our Flutter app is going to be the following:


the MyApp class, which is going to check whether the user has previously logged in, and decide whether to run the LoginPage or the HomePage;
the LoginPage is where we are going to allow the user to log in or sign up;
the HomePage is where we are going to show the user the secret data that can only be accessed by logged-in users. The HomePage needs to be able to be constructed from either just the JWT Base 64 string


  
  
  Creating a Log-In Page


The MaterialApp object we're launching is called MyApp, but we'll worry about that later, given that it needs to check whether we're already logged in, and then choose whether to display a log-in page or the home page.

That's a bit boring to worry about now, let's build some UI and create a log-in page!

The log-in page itself will be a StatelessWidget called LoginPage:

class LoginPage extends StatelessWidget {
}


The nature of the login page and our implementation means we are going to make extensive use of dialogs. This means we'll create a helper method in order to make everything more succint:{% raw %}

void displayDialog(BuildContext context, String title, String text) =>
showDialog(
context: context,
builder: (context) =>
AlertDialog(
title: Text(title),
content: Text(text)
),
);


We'll also create methods that attempt to login and signup the user, and they're very simple POST requests, as we saw earlier on when we talked about our app's API interface.

We'll return a string for the login method, which will be {% raw %}`null` in case of an error (i.e. wrong username/password) and the JWT if the authentication process succeded:

Future attemptLogIn(String username, String password) async {
var res = await http.post(
"$SERVER_IP/login",
body: {
"username": username,
"password": password
}
);
if(res.statusCode == 200) return res.body;
return null;
}


The sign-up method doesn't actually have to return anything useful to the app, so we can just return the status code and deal with that later to establish whether the operation was successuful or not:{% raw %}

Future attemptSignUp(String username, String password) async {
var res = await http.post(
'$SERVER_IP/signup',
body: {
"username": username,
"password": password
}
);
return res.statusCode;

}


Here comes the fun part!{% raw %}

@override
Widget build(BuildContext context) =>
Scaffold(
appBar: AppBar(title: Text("Log In")),
body: /* TODO:INSERT BODY HERE */
);


what's the {% raw %}`body` going to be? A `Column` with two `TextFields` that allow the user to insert username and password and two `FlatButton`s: one to log in and one to sign up. We'll also add some padding around it given that it looks horrible to my eyes without it:

body: Padding(
padding: EdgeInsets.all(8.0),
child: Column(
children: [
TextField(
controller: _usernameController,
decoration: InputDecoration(
labelText: 'Username'
),
),
TextField(
controller: _passwordController,
obscureText: true,
decoration: InputDecoration(
labelText: 'Password'
),
FlatButton(
child: Text("Log In"),
onPressed: /* TODO:HANDLE LOG IN /
),
FlatButton(
child: Text("Sign Up"),
onPressed: / TODO:HANDLE SIGN UP */
)
)
]
)
)


The {% raw %}`labelText` in the `InputDecoration` is the nicest looking way to tell users what each `TextField` is for.

Define the `_usernameController` and `_passwordController` `TextEditingController`s  somewhere in the class definition, like this:

final TextEditingController _usernameController = TextEditingController();
final TextEditingController _passwordController = TextEditingController();


Let's worry about the function to handle logging in, which needs to call the {% raw %}`attemptLogIn` method with the `username` and `password` taken from the `TextEditingController`s, then check the JWT returned by the `attemptLogIn` method. If it is `null`, we need to display a dialog to inform the user we were unable to log them in. If it isn't, we can switch to the `HomePage` and save the JWT:

onPressed: () async {
var username = _usernameController.text;
var password = _passwordController.text;

var jwt = await attemptLogIn(username, password);
if(jwt != null) {
storage.write(key: "jwt", value: jwt);
Navigator.push(
context,
MaterialPageRoute(
builder: (context) => HomePage.fromBase64(jwt)
)
);
} else {
displayDialog(context, "An Error Occurred", "No account was found matching that username and password");
}
},


The function that handles sign-up is going to be complicated by the checking of a few conditions.

We are going to check on the front-end that the user doesn't try to use un username or password less than 4 characters long. This should also be done on the back-end, but this tutorial focuses more on Flutter than it does on Node, so we're just going to do this on the front-end.

If those two inputs are valid, we are going to attempt to sign up, and check the response. If we get HTTP status code 201, it means the user was created and we can simply tell the user to log in with those credentials.

If we get HTTP status code 409, it means the username is already in use, and we can tell that to the user. If the response's status code is neither 409 nor 201, the request failed (probably because of a network error or an internal server error), we just tell the user an unknown error occurred:{% raw %}

onPressed: () async {
var username = _usernameController.text;
var password = _passwordController.text;

if(username.length < 4)
displayDialog(context, "Invalid Username", "The username should be at least 4 characters long");
else if(password.length < 4)
displayDialog(context, "Invalid Password", "The password should be at least 4 characters long");
else{
var res = await attemptSignUp(username, password);
if(res == 201)
displayDialog(context, "Success", "The user was created. Log in now.");
else if(res == 409)
displayDialog(context, "That username is already registered", "Please try to sign up using another username or log in if you already have an account.");

else {
displayDialog(context, "Error", "An unknown error occurred.");
}
}
},


The entire {% raw %}`LoginPage` definition looks like this in the end:

 
  


  
  
  Creating an Home Page


We already know what we need as constructors for the HomePage. Getting the payload from the base64 JWT string should be pretty self-explanatory if you understood the section at the start of this post about the structure of a JWT, and you only need to keep in mind that base64.decode needs a padded base64 string, and that can be obtained with base64.normalize():

class HomePage extends StatelessWidget {
HomePage(this.jwt, this.payload);

factory HomePage.fromBase64(String jwt) =>
HomePage(
jwt,
json.decode(
ascii.decode(
base64.decode(base64.normalize(jwt.split(".")[1]))
)
)
);

final String jwt;
final Map payload;
}


Instead of {% raw %}`ascii.decode`, use `utf8.decode` if you want to support non-ASCII characters. Thanks to @bisquits in the comments for noticing this, since it's really important!

### The HomePage's build() method

The `HomePage` widget itself is going to be made of a `FutureBuilder` that waits for the GET request to the server to get the data, and then either displays it or some text informing the user an error has occurred, if that is the case:

@override
Widget build(BuildContext context) =>
Scaffold(
appBar: AppBar(title: Text("Secret Data Screen")),
body: Center(
child: FutureBuilder(
future: http.read('$SERVER_IP/data', headers: {"Authorization": jwt}),
builder: (context, snapshot) =>
snapshot.hasData ?
Column(
children: [
Text("${payload['username']}, here's the data:"),
Text(snapshot.data, style: Theme.of(context).textTheme.display1)
],
)
:
snapshot.hasError ? Text("An error occurred") : CircularProgressIndicator()
),
),
);


The {% raw %}`HomePage` class definition is, therefore, the following:

 
  


  
  
  Creating the MyApp Class


The MyApp class is the class that gets run when the app starts. It needs to check whether it already has a JWT and, if it has one, it should check whether it is valid, whether it has expired and, based on that, decide whether to ask the user to log in or whether to show them the home page. We are going to need to create a method called jwtOrEmpty()

Future get jwtOrEmpty async {
var jwt = await storage.read(key: "jwt");
if(jwt == null) return "";
return jwt;
}


That's because the {% raw %}`FutureBuilder`'s `snapshot.hasData` parameter that gets passed to the `builder` function would return `false` if it were to receive a `null` value, which would be the case if the JWT were non-existent. This is unwanted because we would have no way of distinguishing the case in which we are still waiting for the `Future` to return and the case in which there is no JWT. Having this second case return an empty string instead of `null` fixes the issue.

All that's left to do is to create a `build()` method, which should return a `MaterialApp` (that's the whole point of the `MyApp` class) that, after getting the JWT and checking it, either shows the user the login page or the home page based on the criteria I described earlier.

All of that ends up in the following class definition:

 
  


  
  
  Implementing the Back-End with Node


You can find the code for this Node backend on GitHub by clicking here.

The Node back-end is where most of it happens: we need to create rules for login, logout and some sort of data to access. We are going to store users in an SQLite database to keep things simple for this example.

  
  
  Choosing How to Sign the Token


The token can be signed using either a method based on public key cryptography (for example using RSA or ECDSA) or by relying on hashing the concatenation of the secret key and the message (called a payload in JWT terms) with any hashing algorithm (usually sha256). The latter concept has been expanded into a full standard for generation of a digital signature (called HMAC) that is protected against collisions and length extension attacks, about which you can find more information on Wikipedia.

For this example, that’s what we will use: HMAC with SHA256. That’s because it’s easier for a quick example for a blog post because we have greater freedom with our choice of private key. When building a real app, you should obviously consider the advantages and disadvantages of this approach based on your needs and the requirements your apps needs to meet. For this post we’ll use a short and simple string as a key, that’s not how it’s supposed to be done: it should ideally be a generated pseudorandom (and particularly long) key, just like any RSA or ECDSA key generated with OpenSSL, otherwise you’re making it very easy for attackers to crack your private key and generate their own JWT tokens your back-end will think are genuine, allowing them to pretend they’re logged in as any user, completely breaking your website’s security.

  
  
  Safety First!


In other words, this is an example meant to be as easy to follow as possible and you must take the appropriate precautions when it comes to choosing or generating a private key. Since we’re talking about security precautions, you should obviously use TLS for communications between front-end and back-end in production. Also, salt the passwords before hashing them if you really want to play it safe.

  
  
  Building the Back-End


These are the libraries we are going to use:



Express, which is what we are going to use as a Web framework;

jsonwebtoken, which simplifies greatly the process of creating JSON Web Tokens;

the sqlite3 SQLite Node driver to create and access the SQLite database where we are going to store our users' data;
Node's built-in crypto library to hash the password to store in the SQLite database.


  
  
  Using the jsonwebtoken Library


The jsonwebtoken NPM package is very, very easy to use. It provides us with three functions, once imported with jwt = require("jsonwebtoken"):



jwt.sign(payload, key, options), which returns a JWT containing the payload and signed using the key, optionally you could also add a callback at the end of the argument list and it would be ran asynchronously, but we're not going to use that feature for our simple example, the default algorithm used for generating the signature is RS256 (RSA signature with SHA256);

jwt.verify(token, key), which returns the decoded payload if the JWT is valid, and throws an error if it isn't, it also optionally takes some options and a callback just like jwt.sign(), but we're going to provide neither of them;

jwt.decode(token), which decodes the payload without verifying the validity, we're not going to use this one at all.


For example, if your payload is {username: "myusername"} and the private key is stored in the variable privKey and you want to create a JWT using the provided RSA private key that is valid for two hours, you can run

let jwt = jwt.sign({username: "myusername"}, privKey, {expiresIn: "2h"} );


and then, if {% raw %}`pubKey` is the corresponding RSA public key, you can run

let jwt = jwt.verify({username: "myusername"}, pubKey);


In our example we are going to use just one secret key (stored in a variable called {% raw %}`KEY`), so we are going to generate the JWT as an HMAC with SHA256 (*HS256*) and have it expire after 15 days, which means we are going to generate the JWT with:

let jwt = jwt.sign({username: "myusername"}, KEY, {expiresIn: "15d", algorithm: "HS256"});


I recommend you look at the documentation for the package on the NPM page for a more complete list of options. I'm not writing an API reference here, I'm trying to make you understand how to implement this.

### A Quick Introduction to the sqlite3 Node SQLite Driver

The sqlite3 Node SQLite Driver doesn't come with too many bells and whistles. There are other packages that provide different interfaces, this is the most basic one and it's perfect for a very basic and simple example that really shouldn't require a huge {% raw %}`node_modules` directory or particularly complicated.

After importing the library with `sqlite = require("sqlite3")`, you can initialize a connection to a database stored in a file called *filename.db* with:

let db = new sqlite.Database("filename.db");


The functions we are going to use are:

* {% raw %}`db.get(query, function(err, row) {})`, which runs the `query` and passes to the provided callback the first row returned as the `row` argument and any errors as the `err` argument;
* `db.run(query)`, which runs the given query, without returning any results, this is used for commands such as `CREATE` and `INSERT` and you can pass a callback to be called in case of errors.

Two other functions exist called `db.all()` and `db.each()` which respectively pass all of the rows as an array to the callback and call the callback for each row returned, only passing one at a time. We would need to use such functions if we wanted, for example, to check whether a log-in attempt failed because the password was wrong, even though the given username exists in the database.

#### Query Parameters

The queries can contain parameters, which can optionally be passed as an array, so they can replace `?` characters found in the query string. This will sanitize the strings before substituting them, not making you vulnerable to SQL injection. For example, the following two calls to `db.each` are equivalent:

db.each("SELECT * FROM Users WHERE username='carmine'", function(err, row) {
console.log(row);
});
~~~

db.each("SELECT * FROM Users WHERE username=?", ['carmine'], function(err, row) {
  console.log(row);
});
~~~

### Installing Dependencies

As always, create a Node project with

$ npm init


and install the packages I listed above with{% raw %}

$ npm install --save express jsonwebtoken sqlite3


### Initial Config

We are going to import all of the libraries into our code and set the secret key (a very unsafe one, but this is just an example) and initialize the database connection:

 {% gist https://gist.github.com/carzacc/ab1f598a313806a02dc401d52a10df6b file=initialConfig.js %}

### Initializing the Database

You can do this either directly using the SQLite or any other tool of your choice or by creating this Node.js file and running it:

 {% gist https://gist.github.com/carzacc/13453b285f265bfa3606f271d2601eb4 %}

### Implementing Sign-Up

Signing users up is simple and has nothing to do with how we manage authorization: we're not logging them in, which means we just need to check whether they have already signed up. If they haven't, we sign them up by adding them to our database. We are going to use the Express built-in urlencoded middleware to parse the body of the request and we're going to log everything to the server console:

 {% gist https://gist.github.com/carzacc/ab1f598a313806a02dc401d52a10df6b file=signup.js %}

Logging in is all about looking in the database for the user who is trying to log in, generating a JWT and returning it if we find it, and returning an error if we don't:

 {% gist https://gist.github.com/carzacc/ab1f598a313806a02dc401d52a10df6b file=login.js %}

Verifying the token is very easy with the Node library we are using, meaning the {% raw %}`/data` route is written very quickly and painlessly, remembering that a failure in verifying the JWT will result in an error being thrown:

 
  


As usual, we take the port to run the server on from the environment variable PORT and, if that fails, we set it to 3000 and run the server:

Uploading a File to a Server from Flutter Using a Multi-Part (form-data) POST Request

Carmine Zaccagnino — Sun, 02 Feb 2020 20:56:04 +0000

My Flutter book is pretty light on advanced HTTP networking topics, focusing instead on giving a more well-rounded approach that, when it comes to networking, explains how to use the http networking package for basic requests, shows an example of an app that makes GET requests, and then goes a bit more specific with Firebase.

My blog is here for those who need more than that, and the first topic I'm going to cover is how to upload a file using a multi-part/form-data POST request.

You can find all of the code contained in this example in this GitHub repository.

What is a Multi-Part POST Request

Usually, the body of a POST request is made of textual key-value pairs. With a multipart POST request, you can also include files with binary content (images, various documents, etc.), in addition to the regular text values.

Making Multi-Part POST Requests with Flutter's HTTP Library

This little section is going to focus on one thing: creating a function that, given a file path and an URL, is able to send that file to that URL with that multipart POST request.

The next section is going to focus on how to build an app that lets the user insert the URL to which to send the request, pick an image and send it to the server, getting back the status of the request.

This means we're not going to worry about dependencies in this section. All you need to know for this section is that we've got this at the top of our main.dart:

import 'package:http/http.dart' as http;
~~~

This allows us to *create* (not send) a multipart POST request using

var req = http.MultipartRequest('POST', Uri.parse(url));


This {% raw %}`req` object has a member `Map` called `fields` for textual values and a `List` called `files` to which you can add `MultipartFiles`.

### The MultipartFile

The most important element of this whole thing is the `MultipartFile`. It can be constructed in a few ways:

* the default `MultipartFile(key, stream, length)` constructor, which you can use if you need to create the file from a `Stream` of bytes of which we know the length;
* the `MultipartFile.fromBytes(key, bytes)` factory method, which attaches a file obtained from a `List` of bytes;
* the `MultipartFile.fromString(key, string)` factory method, which attaches a text file containing the string passed to it;
* the `MultipartFile.fromPath(key, path)` factory method, which attaches the file found at the given path.

In case you’re wondering, *bytes* simply means *integers*. That’s all a byte is. An 8-bit integer value. A list of integers, coupled with an encoding (that can usually be inferred with the help of the extension that’s part of the file name) is all you need to get images, documents, videos, music or text.

If you're using one of the first two constructors for the `MultipartFile`, remember to set a filename using the specific named `filename` argument, as not doing that will cause issues with our back-end.

Here are a few examples: if you have a file and a path to it, here’s how you create a multipart POST request and attach that file to the request:

* Using the default constructor you could write a function like the following:


  

 


UsingMultipartFile.fromBytes() you could write a function like the following:



  

 


UsingMultipartFile.fromPath() you could write a function like the following:



  

 

  
  
  Adding Regular Text Fields


You could add regular text fields to a Multipart POST requests simply by adding, after settomg initialized the MultipartRequest object, an item in the fields member Map:

var request = http.MultipartRequest('POST', Uri.parse(url));
request.fields['key'] = 'value';


## Building an App Around That

Now, to see it in action, let's write an app that allows the user to insert an URL, pick an image, and then upload the image to the server at that URL. We'll write the very simple back-end code required to accept files this way in Node after we're done with the app. Feel free to skip ahead if you're more interested in that.

Let's start, as we must, with an evaluation of the dependencies and the {% raw %}`pubspec.yaml` file. We'll use two packages from Dart Pub: the `image_picker` Flutter package that will handle the image selection dialog for us, about which [I wrote a tutorial on Medium a year ago (not part of the metered paywall in case you're wondering)](https://medium.com/@carminezaccagnino/taking-and-or-using-pictures-in-flutter-apps-using-the-image-picker-package-b8e366654a0) and the [Dart `http` package](https://pub.dev/packages/http) that provides the networking features we need.

Add both the dependencies in `pubspec.yaml` (check the GitHub repo I linked at the start of the post if you don't know how to do that) and import them both into the `lib/main.dart` file along with the usual Flutter Material Design API:

import 'package:flutter/material.dart';
import 'package:http/http.dart' as http;
import 'package:image_picker/image_picker.dart';


### The Start Page

Now let's think about the actions the user needs to take in our app: in order to upload images, we first need an URL, so let's show a screen that allows the user to set the URL first, and then we allow them to upload images. We'll call this first screen {% raw %}`StartPage`. This is the usual Flutter code used to initialize an app, this tutorial really is meant for those who don't need much explanation as to what it does and why (that's more the realm of introductory tutorials and books like the one I've written):


  

 

We use a TextEditingController to let the user both submit the value from the Android keyboard or press our cusdtom FlatButton below the TextField.

  
  
  The Upload Page


Here's the code for the upload page, I'll explain it down below after the code:


  

 

uploadImage() is the simplest of the functions we saw earlier to upload images: we use MultipartFile.fromPath() directly and return the status string of the request. That's going to be the state variable, which is what is shown in the middle of the screen to the user. The URL is the one we get from the StartPage.

The FloatingActionButton is fairly simple: ImagePicker.pickImage() shows the familiar image picking screen to the user returns (through a Future) the path to the file the user picks.

We use that (as part of the floating action button's  onPressed callback) together with the URL passed by the StartPage to call the uploadImage function and re-render the view using setState to show the state of the request to the user.

  
  
  Writing a Simple Back-End in Node to Handle Multi-Part POST Requests


For this section, the tools we're going to use are Node, Express and Multer. There's not going to be much code involved, this is a fairly simple affair.

First of all, install Node and NPM according to the instructions for your operating system on Node’s official website.

After that, create a directory, run the command

$ npm init


and fill out to your preference the choices given to you (the default values are fine in case of doubt)

and then{% raw %}

$ npm --save install express multer


Create a file called {% raw %}`index.js` with the following content:


  

 

As you can see it's not much code, but I'm going to explain it nonetheless.

The first 4 lines are simply dealing with dependencies: the first three are straight-up imports of dependencies, whereas line 4 sets up the Multer middleware (the one that handles file uploads) to save uploaded files to the uploads directory.

Line 6 instantiates an Express server object, as the Express API documentation requires.

  
  
  Creating an Express Rule for Handling Multipart POST requests


After that, on lines 8 to 19, we define a rule for incoming POST requests to the /upload path (in other words, it responds to POST requests sent to &lt;server IP&gt;:&lt;port&gt;/upload), it takes one file on the picture key, and it fires the callback function we defined as (req, res) {...} in the lines 8 to 19.

The callback prints to the console the name of the file that was received (on line 9), it then renames the file to the original file name.

It does that on lines 10 to 16 by creating, as is done using Node's fs interface, streams (much like FILE* variables in C) that allow our script to read from an input file (req.file.path is the path Multer saved the received file to) and write to an output file (using the passed req.file.originalname, which is the filename specified in the POST request by the sender, which is our Flutter app). When this is finished (lines 13 to 16) we delete (unlinkSync) the temporary file created by Multer (which has a name that ensures there aren't two files with the same name but doesn't even keep the same extension as the original file) and send back a response saying everything was OK.

If an error happens (often because no file name was specified, on line 17) we will inform the sender of that.

On lines 22 and 23 we start the server on the port specified by the PORT environment variable or on port 3000 if no port was specified using environment variables.

That's it.

  
  
  Making Our Example Work


To use the example code, start the server by running node index.js. Then, fire up the Flutter app on a phone/emulator, get your PC's local IP (if the phone is connected to the same local network or it's running on an emulator) to substitute to &lt;server_ip&gt; in http://&lt;server_ip&gt;:3000/upload, which is what you need to type into the TextField in the app. For example, if your PC's IP is 192.168.1.2, you'd type in http://192.168.1.2:3000/upload. After that, press the + icon, pick an image, and you'll see the Node script will print out a message like Received image_picker&lt;gibberish&gt;.jpg. By opening the uploads subdirectory in the directory where you have the back-end Node script, you'll find a file called image_picker&lt;gibberish&gt;.jpg.

I hope you found this tutorial useful and I invite you to tell me what topic I should cover next.

The Early Adopter Conundrum and Reacting to Comments

Carmine Zaccagnino — Wed, 25 Dec 2019 00:25:44 +0000

When you love new stuff but don't really
want to lose old stuff you write this kind of stuff. It's about tech stuff that's old and tech stuff that's new.

If you asked me a month ago, the term early adopter would have been a term I could identify myself with, especially when it comes to technology and computing.

For example, as is evident if you read any amount of the stuff I write, I'm a big proponent of Flutter as an app development framework and have been for quite some time.

That's all well and good but, especially when it comes to Linux, I sometimes really like holding onto old and proven stuff. Not really on the desktop, I jumped on the Wayland bandwagon early enough and it has only caused me very minor issues in the early days and now I only go back to X.org the few (not always so few actually) times I'm lazy enough to build some GUI software I need to run as admin for it to work (I know about PolicyKit/polkit, but it's just easier to not bother with it at all when I don't have to).

The fact that sometimes that can interfere with being a credible early adopter came to light when I wrote an article for the Fedora Magazine about the screen command line utility.

It was on a topic among the ones they were looking for someone to write and, since I always use screen, I thought many other people may find it useful to have an article explain the most important features screen offers and how to use them.

A few minutes after it was online, it started getting comments on how screen was outdated and tmux was much better, suggesting people to forget about screen completely.

tmux is newer and it's more likely to be updated in the future and it's seeing more active development, but screen is still a solid option and it offers a lot of features.

As one of the commenters pointed out, tmux lacks (and may never have), among other things, support for terminals over serial connections, so if your backup in case you can't connect to a machine in any other way is serial knowing screen may be more useful to you than learning tmux.

But that's not even my point. Why should I have to forget screen in order to learn tmux? And by that I don't just mean that I can use both as the difference in feature sets makes one easier to use or better than the other depending on the circumstance. I could argue that most of the people who use screen don't even have to learn tmux: except for the comment section on that post, I've never heard people calling screen unstable and tmux is not much easier to use than it for most of what sysadmins do with screen. It's always worked and it might keep working indefinitely.

This begs a question though, bringing us back to the start of this post. What about the early adopter thing? Why am I bothered by people commenting on my Flutter posts on dev.to telling people they're fine using React Native?

It's because they're telling people who want to learn Flutter not to do it because they are too lazy to even learn the basics of Flutter themselves. They're saying Flutter is going to fail. I'm not saying any of that about tmux. I'm not doing any of that. Before this post, I haven't even written about tmux anywhere: I actually use it. Not as much as screen, though.

I'm not hating on any technology (publicly, at least, I privately express stronger opinions on some software development frameworks/tools) because I don't believe it's of any benefit to society for me to tell you to ignore X and Y: I want to tell you all how amazing Flutter is and that's all.

I've got to be clear on this, though: with this post I don't actually mean to say those comments on my posts telling me how much of a fool I am for being a fan of some old or new technology shouldn't exist. I love answering them and would much prefer a civil back-and-forth to a single inflammatory comment with no follow-up.

That said, if anyone's reading around the time I'm writing this, I wish all of you will be able to work with whatever technology you prefer, perhaps learn something new and exciting, and reach your goals in the coming year 2020.

Google's Flutter Framework Could Change Software Forever by Bridging Mobile, Desktop, Web and Embedded

Carmine Zaccagnino — Mon, 18 Nov 2019 17:45:03 +0000

Google is known for moonshot projects. Often they're just that, without much hope of being brought to fruition in the near future. But Flutter is not one of those: it's here now and it works, wonderfully.

How Flutter Was Born: Bridging Mobile Platforms

Flutter was released back in 2017 as a mobile development framework aiming to seamlessly bridge Android and iOS development without taking away any control over the hardware and low-level operating system features from the hands of the software developer, like many other frameworks do. It got lots of attention because Google showed impressive performance results, which are achieved thanks to the use of a low-level rendering engine that doesn't rely on the operating system's native interface elements like similar technologies such as Facebook's React Native do.

It also got so much attention because it is being pointed to as the primary way of developing apps for Google's upcoming Fuchsia OS, which is set to replace Google's current operating systems. Developers also loved the top-notch developer tools allowing, among other things, to instantly preview the result of changes to the code without having to compile the app.

In addition to being one of the main topics of many conferences dedicated to Dart, the Google-developed programming language used to develop Flutter apps, Flutter has been discussed, presented and advertised for a significant amount of time at Google I/O ever since Flutter's initial release in 2017, and we saw that especially in 2018, when Flutter was really being pushed by Google in anticipation of its 1.0 release in late 2018.

Leaping into the Future: Bridging Desktop, Mobile, Web and Embedded

Google I/O 2019 went one step further: experimental support for desktop and web platforms was released, setting forward a vision for a world in which a piece of software doesn't have to be exclusive to one platform: it doesn't matter what platform you need to support if Flutter is powering your app: it doesn’t matter whether they’re phones, tablets, computers, TVs or embedded devices.

Notable Examples of Flutter Use

Flutter is not just a big tech preview: it is being used in production today by big companies. Google themselves recently released the official app for Google Stadia, their well-known upcoming game streaming platform. Google also lists companies such as eBay, BMW, AliBaba, Tencent and other companies worth several billion dollars as Flutter users and one of the early adopters of Flutter in early 2018 was the Hamilton musical's app.

Away from mobile platforms, "The New York Times" has built some of its web-based digital puzzles in Flutter, that you can see at this link.

Why Flutter Is So Important

Flutter is reality and it ought to be exciting for everyone: it could be about to bring down the last of the barriers stopping us from forgetting about the underlying interface entirely and think of applications in a way that is only dependent on the choices of the programmer and the requests of the users.

What You Can Do With It

You might be wondering what exactly you can expect to be built with it. The answer can be found in more than one way: the first is by taking an inductive approach, looking at what has been built with Flutter.

The most obvious example is something like the Hamilton app I mentioned above as the first major app using Flutter because it’s what most people think of when talking about a typical Flutter app. It’s an app that takes up-to-date information from the Internet and shows the information to the user with an unique aesthetic style in multiple layers, mixing everything from news-like sections to trivia quizzes.

This is a mix of some of the most common features in mobile apps, but we can highlight Flutter’s flexibility further: it has control over the screen, so games with custom graphics and animations (like the New York Times puzzle linked above) can be built with it, with the same framework that implements easy-to-use classes for all of the components of Material Design and the iOS design language.

The Low-Level Interfaces: C++, Swift/Objective-C and Java/Kotlin

So Flutter can do anything visually. But we haven't talked about what it can do with the hardware and low-level OS interfaces. To find that out, we are going to take the deductive approach.

The short answer is: anything a native app can do, and the reason for that is that Android Flutter apps can run Java/Kotlin or native C++ code just like regular Android SDK apps, Flutter iOS or macOS apps can run native Swift or Objective-C code and Linux apps can run native C++.

To any programmer, this simply means that the app has full access to the device's capabilities. An example of that is a project of mine that aims to build a Flutter app that can manage filesystems on Linux by interfacing with Stratis, a Red Hat-developed storage management utility.

Flutter is even starting to be considered by Linux GUI developers as a potential solution to the inconsistency among different desktop environments, and the people in charge of putting together Linux distributions are taking note and starting to consider putting some effort into making Flutter desktop support even better.

Looking Onward

Flutter's unparalleled flexibility means there will be no duplication of effort in software development teams, increasing their productivity and eliminating any feature gap between versions of the same app developed for different platforms.

This is revolutionary and is already taking over market share in the mobile world, all that’s left to see is whether it can adapt and succeed on the other platforms, but with Google behind it and after seeing how many companies are investing heavily into it, it looks like it will change the way software is developed, making it easier for everyone to find high-quality software for any platform, be it a phone, a tablet, a computer or even a completely different kind of device, such as a car’s infotainment system, a smart home device or a smart TV.

        <img src="https://imagery.pragprog.com/products/578/czflutr_xlargebeta.jpg?1560360708" alt="...">

      <div class="col-md-8 text-center text-md-left">
        <h3 class="mt-0">Get a Complete 300-page Introduction to Flutter!</h3>
        <p>I’m so excited about Flutter I wrote a book about it called Programming Flutter with the Pragmatic Bookshelf.</p>

      <a href="https://pragprog.com/book/czflutr/programming-flutter">Check it Out Here</a>

      </div>
    </div>