DEV Community: Reece M

Correctly prerender SvelteKit dynamic pages with Prismic as the CMS

Reece M — Wed, 07 Apr 2021 17:16:18 +0000

Originally trying SvelteJS Sapper to build a site with Prismic was a bit tricky, mainly trying to get the systems to work together and also finding out that the hot module reloading was bust...

When testing SvelteKit out (I had read about it on Sapper docs somewhere 🤷‍♂️) but then there was the beta release so I tried it out and also read the Prismic blog post on setting it up and it worked a lot better, the experience was similar to Next and the result was a really really fast build. (Like stupid quick compared to other things)

Yet there was a problem, dynamic static routes weren't built without the svelte:prefetch...

Building a route list before pre-rendering.

I tested different ways to get the site to fetch data and basically 'hydrate' stuff at build time. Because interestingly even with the static-adapter it didn't render pages that were dynamic [uid].svelte. P.S. use npm i -D @sveltejs/adapter-static@next is the working one.

So you can imagine the confusion when Netlify a) doesn't build the site properly and b) the static site has 404 pages where there should be pages.

The solution I decided to use, as it has the best support at present is to use a Node script to fetch the list of pages that you want, map them through a linkResolver function to build the appropriate routes for Svelte to render and make it available before Svelte builds.

Building the dynamic routes 🗺

The first file is called utils/routelist.js, this is called before running Svelte's build process and generates your routes. It is only needed at build time. So when you put it on the server for production.

import Prismic from '@prismicio/client';
import path from 'path';
import fs from 'fs';
import { cwd } from 'process';

const repository = process.env.PRISMIC_REPOSITORY 
    ? process.env.PRISMIC_REPOSITORY 
    : 'CHANGE_THIS_PLEASE';

const apiEndpoint = `https://${repository}.cdn.prismic.io/api/v2`;
const Client = Prismic.client(apiEndpoint);

// Our link resolver that will be used to map the routes 🗺
const linkResolver = (doc) => {
    if (doc.type === 'blog') {
        return `/blog/${doc.uid}`
    }

    if (doc.type === 'categories') {
        return `/category/${doc.uid}`
    }

    return `/${uid}`;
}

/**
 * This is our build function. It contains the query.
 * It uses the link resolver to build the routes.
 * It then writes it to disk in the same dir.
 */
const build = async () => {
    let query = await Client.query([
        Prismic.Predicates.at('document.type', 'blog'),
        Prismic.Predicates.at('document.type', 'categories'),
        Prismic.Predicates.at('document.type', 'homepage'),
    ]);

    /**
     * Svelte uses the `*` to render the other pages that aren't dynamic
     */
    let pages = ['*']

    /**
     * Convert the docs into the related link for Svelte to render.
     */
    let result = query.results.map(linkResolver);

    pages.push(...result)

    /**
     * We create a JSON file that is used to build the site.
     */
    fs.writeFileSync(
        path.join(cwd(), './utils/routelist.json'),
        JSON.stringify(pages)
    )

    console.log('written: ', pages);
}

build();

A quick summary of what that all does is basically uses the API to get the docs we want and their UID, map them, then write them to disk as an array in a JSON file.

This has two benefits, we don't have to commit the JSON to git and we don't have to parse the JSON file when importing it.

Updating the Svelte config file

To make use of the built pages, you can edit your svelte.config.js file like so:

+ const static = require('@sveltejs/adapter-static');
- const prismic = require('./adapter-prismic');
const pkg = require('./package.json');
+ const pages = require('./utils/routelist.json');

/** @type {import('@sveltejs/kit').Config} */
module.exports = {
    kit: {
        // By default, `npm run build` will create a standard Node app.
        // You can create optimized builds for different platforms by
        // specifying a different adapter
+       adapter: static(),

        // hydrate the <div id="svelte"> element in src/app.html
        target: '#svelte',

        prerender: {
+           crawl: true,
+           enabled: true,
+           force: true,
+           pages: [...pages],
        },

        vite: {
            ssr: {
                noExternal: Object.keys(pkg.dependencies || {})
            }
        }
    }
};

This will import the json file that is basically an array of strings, this is then destructured into the pages key for the prerender.

Updating package.json

To make sure the files are triggered correctly, you can add the following to the package.json scripts key:

    "scripts": {
        "dev": "svelte-kit dev",
        "build": "npm run routes && svelte-kit build", /* Updated */
        "routes": "node ./utils/routelist", /* NEW */
        "start": "svelte-kit start"
    },

This will make it possible that now your dynamic pages in Svelte are prerendered when exporting to a static version using Prismic or another headless CMS I guess.

Cleaning it up

I added the exported file to my gitignore, as it really isn't needed as it is once off during the build process. So for this specific example add the following to the root .gitignore for your project: /utils/routelist.json

That should be about all to make a clean, fast, and non-404 static site with SvelteKit

0_o

Original from my site

How to get Paddle PayLinks from a backend API Controller in Laravel

Reece M — Sun, 29 Nov 2020 17:45:40 +0000

This is the follow up post to using a renderless component for Paddle paylinks.

Sometimes you may have na application that has a few subscription options, sometimes not.

If you have a few subscription options available and you are displaying them for the user to pick one, there is a request each time to the Paddle API endpoint to generate a payment link, this in turn will reduce the response time for the subscriptions settings page, this sucks.

We will solve this delay by continuing this split of loading the payment links after the initial response.

Creating a Controller to handle the links

So to begin, you need a controller to handle the generation of the links, because this is an API controller basically, you won't need the extra methods of a normal CRUD controller, so we can go with an invokable one.

php artisan make:controller Api\\SubscriptionLinksListController --invokable

