You know those moments when you're building something and questioning the approach? Those moments when something should be easy but it's not?

Restricting downloads to only users who are authenticated should be EASY from the client side ... right?

Having authentication between the client and api is stupidly common. Your client sends all its requests up with a `jwt`, the server validates the `jwt` through middleware and you have an authenticated api.

So what happens when we can't add our token to a request header. A Download Link for example. We need a way to request and download a resource, and make it go through the same authentication pipeline as our app that is as seamless as ... clicking a link.

Probably the right way

If we had all the resources in the world, we could use someones credit card, setup an account on AWS, setup profiles and policies and infrastructure to allow our server to generate signed urls that expire after a couple of minutes.

Well in the world of agile, priority arrangements and short sprints, sometimes you need to take an approach with far less overhead.

Using HTML5, Blobs and Javascript in React

Authenticated File Downloads in React

We can use this technique with our existing authenticated api and build a component wrapper to handle the action lifecycle. An overview of this technique looks like this:

1. Have an authenticated server that can serve a file like res.sendFile(filePath) which is protected and requires a valid authenticated session
2. Make a request const result = await fetch(...) from the client to the server with your auth headers to an endpoint that can serve your file as the response.
3. When the client receives the response you convert the data to a blob using const blob = await result.blob().
4. Create an object URL out of the blob by using const objectURL = window.URL.createObjectURL(blob)
5. Assign that object url to the ancher tag <a href={objectURL}>download</a>
6. Programatically click the ancher tag to initiate the download so the user does not have to click a second time.

Let see what a reusable component would look like in React.

import { createRef } from 'react'

export function AuthenticatedLink ({ url, filename, children }) {
  const link = createRef()
  
  const handleAction = async () => {
    if (link.current.href) { return }
  
    const result = await fetch(url, {	
      headers: {...authHeaders}
    })
    
    const blob = await result.blob()
    const href = window.URL.createObjectURL(blob)
    
    link.current.download = filename
    link.current.href = href
      
    link.current.click()
  }

  return (
    <>
      <a role='button' ref={link} onClick={handleAction}>{children}</a>
    </>
  )
}

we then call the component in its parent like

<AuthenticatedLink url='/protected/api/documents/filename.png' filename='filename.pdf' >
  Download file now
</AuthenticatedLink>

1. We check that the a element does not have a href attribute assigned to stop the recursive pattern that could happen when simulating a click and calling the click handler again.
2. Using Reacts.createRef allows us to manage the element with ease.
3. This pattern does not change how a link is clicked in a web application. It works like a normal link

So there we have it, a pretty well supported way of protecting files from a server that requires  authenticated users to make requests.

Peace,

EDIT 1

It is quite common with axios to do something like `const { data } = await axios.get('...')` and return data. It can also be quite common to chain a set of asynchronous calls to get what you need. Below will not work because `data` is defined on the first line.

const { data } = await axios.get('.../resource1')
const { data } = await axios.get('.../resource2')
const { data } = await axios.get('.../resource2')

We can name deconstructed variables with the spread operator. The above can be rewritten like below which gives us access to the newly named resource constants.

const { data: resource1Result } = await axios.get('.../resource1')
const { data: resource2Result } = await axios.get('.../resource2')
const { data: resource3Result } = await axios.get('.../resource3')

If you know the object in advance you can also deconstruct child properties as well.

const { data: child1: child2: { status: child2Status } } = { data: { child1: { child2: { status: 'child2 status' } } } }

console.log(child2status) // child2 status

:cool:

END EDIT 1

The spread operator is amazing. It is probably single handedly one of the best bits of javascript functionality to be bestowed upon us.

It allows us to manage immutability,  deconstruct and assign variables in a single line, merge multiple arrays into a single collection.  But wait, that is NOT why I am here today. The reason I stand before you right now is ..., I learnt something else this magnificent operator can do. Take this snippet below;

const post = { title: 'Javascript', sub: 'is great', emotive: 'and I love it!' }

const { title, ...rest } = post

Using the spread operator, I can pick  title out of the post object and assign the rest of the properties to a variable called rest.

rest is now an object that does not contain title.

I know, it's a short post, but it was enough to make me smile!

Happy Developing!

I should preface that I love Vue! I have said that far too often to colleagues with looks of, "huh?" and "what did you say?".

I started using Vue using the amazing Vue CLI Tool that is provided. Much like create-react-app , Vue has a really powerful, behind the scenes, (include all the things) CLI that gets you up and running in minutes instead of days.

Webpack is behind a lot of the magic that the Vue CLI client provides and one of complexities of Webpack is how it manages assets. Webpack must manage assets from two perspectives. One is on your local development machine, and the other is your built out production ready version.

What happens behind the scenes?

This is what it looks like to bring an image into a *.vue template

<template>
  <img src="@/assets/logo.jpg" />
</template>

The default webpack config will automatically transform img elements and convert the url to a production ready url. When your project is built out, you should find your assets renamed to something like below.

<img src="/img/logo.f556f5d.png" />

This happens automagically with img elements. but most of the time we are using components from other frameworks and we need to be able to resolve asset paths on the fly.

What about a dynamic static path?

A team page would be dynamic to some extent. We would have team members, profile pictures that probably don't change too often associated with the team members id.

Resolved Assets

We can use `require` in our source url of our customer component to tell webpack about the asset being used. When the file loader runs into a situation where we have partially defined the asset path, it will copy everything relative to the dynamic part of the path to the static assets directory. For example, everything in the teams directory will be copied across.

<my-image-component :image="require(`@assets/teams/${teamId}.png`)" />

Another way we can use local assets is explicitly defining them as static assets. It could be icons, team pictures, or marketing collateral.

Using the Vue project config we can setup a static assets directory.

Static Assets

Add `vue.config.js` inside the root of your project directory and add the following config to it.

// Config file is automatically picked up by Vue CLI services.

module.exports = {
  build: {
    assetsPublicPath: '/',
    assetsSubDirectory: 'static'
  }
}

This will copy all the assets inside this directory to the build directory. You can reference any of these urls inside your project by using relative paths like `/static/my-filename.png`

Remember that when you use static paths, any change to the assets name or sub directory requires all the paths in your project to be updated.

I hope this post provides a little more insight into how Vue CLI and webpack handle dynamically generated static urls.

👍

A typical developer has multiple account environments for testing and production. We currently have dev, test, and prod environments where I work. Every single 3rd party platform we use, has the same environments setup as well.

Most developers using AWS services would understand the pain of switching between different account. For me, it involved opening an incognito window, pasting in the environments login url, entering my passwords into the password field, and entering my 2FA key.

There has to be an easier way ...

Chrome allows you to create Localised Users Profiles each with there own session data. This allows us to have a browser window instance per user with unique session data.

1. Click on the user icon in the top right hand corner of your chrome window, and click on the Manage People button.

2. Add a New Person for each environment you use.

3. Now you can click on your created people and open up a new chrome window which is unique to each profile.

This was a huge productivity improvement when switching between accounts on a daily basis and has saved a chunk of time signing out, clearing cache and using incognito.

Creativity in coding plays a really important part to what I love doing every single day. I get an hour on the tram every morning to sit down and work on my own personal projects. This was one of the outcomes.

Oh shit, how exciting is this! I love all facets of JavaScript, Design and Principles. JavaScript is probably the most accessible language in the world and I can't wait to dive deep into my learnings and just develop fun and amazing things with it.

Looking forward to you all following along and learning something on the way!

See you Math.round(0.8).