You should have a new controller under App\Http\Controllers\Api. (Please don't feel forced to use the name I have put here, you can use whatever you feel is better.)

Getting the Paddle paylinks from Cashier

Inside our __invoke we are going to place our main logic to check for the user and then create paddle links.

Things we want from this controller are the following:

We need a link for each subscription type we offering to the user
Which one the user is currently on
The 'pretty' name that a user understands
Possibly some features or highlights for the front-end

So with that in mind, lets get the links sorted first off, below is our skeleton of code that we will need:

use Illuminate\Http\Response;
use Illuminate\Http\JsonResponse;
use App\Models\Plan;

...

    public function __invoke(Request $request)
    {
        /** 
         * This part assumes that the current billable instance is the authorised user.
         */
        $billable = $request->user();

        // Our list of available plans, note the name could be anything here for the plan model.
        $plans = Plan::whereIsAvailable(true)
            ->get(['id', 'paddle_id', 'title', 'name', 'is_available']);

        $subscriptions = $plans->map(function($plan) use($billable){

            if ($currentSubscription = $billable->subscribedToPlan($plan->name)) {
                /** For this example you can just giving them the option to cancel the plan*/
                $payLink = $billable->subscription($plan->name)->cancelUrl();
            } else {
                $payLink = $billable->newSubscription($plan->name, $plan->paddle_id)
                        ->returnTo(route('billing'))
                        ->create();
            }

            return [
                'title' => $plan->title,
                'name' => $plan->name,
                'paylink' => $paylink,
                'current' => $currentSubscription,
            ];
        });

        return new JsonResponse([
            "data" => $subscriptions,
        ]);
    }

Lets break down the current parts of this code.

Getting the current `billable` model

The line of code that reads $billable = $request->user(); is where we get the billable model from cashier, this is the model we will use to compare if they have any active plans currently.

A point to note about this is that the Billable model could be anything, if you get that from a different source, then change that line.

For example

    // if you have an Account model that is billable, then it could look like this.
    $billable = Account::where('user_id', $request->user()->account_id)->firstOrFail();

Fetching the plan names for the Paddle subscriptions

You could manually hard-code the plans into place via config files, this would give you the same option of fetching them with the config file.

This would let you keep the changes in version control, but if you need to change a plan and make a custom one for a customer, you would have to go through a deploy cycle to get it to them.

In this instance, the plan details are fetched from a database table, this gives us the option to even scope the plans to certain people.

The important information to store in the plan table is the following:

Paddle Product/Subscription ID
The name cashier will search with
A name to show the user in normal naming convention, not 'pro-plan-version-1-iteration-4' :)

Creating the return data from our API

The data that is returned to the frontend code contains only the information that matters for the UI to be rendered, the Paddle Paylink, the name and if it's currently subscribed to.

This makes the data returned light so if they have network issues it isn't a large payload. Making it quicker basically.

The data is returned in the form of a JsonResponse, this wraps the data in the appropriate headers and HTTP response codes.

You could always create a Json Resource class that has the same structure for any subscription data returned from your app, this would allow you to have a consistent pattern of data across your entire app if you are working on a large team. All each person has to do is call new SubscriptionLinkResource($data)

Getting the links from the frontend

To get the data from the front end you can use the component outlined in this post: Using a renderless component for Paddle paylinks.

Or you could create your own version of that.

Either way, you need to make sure to have an entry in your routes file.

Something like Route::get('/billing/subscriptions', SubscriptionLinksListController::class)->middleware('auth:api'); would be enough.

Alternatives

You could use a Resource class in Laravel to contain the structure for each link, then bundle it as a collection handling the fetching of each Paddle link inside the resource class, this would make for a very skinny controller, basically just a fetch of the plans from the DB or from the configuration files, then you can have something like return SubscriptionLinksCollection($data)

I will maybe make an additional version of that later on an link it here.

I hope you enjoyed this, please reach out with feedback or suggestions for improvements. You can find me on twitter @iexistin3d.

Have a great time and keep safe 🙃

What times are reasonable to post a technical blog post/ tutorial ?

Reece M — Fri, 27 Nov 2020 09:44:51 +0000

I have been wondering for a while now what the most reasonable time is to post either on dev.to or other channels.

Just been wondering this as most people are busy with stuff, so either they could just be browsing and not reading. So just wondering what sort of timeframe people are sitting down to look for something to read.

Or maybe it is an engagement issue from my end 🤷‍♂️ 😅 as it would be great to post at a time, or improve the posts that would encourage feedback on things that can be improved or even are decent points.

Please share your thoughts or experiences on this if you have had the same thing :)

Have a good day too

Dynamically load Cashier Paddle buttons with a renderless component

Reece M — Fri, 13 Nov 2020 21:06:56 +0000

A project I have been working on has been in need of an improved billing system, with the release of the cashier-paddle package I was able to add some subscriptions to the app.

Working with the package, one can see that it's relatively easy and fluent to get paddle / cashier working in your Laravel app. And this is great!

Noticing the load times on generating links

I noticed after a while that sometimes the loading of the payment links took a while. Taking into account the API is requested for each link. Making in turn the response from the server slow, ... ... ... waiting for each link to be generated.

Obviously, the immediate thing here is that if this isn't an SPA that doesn't have to get new pages, you will notice. And you would notice on an SPA 🤷‍♂️

Now, this is greatly exaggerated if you are showing a bunch of paddle links for a user to choose. That sucks really.

So I decided to make it a little more enjoyable to load up a bunch of possible subscriptions for an end user, and also make the vue component renderless. This makes it easier for me to port it between a few projects.

So off to work on a 'simplification'.

First thing, the original blade component file:

<a href="#!" data-override="{{ $url }}" {{ $attributes->merge(['class' => 'paddle_button']) }}>
    {{ $slot }}
</a>

Basically, the important things here are: href="#!", data-override="" and the css class paddle_button

Awesome, so when the component is made we just need to make sure those are there in either out component or the added ones.

Please note, there isn't any need to move away from the blade component, it's an awesome way of rendering the links each time. For this instance it didn't always work

Renderless Paddle Subscription Component

Now to the component, it is in Vuejs because currently that is the frontend it was made for :)

We can create a js file called Subscriptions.js under your js folder, your choice. Mine are in a components folder.

We know that we need to hold the links that are retrieved, a loading state and error state, so lets get those into the component

export default {
    data() {
        return {
            payLinks: [],
            loaded: false,
            error: false,
        },
    },
    render() {
        return this.$slots.default[0];
    }
}

This would be our basic component that we can return. But, I wanted to pass some things down to the elements in the slot area to use.

So we make use of the $scopedSlots property, this allows us to pass data to the slots, and then pick up those in our html side.

export default {
    data() {
        return {
            payLinks: [],
            loaded: false,
            error: false,
        },
    },
    render() {
-       return this.$slots.default[0];
+       return this.$scopedSlots.default({
+            payLinks: this.payLinks,
+            loaded: this.loaded,
+            error: this.error,
+       })
    }
}

Fetching the Paddle PayLinks from the backend over an API endpoint

Now the fun part, getting the paddle links from the server and loading them into the component

I initially had the url for the endpoint hard coded, but then realized it would be better to have it as a prop, can then use something like: endpoint="{{ route('api.billing.links') }}".

Change the component to include the following:

export default {
    data() {
        ...
    },
+   props: {
+       /**
+        * The api endpoint to fetch the billing info
+        */
+        endpoint: {
+            type: String,
+            default: '/api/settings/billing'
+        }
+    },
+   methods: {
+        fetch() {
+            axios.get(this.endpoint)
+                .then(({
+                    data: { data }
+                }) => {
+                    this.payLinks = data;
+                    this.loaded = true;
+                    this.error = false;
+                })
+                .catch(error => {
+                    this.loaded = false;
+                    this.error = true;
+                    throw error;
+                });
+       }
+    },
    render() {
        return this.$scopedSlots.default({
            payLinks: this.payLinks,
            loaded: this.loaded,
            error: this.error,
+           fetch: this.fetch
        });
    }
}

The method fetch uses the endpoint value in the axios request, this in turn loads the data from the response into the payLinks url.

We also add the fetch method to the output of the slot scope, enabling us to trigger a reload from outside the component

Adding some messages and feedback

export default {
    data() {
        return {
            payLinks: [],
            loaded: false,
            error: false,
+           message: 'Loading Subscriptions ...',
        }
    },

    ... // props

    methods: {
        fetch() {
            axios.get(this.endpoint)
                .then(({
                    data: { data }
                }) => {
                    this.payLinks = data;
                    this.loaded = true;
                    this.error = false;
                })
                .catch(error => {
                    this.loaded = false;
                    this.error = true;
+                    this.message = 'Failed to load current subscriptions';
                    throw error;
                });
        }
    },
    render() {
        return this.$scopedSlots.default({
            payLinks: this.payLinks,
            loaded: this.loaded,
            error: this.error,
+           message: this.message,
            fetch: this.fetch
        });
    }
}

Loading Paddle after getting the links.

When using the Laravel cashier-paddle package, you use the @paddleJs directive, this loads buttons that are already there. Not our vue rendered checkout button.

When checking the methods available on the Paddle object that is loaded you find that the Paddle JS file has some methods that are callable, and one that instantiates the buttons, and we can call it, awesome stuff.

So, what we do is to make use of the fact that because we are rendering the data inside the component after fetching it, we can rely on the updated method to reload the Paddle buttons. This is done using Paddle.Button.load()

So what we can do is add a new method and stick that into the updated handler:

export default {

+   updated() {
+       this.loadPaddle()
+   },

    methods: {
+       loadPaddle() {
+           // check if paddle is loaded.
+           if (Paddle) {
+               try {
+                   Paddle.Button.load();
+               } catch (error) {
+                   console.error(error);
+               }
+           }
+       }       
    },
}

Loading up the Paddle links

Right so our file now has the needed methods and data properties, the final bit, and probably really, really important is the css paddle_button.

Now lets look at the mounted method, this is where we are going to call all the methods and add the paddle_button class to our links.

    mounted() {
        this.$nextTick(() => {
            this.fetch();

            this.$el.querySelectorAll('a')
                .forEach(element => {
                    if (element.href === '#!') {
                        element.classList.add('paddle_button');
                    }
                });
        });
    },

Basically, after the component is mounted, we wait till the next tick from vue and all that, fetch the links from the backend.

We then use some good ol' Javascript 😁. Using the querySelectorAll('a') function, we can get all the links that happen to be in the slot area, loop through them, then add the class paddle_button on any link that has the href of #!. That way we don't load up other random urls to have the paddle stuff.

Final JS file

Below is the final component file, a lot nicer than the bunch of diff markings all over...

/**
 * Paddle Subscription button renderless component.
 *
 * @author ReeceM
 * @copyright MIT
 * @filename Subscriptions.js
 */

// import axios from 'axios'; // optional..

export default {
    data() {
        return {
            payLinks: [],
            loaded: false,
            error: false,
            message: 'Loading Subscriptions ...',
        }
    },

    props: {
        /**
         * The api endpoint to fetch the billing info
         */
        endpoint: {
            type: String,
            default: '/api/settings/billing'
        }
    },

    mounted() {
        this.$nextTick(() => {
            this.fetch();

            this.$el.querySelectorAll('a')
                .forEach(element => {
                    if (element.href === '#!') {
                        element.classList.add('paddle_button');
                    }
                });
        });
    },

    updated() {
        this.loadPaddle()
    },

    methods: {
        /**
         * Fetch the Paddle Paylinks from the server.
         */
        fetch() {

            this.error = false;
            this.loaded = false;

            axios.get(this.endpoint)
                .then(({
                    data: { data }
                }) => {
                    this.payLinks = data;
                    this.loaded = true;
                })
                .catch(error => {
                    this.message = 'Failed to load current subscriptions';
                    this.loaded = false;
                    this.error = true;

                    throw error;
                });
        },

        /**
         * reload the Paddle buttons
         */
        loadPaddle() {
            Paddle ? Paddle.Button.load() : console.warn('Up a creek!');
        }
    },

    render() {
        return this.$scopedSlots.default({
            payLinks: this.payLinks,
            loaded: this.loaded,
            error: this.error,
            message: this.message,
            fetch: this.fetch
        });
    }
}

Example usage

Below is an example that uses the laravel blade file, and then builds up a table with the buttons and the paylinks. The styling is in Bulma.

<subscriptions>
    <template v-slot="{payLinks, message, loaded, error, fetch}">
        <table class="table is-striped is-fullwidth table-bordered">
            <tbody>
                <tr v-if="!loaded">
                    <td v-text="message"></td>
                    <td v-if="error">
                        <div class="notification is-warning">
                            <button
                                @click=fetch()
                                class="button is-small is-outlined">
                                Retry
                            </button>
                        </div>
                    </td>
                </tr>
                <tr v-else 
                    v-for="payLink in payLinks" 
                    :key="payLink.title" >
                    <td>@{{ payLink['title'] }} Plan</td>
                    <td>terms</td>
                    <td>
                        <a
                            href="#!"
                            :data-override="payLink['link']"
                            data-theme="none"

                            class="button is-info"
                            :class="{'is-success': payLink['current']}" >
                            @{{payLink['current'] === true ? 'Subscribed' : 'Subscribe'}}
                        </a>
                    </td>
                </tr>
            </tbody>
        </table>
    </template>
</subscriptions>

To make use of the slot scope, we need to use a <template> element, then add the v-slot="{payLinks, message, loaded, error, fetch}" attribute, this allows us to access the needed data.

From there we can use the stuff inside the blade file to change how we render the Subscription links, this is nice because we don't have to recompile the JS file every time we need to make a change to a bit of wording.

Just don't forget the @ before the handlebar tags, or you going to end up with a bunch of errors from the blade engine.

I will share the follow up article to this on an example backend controller to get the links with.

I hope you enjoyed the post, please share any feedback you have on it or thoughts, you can give me a shout on twitter with @iexistin3d.

0_o

Use Morph Map of names to resolve the Model for Laravel Gate Policies

Reece M — Mon, 06 Jul 2020 21:44:36 +0000

When using the Blade directives in Laravel for authorizing resources and actions such as the @can and @cannot you have to place the classes full path into the function, eg @can(\App\User::class) or @can('App\User').

I had a cunning plan to extend the way the Gate class resolves the models in the same way as it does with Policy classes.

Laravel gives a nice way to extend the way it finds the Policy class for a model by using the Gate::guessPolicyNamesUsing() function.

The entire solution doesn't require much and allows you to add it in without causing issues.

After that you would be able to write @can('viewAny', 'users') and that would resolve to App\User or App\Models\Users

Creating the new Gate class

The first file that you would want to create is the CustomGate class. You can create it anywhere you prefer.

The class extends the normal Gate to allow normal usage.

⚠️ Important, we must ensure that it implements the Illuminate\Contracts\Auth\Access\Gate contract.

Create a file in the app\Extensions directory and call it CustomGate.php.

In that file we are going to place the following.

<?php

namespace App\Extensions;

use Illuminate\Auth\Access\Gate;
use Illuminate\Contracts\Auth\Access\Gate as AccessGate;

class CustomGate extends Gate implements AccessGate
{
    /**
     * The callback to be used to guess policy models.
     *
     * @var callable|null
     */
    protected $guessClassNameUsingCallback;

    /**
     * Get a policy instance for a given class.
     *
     * @param  object|string  $class
     * @return mixed
     */
    public function getPolicyFor($class)
    {
        if ($this->guessClassNameUsingCallback && !is_object($class)) {
            $class = call_user_func($this->guessClassNameUsingCallback, $class);
        }

        return parent::getPolicyFor($class);
    }

    /**
     * Specify a callback to be used to guess policy models.
     *
     * @param  callable $callback
     * @return $this
     */
    public function guessClassNameUsing(callable $callback)
    {
        $this->guessClassNameUsingCallback = $callback;

        return $this;
    }
}

Let's review this file quick, first off the getPolicyFor function.

    /**
     * Get a policy instance for a given class.
     *
     * @param  object|string  $class
     * @return mixed
     */
    public function getPolicyFor($class)
    {
        if ($this->guessClassNameUsingCallback && !is_object($class)) {
            $class = call_user_func($this->guessClassNameUsingCallback, $class);
        }

        return parent::getPolicyFor($class);
    }

We are overriding the default getPolicyFor function that the Laravel Gate class uses to get the model for the policy. If we have set a callback, then use that to get the class and then pass the value to the parents function.

The guessClassNameUsing() is setting the internal callback in the same way as the guessPolicyName function does. This allows the functionality to be opt-in.

That's about it for custom classes :)

Extending the Laravel Gate class

We are now going to let Service Container in Laravel know that we are using a different class when resolving the Gate contract. This means, that if we instantiate the Gate class directly, it won't have the functionality we adding.

We will place the following in the AppServiceProvider class inside the register function

    $this->app->singleton(\Illuminate\Contracts\Auth\Access\Gate::class, function ($app) {
        return new \App\Extensions\CustomGate($app, function () use ($app) {
            return call_user_func($app['auth']->userResolver());
        });
    });

Now that we have done that we can move onto how we can map our classes.

Creating a class map.

I use a single config file to keep all the Model classes for Morph Mapping in relations, for that reason I will give that example of a way to map your classes in a central place with default names. This is done as I have a few models and an array inside the Service Provider is a bit of a pain.

Right, so for example you can structure a config file (config/models.php), or even a trait like the following:

<?php
// filename: config/models.php
return [
    /*
    |---------------------------------------------------------------
    | Morph Maps
    |--------------------------------------------------------------- 
    |
    | The config for the morph Map relations
    |
    */
    'map' => [
        'users'         => \App\Models\User::class,
        'applications'  => \App\Models\Application::class,
        'comments'      => \App\Models\Comment::class,
        // another 20 odd models
        'components'    => \App\Models\Forms\Component::class,
        'templates'     => \App\Models\Forms\Template::class,
    ],
];

Now you would have that named how you like and also your model classes will be different.

But the important bit is that you can now write config('models.map.users') and get \App\Models\User::class.

Now with that class map, it is a simple matter of giving the CustomGate class a callback and this list and we are set.

Linking the string to a Model class

Open up the AuthServiceProvider and go to the boot() function as for the reason of placing the auth related part of this exercise; it is the most logical.

    Gate::guessClassNameUsing(function($class) {
        return Arr::get(config('models.map'), $class, $class);
    });

Don't forget to add use Illuminate\Support\Facades\Gate; and use Illuminate\Support\Arr; to the top of the class :)

The callback for linking the class sting to an actual class is pretty simple

Look in the model map array for $class
If its found by Arr::get() return the result
if not send back the original string and let the Parent of the Gate class handle it.

How to use this now.

Well a simple example is the following:

@can('create', 'users')
    // some element or so in the 
@endcan

Now the cool thing is you can still use App\Models\User::class and it will still get picked up.

Also if you pass the string value 'App\Models\Class', because it isn't found in the array map, it returns the search string instead of the default null.

I hope you enjoyed the article, if you have any questions you can reach me on Twitter at @iexistin3d or comment below.

ClockWorks, Web Worker library

Reece M — Mon, 08 Jun 2020 21:27:37 +0000

As a spin off from another simple static web page app that I made the other day using Alpine.js and TailwindCSS I was in the need of pushing the setInterval() functions off to the Web Worker API.

The result is a naïve implementation of a stack system to manage a set if intervals and timeouts (setTimeout() isn't available as of v0.1.x).

The whole package is cool in that it is currently less than 1KB zipped as of version 0.1, which is quite neat.

The first implementation of the system was baked into the app, and gave me a place to test the base logic and ideas.

After an afternoon to stick the package together, the simple way to have a interval firing on the web worker is below:

IMPORTANT Please note that the first few versions are only pushing the timers into the web worker, the callback is still done in the main thread.

Details

The idea was simple, and only after I added some tags to the repo did I find it's not the first but glad to know that I was on the right track before learning how others had done similar :D.

Usage is pretty simple, you can spin up the intervals/timers when you instantiate the class like so:

/**
 * Create a new instance of the class and then print the time to the console.
 *
 * We will also remove the clock after 5 seconds, by counting a variable.
 */
let triggers = 0;
let clockWorks = new ClockWorks([
    {
        name: 'clock',
        time: 1000,
        callback: () => {
            console.log((new Date()).toLocaleString())
        }
    },
    {
        name: 'remove-clock',
        time: 1000,
        callback: () => {
            if (++triggers >= 5) {
                $clock.pull('clock')
                $clock.pull('remove-clock')
            }
        }
    }
])

Or during the process of running your app you can call the push or pull methods, these allow you to selectively add or remove a timer from the stack by using the name you defined in the object.

Example of adding one:

clockWorks.push({
    name: 'new-timer',
    time: 5000,
    callback: () => {
        console.log('New interval has fired at [%s]', (new Date()).toLocaleString());
    }
})

And to pull that same one later on would be:

clockWorks.pull('new-timer');

Web Worker

I got around having to send a separate web worker as the implementation shouldn't need to be edited by bundling in the package and then using the Blob technique to get it running.

This actually has a neat side effect in that because each web worker gets a new blob url, you can create multiple instances with their own worker each.

The code that makes it possible is from a bit of finding it isn't the first time people have tried this and also the classic SO questions that have been asked. From looking at a bunch, I decided that the best way would be to do the following when installing a new Web Worker:

import workerFile from './worker';

// ... later on

// in the startWorker method, we use blob to make the url
// we convert the function into a string, and then wrap it in IIFE thingy so it runs and works correctly, that was a bit of fun.
var blob = new Blob([`(${workerFile.toString()})();`], { type: 'text/javascript' });

// then put it in a Worker thingy :)
this.worker = new Worker(window.URL.createObjectURL(blob));

The actual worker file is rather bland, but you can check it out here: worker.js

This works pretty well as its able to have the script bundled and then add it dynamically.

Microbundle

For this package I decided to use microbundle as I was not wanting a whole complex build system for something that was going to be slap stick.

It worked as advertised 🎉, LOL.

But it did to as it was labeled, straight forward and easy to get running bundler. Which is nice for this build as I was able to target different things.

Planned features

A planned feature that I will implement is to be able to define just a straight forward callback, with an optional name. This would then be tracked internally and the user will get an id they can use to pull it from the stack of timers if it is an interval one.

This would give the user the ability to do this:


let id = clockWorks.push(() => {
    var element = document.querySelector('[worker-main]');
    // select Alpine Element
    element.__x.refreshGraphData();
})

GitHub repo.

If you would like to see more details or how to make use of it you can check out the Git repo.

The library is currently in pre-release as there are still some features that can be added. PRs for any bugs are welcome too.

ReeceM / clockworks

Webworker for managing timers and intervals

0_o

How to Separate Redis Cache for Tenants

Reece M — Thu, 02 Jan 2020 13:01:34 +0000

One problem you may face when storing data into your cache is that you may have pollution of data between different apps that touch the same cache store in Laravel, I know as it has happened before and its a pain to debug.

In Redis servers there is the option to select 1 of 16 different databases within the same redis instance. This tutorial will also work on Laravel 6.x or 5.x

This is quite useful and awesome as you are able to split information incase they have the same keys or, if you want to split your main application from a trial versions data.

Laravel though when it is running normally only allows one redistribution database when connecting. This is fine, unless you want to change it during run time. No, here comes the question, how?

The use of the word 'trial' in this article is just because it is a nice way to reference a reason for switching the database, it could be anything or reason you want. But for the purpose of understanding it is 'trial' :)

Right, let's begin

Initial configuration

We will need to create a new class that extends the Laravel Illuminate\Cache\CacheManager. This is the only way I found to get this to work in a way that can be modified further on for other things.

Also it is easier as the createRedisDriver() function is protected, so it isn't easily extended.

Now you can make the class anywhere you want, for example purposes I am going to place this class in an Extensions folder, if you have preferred place to stick a class you may put it there.

Create the file: app\Extensions\CacheManager.php.

Place the following code in as your class:


<?php

namespace App\Extensions;

use Illuminate\Cache\CacheManager as BaseCacheManager;

class CacheManager extends BaseCacheManager
{
    //
}

Good, now we have the base class that extends the Laravel CacheManager as BaseCacheManager.

Configure your choice of the redis database.

For this example, we are going to use a configured setting in the config\database.php file as that way we could have the Redis instance on a separate server. (Another way is explained at the end.)

You can place a duplicated entry of the default redis connection from the database file, something similar to the following :

    'trial' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => env('REDIS_TRIAL_DB', 3), // <- note this line here.
    ],

You will notice that the above is very similar to the default one, except the 'database' one, this has a separate env variable and also a different to the default in the redis connection.

This is what changes the connection to a different database inside the same redis instance.

Changing the Connection Dynamically

Here is the fun and kinda simple part.

Inside the class that we made we are going to override the parent function createRedisDriver(), add some extra logic and then hand off the rest of the work back to the base CacheManager class.

Our function:

    /**
     * Create an instance of the Redis cache driver.
     *
     * @param  array  $config
     * @return \Illuminate\Cache\Repository
     */
    protected function createRedisDriver(array $config)
    {

        if ($someThingThatTriggersTheSwitch === true) {
            $config['connection'] = 'trial';
        }

        return parent::createRedisDriver($config);
    }

You probably noticed that there isn't actually a variable called $someThingThatTriggersTheSwitch !? and thinking I'm dumb for putting that there..., but close.

That logic can actually vary depending on what you want to do or how you are determining the reason for switching. We can make a function to handle that, or we can just straight inline it with an auth()->user()->is_trialing check.

We are going to do two similar things. The first will be the easiest for beginners to implement or for a really simple application. The other would be if you have a dedicated method to check for tenants.

Option 1.

Using a column on the users table in the database, we can use the Laravel auth() helper to get our user, and to check if we should apply the cache call.

Lets switch out the $someThingThatTriggersTheSwitch variable to a internal function, lets call it shouldSwitch().

    /**
     * This function will determine if we can change the connection.
     *
     * @return bool
     */
    protected function shouldSwitch(): bool
    {
        if (! auth()->check()) {
            return false;
        }

        return auth()->user()->is_trialing == true;
    }

Because there is the possibility that you may call the cache when there are guest users, we will first check if the user is authorized, if not just return false and use the default otherwise apply our logic check (very simple in this case).

Your if statement should look something like if ($this->shouldSwitch() === true).

Option 2 (If you have a custom tenant class)

Our method will be similar to the above style of using the shouldSwitch() function. The only difference is that we will be looking at a different source of truth if we should be switching the connection.

For example, if you have a tenant() helper or Facade that has some method of checking for tenants, you can have a function similar to the below method:

    /**
     * This function will determine if we can change the connection.
     *
     * @return bool
     */
    protected function shouldSwitch(): bool
    {
        return Tenant::isTrialing();
    }

That is relatively painless too.

If you want to look at some resources for multiple tenants and checking for them, I was able to get one instance running by using some info from Ollie Read.

Adding our dynamic Cache to the ServiceProvider

We need to let our application know that we have a new CacheManager for it to use.

So go ahead and open up your AppServiceProvider.php class.

Inside the boot() function of the provider we will extend the Laravel cache instance and override the CacheManager with our own one.

It isn't in the register() function as you cannot access the user in the auth() helper as they don't exist ... 🤷‍♂️ they somewhere else at that time.

        $this->app->extend('cache', function () {
            return new \App\Extensions\CacheManager($this->app);
        });

This overrides the already registered cache instance inside the Laravel container with our extended CacheManager class. Not that much happening.

Checking that it works.

Spin up your application. And also open up your terminal and start the redid-cli.

This part I can't really tell you what to do, but cache something as your regular user, then cache something again as the trial/ or other type of user

Once you have cached something you can see that if it did what its supposed to do from the redis cli.

From your terminal you run redis-cli, if you have it installed on a local machine or your test server.

Check the normal Laravel redis database

The normal one is database 0, in the terminal type SELECT 0 and press return (didn't say hit...)

You can then type key * and get a list of all things cached, you should see the cache key you used near the end.

Checking your 'trial' redis database

IF you left the database stuff default and didn't define a env variable the database will be 3. So in the terminal type SELECT 3, this will switch to that database.

Type key * again. You may or may not see very few entries, but one of 'em will be the new key you entered as a 'trial' user.

The extra way you could split the data.

Mentioned earlier is that you can change the way of switching other than the connection.

You can edit the prefix. In the CacheManager of laravel, it checks the actual $config variable for a prefix, this means we can override our default prefix defined in the cache config.

In our function createRedisDriver() we will change the line $config['connection'] = 'trial'; to the following:

$config['prefix'] = 'trial_cache:';

This means that we won't actually change the connection, but merely the prefix that is used when caching the data. This means that it will all be in the same redis database but with a different prefix to the cache key.

That's all 👋

Thanks for reading, leave any comments or questions. And suggestions if I can improve this article.

(A lesson learned from this: autocorrect doesn't like the word redis)

Custom Token Authentication for Laravel

Reece M — Sat, 21 Dec 2019 15:36:21 +0000

With this tutorial I will skip the “... a recent project I have been working on...” bit followed by an explanation of its details and things, I really think everybody is probably busy with some sort of side project and having a 'today I learned moment'. 🙃

🤔 What will be trying to achieve with this?

The idea is to be able to provide access tokens for users. Integrate with the default Laravel Auth system for API requests. And also log the requests that come through, whether successful or not.

Disclaimer at this point in time right now: I am not fully sure myself if the methods used are 'secure' as I am not a security specialist, duh, I do know however that it works and is a good lesson in extending the Laravel auth sections.

Things you will need to get this running.

A LAMP stack on your development machine. I am using MAMP currently to get most of all the features I need to do dev work on my mac, but you are free to use any of the other setups if you got it running already.
A computer to work on… that's a given.
Something like SequelPro or phpMyAdmin for working with your database.
A fresh install of Laravel, can be 5.8.x (or an old project as this doesn’t touch mush old code base.
A code editor, currently mine is VSCode. Sublime is also the other go to.
⏲ and ☕️
An API client tester app:
- Google ARC
- Postman
- or just cURL... :)

If you have your dev machine setup already with things, please skip to Step 3

Step 1: Setup your Stack.

I would suggest that you look at the respective install directions for the choice you choose as I don’t think it is necessary to re-write that and make a mess in the transfer of information.

I would suggest that you get your PHP instance up and running as well as mysql before installing things like composer and Laravel. This way you going to have the least headaches.

test the php by running php --version from your terminal.

For installing Laravel and getting it running please follow the official docs. Yes I know it points to 5.8, it has the stuff for setting up a local dev environment. So please use the latest requirements by laravel 6.x or 5.8 depending on your choice.

Step 2: Install a new Laravel app and DB.

Or. If you already have a project, you can go ahead and open that up and move to Begin and collect 20000.

If you have the Laravel installer on your machine, you can run:


laravel new token-api-app

If you are running composer only:

composer create-project --prefer-dist laravel/laravel token-api-app

Once you have got that running, open up the project in your code editor.

You also will want to create your database at this point.

You can use the default laravel .env settings or keep your current DB name.

CREATE DATABASE token_api_app CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Step 3: Creating your base files for the project.

Because you will be saving tokens that are generated into the database and also their usage stats, we are going to start by making the migration files and the models.

Open up your terminal if you are using an external one. Or you can open up the integrated terminal in VSCode with CMD+J.

3.1 Create your models and migrations for the app

You will now make the the model classes and the migrations using the Laravel artisan make:model command. Using this you will be able to create your two main models that will be used in this project, Token and TokenStatistic.

We are using the --migration option on the command to create the migrations for the database at the same time. (you can also use the short version -m)

php artisan make:model Token --migration

php artisan make:model TokenStatistic --migration

What would be the terminal output results you are looking for:

And the resulting files from a git status

3.2 Modify the created model classes.

You will find your two new model classes under the app directory.

Once you have those created you will replace the Model code with the following files.

Model for the `Token` class:

The Token model has relationships with the users table and also the token statistics table.

Model code for the `TokenStatistic` class:

3.3 Editing the migration files:

Our next step is to change the automatically filled in schema. Our schema is going to be pretty basic to get the system working, but obviously have enough useable data.

For your tokens table, delete what is inside the up function, then put the following inside it:

        Schema::create('tokens', function (Blueprint $table) {
            $table->bigIncrements('id');

            $table->unsignedBigInteger('user_id');

            $table->foreign('user_id')
                ->references('id')
                ->on('users');

            $table->string('name');
            $table->string('description')->default('API token');

            $table->string('api_token')->unique()->index();
            $table->integer('limit');

            $table->softDeletes();
            $table->timestamps();
        });

Next, we will change the contents of the token_statistics table, again you will delete the contents of the up function inside the migration file and replace it with the following:

        Schema::create('token_statistics', function (Blueprint $table) {
            $table->unsignedBigInteger('date')->index();

            $table->unsignedBigInteger('token_id')->nullable();
            $table->string('ip_address');
            $table->boolean('success')->default(false);
            $table->json('request');
        });

Step 4: Migrating tables. 💽

Great, you have made it this far 😅. But just before you hit continue; please ensure that inside your .env file you have your database setup correctly.

If you used the code to create your database from this tutorial, please ensure the env file is name correctly:

e.g.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306 #or 8889 if using MAMP !
DB_DATABASE=token_api_app
DB_USERNAME=root
DB_PASSWORD=root

Now we are going to run php artisan migrate in our terminals to create the new tables we have just defined.

This will run the migrations for the default migrations that are provided with Laravel, we want this as it has the users table and also stuff for failed jobs from the queue. Once the migrations are completed we can now move onto the next section.

Should look something like below:

note, i have an alias for php artisan -> artisan

Step 5: Lets make our extensions.

We are now going to create our class that is going to extend the the Laravel Illuminate\Auth\EloquentUserProvider. This is the same class that is used as the user provider for the other Auth mechanisms in the Laravel framework.

Now, you are going to create a new file under the following directory:

/app/Extensions/TokenUserProvider.php

Open that new file and place the following code in it

<?php

namespace App\Extensions;

use App\Events\Auth\TokenFailed;
use App\Events\Auth\TokenAuthenticated;

use Illuminate\Auth\EloquentUserProvider;
use Illuminate\Contracts\Support\Arrayable;
use Illuminate\Support\Str;

class TokenUserProvider extends EloquentUserProvider
{
    use LogsToken;

    /**
     * Retrieve a user by the given credentials.
     *
     * @param  array  $credentials
     * @return \Illuminate\Contracts\Auth\Authenticatable|null
     */
    public function retrieveByCredentials(array $credentials)
    {
        if (
            empty($credentials) || (count($credentials) === 1 &&
                array_key_exists('password', $credentials))
        ) {
            return;
        }

        // First we will add each credential element to the query as a where clause.
        // Then we can execute the query and, if we found a user, return it in a
        // Eloquent User "model" that will be utilized by the Guard instances.
        $query = $this->newModelQuery();

        foreach ($credentials as $key => $value) {
            if (Str::contains($key, 'password')) {
                continue;
            }

            if (is_array($value) || $value instanceof Arrayable) {
                $query->whereIn($key, $value);
            } else {
                $query->where($key, $value);
            }
        }
        $token = $query->with('user')->first();

        if (!is_null($token)) {
            $this->logToken($token, request());
        } else {
            $this->logFailedToken($token, request());
        }

        return $token->user ?? null;
    }

    /**
     * Gets the structure for the log of the token
     *
     * @param \App\Models\Token $token
     * @param \Illuminate\Http\Request $request
     * @return void
     */
    protected function logToken($token, $request): void
    {
        event(new TokenAuthenticated($request->ip(), $token, [
            'parameters' => $this->cleanData($request->toArray()),
            'headers' => [
                'user-agent' => $request->userAgent(),
            ],
        ]));
    }

    /**
     * Logs the data for a failed query.
     *
     * @param \App\Models\Token|null $token
     * @param \Illuminate\Http\Request $request
     * @return void
     */
    protected function logFailedToken($token, $request): void
    {
        event(new TokenFailed($request->ip(), $token, [
            'parameters' => $this->cleanData($request->toArray()),
            'headers' => collect($request->headers)->toArray(),
        ]));
    }

    /**
     * Filter out the data to get only the desired values.
     *
     * @param array $parameters
     * @param array $skip
     * @return array
     */
    protected function cleanData($parameters, $skip = ['api_token']): array
    {
        return array_filter($parameters, function ($key) use ($skip) {
            if (array_search($key, $skip) !== false) {
                return false;
            }
            return true;
        }, ARRAY_FILTER_USE_KEY);
    }
}

Lets have a look at the file that we just created. Firstly, we are extending a default Laravel class that handles the normal user resolution when we are using the api auth or any of the other methods, e.g. 'remember_me' tokens.

We are only going to be overriding one of the functions from the parent class in this tutorial as we will do some more with it in future ones.

Our first function then is retrieveByCredentials(array $credentials), there is nothing special about this except two things, we added logging for when the token is successful or fails.

Next we then return the user relationship from the token, and not the model/token as the normal user provider does.

The next two functions handle the login of the data, this can be customized to what you would like to be in there. Especially if you made modifications to the migration file for the tables structure.

The last function is just a simple one that cleans up any data that is in the request based on the keys. This is useful if you want to strip out the api_token that was sent and also to be able to remove any files that are uploaded as they cannot be serialized when the events are dispatched for logging.

Step 6: Registering the services.

We are going to make a custom service provider for this feature as it gives a nice way for you to make adjustments and extend it further, knowing that it is specifically this Service Provider that handles things.

Run the following command from the terminal:

php artisan make:provider TokenAuthProvider

This will now give you your Service Provider stub default.

We will want to import the following classes:

// ... other use statements

use App\Extensions\TokenUserProvider;
use Illuminate\Support\Facades\Auth;

// ...

Now that we have those, we can extend our Auth providers. Replace the boot method with the following piece of code:

   /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        Auth::provider('token-driver', function ($app, array $config) {
            // Return an instance of Illuminate\Contracts\Auth\UserProvider...
            return new TokenUserProvider($app['hash'], $config['model']);
        });
    }

Now this uses the Auth provider method to extend the list of provides that Laravel looks for when you define a provider in our config/auth.php file (more on this just now).

We are passing all the parameters from the closure directly to our new class we created in step 5.

Now, having this here is all very good and well, if Laravel's IoC new about it. As it currently is, none of this will do anything until we setup the config files.

First file we are going to edit is the config/app.php file, you will be adding App\Providers\TokenAuthProvider::class under the providers key:

         // App\Providers\BroadcastServiceProvider::class,
         App\Providers\EventServiceProvider::class,
         App\Providers\RouteServiceProvider::class,
+        App\Providers\TokenAuthProvider::class,

     ],

Next, you are going to edit the config/auth.php file.

Under the section guards change it to look like this:

        'api' => [
            'driver' => 'token',
            'provider' => 'tokens',
            'hash' => true,
        ],

        'token' => [
            'driver' => 'token',
            'provider' => 'tokens',
            'hash' => true,
        ]

Explanation: Setting the provider for both of the guards means that Laravel will look at the providers list for one called tokens, that is where we define the driver that we have created as well as what the model is that we are looking at for the api_token column.

Then, add the following under the providers:

        'tokens' => [
            'driver' => 'token-driver',
            'model' => \App\Token::class,
            // 'input_key' => '',
            // 'storage_key' => '',
        ],

The 'tokens.driver' value should match the name that you give when extending the Auth facade in the service provider.

This would complete the configuration needed to let Laravel know what is cutting with the modified auth system.

IMPORTANT Word of caution here with changing the api guard to use the tokens provider, you will have to use the proper tokens generated on the tokens table, and not the normal way that Laravel looks for an api_token column on the users table.

Step 7: Nearly there, lets make some useful additions.

We now really need a way to create tokens. Well, for this tutorial, we are going to use a console command to create the tokens we need. In the follow up articles, we are going to build a UI for managing the tokens and creating them.

To create our command we will run php artisan make:command GenerateApiToken.

In the created command under app/Console/Commands replace everything with the following into the new file:

<?php

namespace App\Console\Commands;

use App\Token;
use Illuminate\Console\Command;
use Illuminate\Support\Str;

class GenerateApiToken extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'make:token  {name : name the token}
                                        {user : the user id of token owner}
                                        {description? : describe the token}
                                        {l? : the apis limit / min}
                            ';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Makes a new API Token';

    /**
     * Execute the console command.
     *
     * @return mixed
     */
    public function handle()
    {
        $this->comment('Creating a new Api Token');
        $token = (string)Str::uuid();

        Token::create([
            'user_id'       => $this->argument('user'),
            'name'          => $this->argument('name'),
            'description'   => $this->argument('description') ?? '',
            'api_token'     => hash('sha256', $token),
            'limit'         => $this->argument('l') ?? 60,
        ]);

        $this->info('The Token has been made');
        $this->line('Token is: '.$token);
        $this->error('This is the only time you will see this token, so keep it');
    }
}

Now this command is very simple and would require you to know the users id that the token must link to, but for our purpose now it is perfectly fine.

When we use this command we will only need to provide the user id and a name. If we want we can add a description and a rate limit (this is for future updates)

Now that we have a command to run in the console as the follows:

So, we will need to make sure we have a user to create our token for, so fire up php artisan tinker

Inside there we are going to run the following code for a factory factory(\App\User::class)->create()

This will have the following type of result:

Then we can go ahead and run our command to make a new token:

Result from the `make:token` command

Then in the database you will see something similar to this:

The token and its hash in the db

Step 9: create the events and listeners.

When logging your token success or failure stats and the headers for each request, we use events and the Laravel queue system to reduce the amount of things done in a request.

If you were to make any requests before creating your event listeners and events you will get a 500 error as it can't find any of the events or listeners.

First file you will want to create is the base class the events will extend as it gives a nice way to have separate event names, but a base class constructor.

Create a file under app/Events/Auth called TokenEvent.php

You will probably have to create that directory as it might not exist.

Inside that file you will place the following code that gets a token, request and ip as its constructor arguments.

<?php

namespace App\Events\Auth;

class TokenEvent 
{
    /**
     * The authenticated token.
     *
     * @var \App\Models\Token
     */
    public $token;

    /**
     * The data to persist to mem.
     *
     * @var array
     */
    public $toLog = [];

    /**
     * The IP address of the client
     * @var string $ip
     */
    public $ip;

    /**
     * Create a new event instance.
     *
     * @param  string  $ip
     * @param  \App\Models\Token $token
     * @param  array $toLog
     * @return void
     */
    public function __construct($ip, $token, $toLog)
    {
        $this->ip    = $ip;
        $this->token = $token;
        $this->toLog = $toLog;
    }
}

In your EventServiceProvider add the following to the listeners array:


        \App\Events\Auth\TokenAuthenticated::class => [
            \App\Listeners\Auth\AuthenticatedTokenLog::class,
        ],
        \App\Events\Auth\TokenFailed::class => [
            \App\Listeners\Auth\FailedTokenLog::class,
        ],

then run php artisan event:generate to create the files automatically.

In each of these files, you will be basically replacing everything.

In the file app/Events/Auth/TokenAuthenticated.php replace everything with:

<?php
// app/Events/Auth/TokenAuthenticated.php

namespace App\Events\Auth;

use Illuminate\Queue\SerializesModels;

class TokenAuthenticated extends TokenEvent
{
    use SerializesModels;

}

The same again for the event file app/Events/Auth/TokenFailed.php, replace everything with:

<?php
// app/Events/Auth/TokenFailed.php

namespace App\Events\Auth;

use Illuminate\Queue\SerializesModels;

class TokenFailed extends TokenEvent
{
    use SerializesModels;

}

For our event listeners now, change the file app/Listeners/Auth/AuthenticatedTokenLog.php

<?php
// app/Listeners/Auth/AuthenticatedTokenLog.php

namespace App\Listeners\Auth;

use App\Events\Auth\TokenAuthenticated;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;

class AuthenticatedTokenLog implements ShouldQueue
{
    /**
     * Handle the event.
     *
     * @param  TokenAuthenticated  $event
     * @return void
     */
    public function handle(TokenAuthenticated $event)
    {
        $event->token->tokenStatistic()->create([
            'date'          => time(),
            'success'       => true,
            'ip_address'    => $event->ip,
            'request'       => $event->toLog,
        ]);
    }
}

Then for our file app/Listeners/Auth/FailedTokenLog.php:

<?php
// app/Listeners/Auth/FailedTokenLog.php

namespace App\Listeners\Auth;

use App\Events\Auth\TokenFailed;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;

class FailedTokenLog implements ShouldQueue
{
    /**
     * Handle the event.
     *
     * @param  TokenFailed  $event
     * @return void
     */
    public function handle(TokenFailed $event)
    {
        $event->token->tokenStatistic()->create([
            'date'          => time(),
            'success'       => false,
            'ip_address'    => $event->ip,
            'request'       => $event->toLog,
        ]);
    }
}

Both of the event listeners are very simple in that they just take the token that his based to the event and log it against a TokenStatistic::class relation.

For example then a use would be as follows:

event(new TokenAuthenticated($request->ip(), $token, [
    'parameters' => $this->cleanData($request->toArray()),
    'headers' => [
        'user-agent' => $request->userAgent(),
    ],
]));

A successful request would have the following in the table:

🏁 END: The really exciting part where we see things happen ‼️

To get our local dev server running, just type in to the terminal the following php artisan serve. This will get the php test server running.

Now Laravel comes with default api url route /api/user that returns your currently authenticated user.

Open up your API testing app of choice and type the following into the url input:

http://localhost:8000/api/user

Well, that is going to be quite depressing immediately as you will get a 500 error, similar to this:

Well, now add your token that you got earlier under the following section:

Now, press, don't hit the send button.

If all is well in the world of computers you should have a JSON response in the response section of your API tester similar to the below image:

We can also do the following with a cURL command from the terminal

Running curl "http://localhost:8000/api/user" You should see a whole load of info come back that means nothing.

Now run either of the following bits of code:

curl -X GET \
  http://localhost:8000/api/user \
  -H 'Authorization: Bearer YOUR_TOKEN_HERE'

curl "http://localhost:8000/api/user?api_token=YOUR_TOKEN_HERE"

You will then see a JSON response similar to the Postman/ARC one:

{"id":1,"name":"Valerie Huels DDS","email":"herman.orion@example.com","email_verified_at":"2019-12-20 23:07:17","created_at":"2019-12-20 23:07:17","updated_at":"2019-12-20 23:07:17"}

Conclusion

So congratulations, you have made it this far and put up with my strange style of explaining things or maybe you are like me and skipped all the way to the end in search of a package or something.

Well you can have a demo application that has all of this wonderfully functioning code running in it to pull a TL;DR on.

ReeceM / laravel-token-demo

A demo for a custom Laravel API token authentication tutorial

Thank you very much for putting up with my first post here and tutorial on Laravel. Please leave any suggestions in the comments or PRs on the repo if you feel so inclined.

There will be some follow up articles for this, so please keep an eye out for them.

I would really appreciate it if you enjoyed this article and feel generous to buying a coffee or something else. (I am trying to create a new application for the php community)

Reece - o_0