If you go through the trouble setting up a contact-form on your website you might as well take the extra mile, or in this case the extra 20 minutes to make it bot-proof by using the Google [ReCaptcha v3 service](https://developers.google.com/recaptcha). In this article I'll explain what steps I took and the code needed to protect the contact form on this website.

## Step one: register your website

First you need to register your website in order to acquire the keys needed to communicate with the service:

![Google reCAPTCHA v3 registration](/gallery/2023/06/18/google-recaptcha-v3-register.jpg)
![Google reCAPTCHA v3 keys](/gallery/2023/06/18/recaptcha-keys.jpg)

## Step two: have the keys set up

As this website is built with [Next.js 13](https://nextjs.org/) the environment variables for the client-side need to be present on *build-time*, meaning I have set them up in a CI/CD -variable (of type file) in my GitLab installation and reference them as follows:

~~~yaml
build app:
  stage: build
  cache:
    paths:
      - node_modules
  artifacts:
    paths:
      - .next
  before_script:
    - cp "$ENV_FILE_PATH" .env
  script:
    - npm run build
~~~

The contents for the `.env` -file is written next to the source code and will then look similar to this:

~~~ini
NEXT_PUBLIC_RECAPTCHA_SITE_KEY=<nope>
RECAPTCHA_SECRET_KEY=<even-more-nope>
~~~

As you can see, the first environment variable name is prefixed with `NEXT_PUBLIC_`, which is [replaced build-time](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables#bundling-environment-variables-for-the-browser) in the source code by Next.js and is therefore available in the client-side code as well. The secret-key on the other hand must only be available to the server-side code, which calls the reCAPTCHA -service from the endpoint we use to handle the contact-form request.

## Step three: the backend-handler for the form

Lets create an API-endpoint for handling the form submit -request. We'll have a file `pages/api/contact.ts` for that purpose:

~~~typescript
import {NextApiRequest, NextApiResponse} from "next";
import {Response} from "next/dist/compiled/@edge-runtime/primitives/fetch";

type RecaptchaResponse = {
    success: boolean       // whether this request was a valid reCAPTCHA token for your site
    score: number          // the score for this request (0.0 - 1.0)
    action: string         // the action name for this request (important to verify)
    challenge_ts: string   // timestamp of the challenge load (ISO format yyyy-MM-dd'T'HH:mm:ssZZ)
    hostname: string       // the hostname of the site where the reCAPTCHA was solved
    "error-codes": any[]   // optional
}

const verifyRecaptcha = async (token:string): Promise<RecaptchaResponse> => {
    const secret = process.env.RECAPTCHA_SECRET_KEY;

    const url = `https://www.google.com/recaptcha/api/siteverify?secret=${secret}&&response=${token}`;

    return await fetch(url).then((response: Response) => response.json());
}

export default async function handler(req: NextApiRequest, res: NextApiResponse): Promise<void> {
    try {
        const token = req.body.gRecaptchaToken;
        const response = await verifyRecaptcha(token);

        if (!response.success) {
            console.log("Google RECAPTCHA v3 returned a failure with the following response:" + response);
            return res.status(500).json({status: "error", message: "Something went wrong, please try again."});
        }

        console.log("Google RECAPTCHA v3 returned a success with score of " + response.score);

        // see https://developers.google.com/recaptcha/docs/v3#interpreting_the_score for more information
        if (response.score < 0.5) {
            return res.status(403).json({status: "error", message: "reCAPTCHA score too low"});
        }
    } catch (error) {
        return res.status(500).json({status: "error", message: "Something went wrong, please try again!"});
    }

    // Here you do whatever you want to do with the actual form data and don't forget to return an "ok" response:
    res.status(202).end();
}
~~~

So what we have here is the `verifyRecaptcha`-function that is just a helper to make the actual call to the reCAPTCHA -service; It will return a response which is modeled above with the type `RecaptchaResponse`. This is just a brief example and is lacking a lot of error-checking with the `fetch`-call etc as it's beyond the scope of this article.

The handler itself is the "controller" of the API-endpoint and will take care of the request against route `/api/contact`. There the token from the form (generated by the reCAPTCHA frontend-library) is checked against Google's endpoint, and if the response is ok and the score high enough (0.5 in this case) we're good to go.

## Step five: the reCAPTCHA frontend integration and the form itself

I used the [react-google-recaptcha-v3](https://www.npmjs.com/package/react-google-recaptcha-v3) -package for managing the settings and dependencies for reCAPTCHA. It is used by wrapping your components inside it, so my `pages/_app.tsx` looks roughly like this:

~~~tsx
import type {AppProps} from 'next/app'
import React from "react";
import {GoogleReCaptchaProvider} from "react-google-recaptcha-v3";

const RECAPTCHA_SITE_KEY = process.env.NEXT_PUBLIC_RECAPTCHA_SITE_KEY ?? '';

export default function App({Component, pageProps}: AppProps) {
    return <>
        <GoogleReCaptchaProvider
            reCaptchaKey={RECAPTCHA_SITE_KEY}
            scriptProps={{
                async: false,
                defer: false,
                appendTo: 'body',
            }}
        >
            <div className="page-container">
                <Component {...pageProps} />
            </div>
        </GoogleReCaptchaProvider>
    </>
}
~~~

The actual contact-page is located at `pages/contact.tsx` and looks similar to this:

~~~tsx
import React, {useCallback, useState} from "react";
import {useGoogleReCaptcha} from "react-google-recaptcha-v3";

export default function ContactPage(): JSX.Element {
    const [isSending, setIsSending] = useState<boolean>(false)
    const [hasSubmitted, setHasSubmitted] = useState<boolean>(false)
    const [email, setEmail] = useState<string>("")
    const [firstName, setFirstName] = useState<string>("")
    const [lastName, setLastName] = useState<string>("")
    const [message, setMessage] = useState<string>("")
    const { executeRecaptcha } = useGoogleReCaptcha();

    const onSubmit = useCallback((e: React.FormEvent<HTMLFormElement>) => {
            e.preventDefault()
            setIsSending(true)
            if (!executeRecaptcha) {
                return;
            }

            executeRecaptcha("contactFormSubmit")
                .then((gRecaptchaToken) => {
                    const data = {
                        email,
                        firstName,
                        lastName,
                        message,
                        gRecaptchaToken,
                    };

                    try {
                        fetch('/api/contact', {
                            method: 'POST',
                            headers: {
                                Accept: "application/json, text/plain, */*",
                                "Content-Type": "application/json",
                            },
                            body: JSON.stringify(data),
                        }).then(response => {
                            if (!response.ok) {
                                throw new Error(`Invalid response: ${response.status}`);
                            }
                            setHasSubmitted(true)
                            setIsSending(false)
                        })
                    } catch (err) {
                        alert("An error occurred, please try again later,");
                    }
                });
        }, [executeRecaptcha, setIsSending, email, firstName, lastName, message]
    );

    return (
        <main>
            {hasSubmitted ?
                <div>Thanks for contacting us, we will get back to you soon!</div>
                :
                <div className={`form-container`}>
                    <form onSubmit={onSubmit}>
                        <fieldset disabled={isSending || !executeRecaptcha}>
                            <div className="row">
                                <div className="col-25">
                                    <label htmlFor="email">Email</label>
                                </div>
                                <div className="col-75">
                                    <input type="email" id="email" name="email" value={email} onChange={(e) => setEmail(e.target.value)} required/>
                                </div>
                            </div>
                            <div className="row">
                                <div className="col-25-dual">
                                    <label htmlFor="firstName">First name</label>
                                </div>
                                <div className="col-25-dual">
                                    <input type="text" id="firstName" name="firstName" value={firstName} onChange={(e) => setFirstName(e.target.value)}/>
                                </div>
                                <div className="col-25-dual">
                                    <label htmlFor="lastName">Last name</label>
                                </div>
                                <div className="col-25-dual">
                                    <input type="text" id="lastName" name="lastName" value={lastName} onChange={(e) => setLastName(e.target.value)}/>
                                </div>
                            </div>
                            <div className="row">
                                <div className="col-25">
                                    <label htmlFor="message">Message</label>
                                </div>
                                <div className="col-75">
                                    <textarea id="message" name="message" rows={10} value={message} onChange={(e) => setMessage(e.target.value)}/>
                                </div>
                            </div>
                            <div className="row">
                                <input type="submit" value="Send"/>
                            </div>
                        </fieldset>
                        <small>This site is protected by reCAPTCHA and the Google <a href="https://policies.google.com/privacy">Privacy Policy</a> and <a href="https://policies.google.com/terms">Terms of Service</a> apply.</small>
                    </form>
                </div>
            }
        </main>
    )
}
~~~

Nothing special here: the state of the form and it's fields is managed through React `useState` -hooks, the token for the reCAPTCHA is obtained by using the `useGoogleReCaptcha` -hook and sent along with the form fields to the backend with simple `fetch` -call.

## The final touch

The reCAPTCHA badge is rather large, especially viewed on mobile devices and since we use it only on one page here it feels it takes a bit too much screen-realestate. Thankfully you can hide it as long as you include the T&C's from Google as demonstrated between the small-tags below the form. Now you can just add the following css snippet to your stylesheet and the badge is no more:

~~~css
.grecaptcha-badge {
  visibility: hidden;
}
~~~

## Conclusion

As you can see it doesn't take that much time nor effort to integrate Google reCAPTCHA service on your website, but it'll probably save you a lot of time and effort by not having to go through more spam in your inbox.

If you go through the trouble setting up a contact-form on your website you might as well take the extra mile, or in this case the extra 20 minutes to make it a bot-proof by using the Google ReCaptcha v3 service.

Contact-form with Google ReCaptcha v3

Making Next.js forms bot-proof using ReCaptcha v3

When I started re-writing this website (again) I decided to go with the old-faithful [Next.js](https://nextjs.org/) which I have been rather happy with in the past. Now, like everything in the Javascript/Typescript/Node/npm -ecosystem everything changes completely if you make the mistake of looking away for two seconds, and while change is usually good and there is nothing permanent except change it sometimes takes a while to adapt when whole concepts get thrown away. This hit me hard with the deprecation of *getInitialProps()*, which I actually learned to like and while having it's problems in some use-cases I never had any issues with it. You could argue that "it is only deprecated, you can still use it" and while this is true I'd rather learn the new ways as I go and not hang in the past, or I'll deprecate myself as I go.

## So what's with Next.js 13 and what's new?

Actually, the recommended way to use Next.js 13.4 is to use the [App-router](https://nextjs.org/blog/next-13-4) and the previous "pages router" is probably going to be a thing in the past in the near future. This change happened after I started my work so I'm sticking with this until I get things stable and I have time to either experiment with the App-router or move over to something completely different (looking at [Remix](https://remix.run) and maybe having a serverless front, using [Cloudflare pages](https://pages.cloudflare.com/) etc).

So in short: the [getInitialProps](https://nextjs.org/docs/pages/api-reference/functions/get-initial-props) is deprecated and the way to do things with Next.js 13 pages routing can be picked from [these](https://nextjs.org/docs/pages/building-your-application/rendering):

* **Server Side Rendering (SSR):** export a *getServerSideProps()* -function which is called on server-sider on every render
* **Static Site Generation (SSG):** export a *getStaticProps()* -function which is called on **BUILD-TIME**, and also *getStaticPaths()* -function if you have dynamic routing
* **Incremental Static Regeneration (ISR):** same as previous, but with revalidate-value from returned from those functions to update contents in the background
* **Client-side Rendering (CSR):** just fetch data on the client-side
* **Edge and Node.js Runtimes:** in practise vendor-locking yourself with [Vercel](https://vercel.com) or managing the whole infrastructure yourself

The first option is good for SEO but even with careful caching it will not be a SPA-like experience. The second one expects you to have really static content, which rarely is an actual, real-world situation. Fourth option kills your SEO and for the fifth I don't have the time now nor do I want to go the Vercel-way.

So I'm left with the middle one and it has it's own problems: the ISR is built on top of SSG, meaning that the site-content still needs to be built completely on **BUILD-TIME**, meaning I cannot simply have this on my ".gitlab-ci.yml" and get on with it:


~~~yaml
lint:
  stage: test
  cache:
    paths:
      - node_modules
  script:
    - npm install
    - npm run lint

build app:
  stage: build
  variables:
    NEXT_TELEMETRY_DISABLED: "1"
  cache:
    paths:
      - node_modules
  artifacts:
    paths:
      - .next
  script:
    - npm run build
~~~

Why? Because the next app tries to call the *getStaticProps()* and *getStaticPaths()* -functions on each page that has them and build the contents to .next/static/chunks/pages. Depending how your CI/CD is configured this may or may not work at all and is sub-optimal to say the least if the site is being built from scratch and the endpoints are not online yet. I'd even go as far as calling it an anti-pattern.

Again I'm left with a couple of options:

- Prevent the static content-generation at build time
- Nuke the cached content from the Docker image  after build and have it created lazily on production

As it turns out I cannot completely prevent the static content to be generated - npm run build calls the aforementioned functions and that's that. And I'd have to generate some kind of dummy output from them the first place to have this issue fixed with the second option. Now my hacky solution is a mix of those two:

### 1. Tell the app about build-time

I have the "build app" script line from ".gitlab-ci.yml" modified like this to tell the app not to call any endpoints:

~~~yaml
  script:
    - SKIP_GET_STATIC_PROPS=true npm run build
~~~

### 2. Detect build-time and return "empty" json from getStaticProps() and getStaticPaths()

My *getStaticProps()* looks something like this:

~~~typescript
export const getStaticProps: GetStaticProps<HomePageProps> = async () => {
    if (process.env.SKIP_GET_STATIC_PROPS) {
        return {
            props: {},
            revalidate: 1,
        }
    }

    // ... actual fetching is done around here and returned:

    return {
        props: {
            articles,
            content,
        },
        revalidate: 60,
    }
}
~~~

The *getStaticPaths()* on those pages that have dynamic routing look something like this:

~~~typescript
export async function getStaticPaths() {
    if (process.env.SKIP_GET_STATIC_PROPS) {
        return {
            paths: [],
            fallback: 'blocking',
        }
    }

    // ... fetch the dynamic paths and return them in the paths -key plus tell the server to check for new content if it's not found pre-rendered

    return {
        paths, fallback: 'blocking',
    }
}
~~~

One more issue remains: Next.js serves stale content on the first request (that dummy content in this case) and then in the background tries to regenerate it and on upcoming requests the client will receive up-to-date content. This means some poor user might end up with a "loading..." screen I made, which is not exactly optimal.

That's when I decided to do something naughty on the *docker-entrypoint.sh*.

### 3. Implement a "magic" -endpoint for on-demand revalidation and call it at start of the app

So you can implement an endpoint for doing on-demand revalidation and here's the code I use in *pages/api/revalidate.ts*:

~~~typescript
import {NextApiRequest, NextApiResponse} from "next";

export default async function handler(req: NextApiRequest, res: NextApiResponse): Promise<void> {
    if (process.env.NEXT_REVALIDATE_TOKEN === undefined || process.env.NEXT_REVALIDATE_TOKEN === '') {
        res.status(500).json({ message: 'Missing token'});
        return
    }

    if (req.query.secret !== process.env.NEXT_REVALIDATE_TOKEN) {
        res.status(401).json({ message: 'Invalid token'});
    }

    const path = Array.isArray(req.query.path) ? req.query.path[0] : req.query.path;

    if (!path) {
        res.status(400).json({ message: 'Missing path'});

        return
    }

    try {
        await res.revalidate(path);
        res.json({revalidated: true});
    } catch (err) {
        res.status(500).send('Error revalidating');
    }
}
~~~

And with all the type- and error-checking the beef boils down to this one simple command: *res.revalidate(path)*.

A point you should be raising now is that you cannot call anything **AFTER** the *Dockerfile* CMD is called, i.e. you cannot call any endpoints once the app has started. Except you can, if you abuse it a bit.

You can always fork a process before you exec the CMD and have a sleep statement take care of the delay. So here's a *docker-entrypoint.sh* I use:

~~~shell
#!/usr/bin/env sh
set -euo pipefail

export NEXT_REVALIDATE_TOKEN=$(cat /dev/urandom | tr -dc '[:alpha:]' | head -c 20 | head -n 1)

/usr/local/bin/preload-cache.sh &

exec $@
~~~

And the actual "magic" happens in the *preload-cache.sh* which looks like this:

~~~shell
#!/usr/bin/env sh
set -euo pipefail

sleep 3

if [ "$NODE_ENV" != "production" ]; then
    # Technically /app/.next/static/chunks/pages has no matching files in non-production environment, but lest be verbose
    echo "Skip cache revalidate on non-production environment..."
    exit 0
fi;

function revalidate() {
    echo -n "invalidating chunk: ${1}..."
    CHUNK=$(echo "${1}" | sed -r 's/\[/%5B/' | sed -r 's/\]/%5D/' )
    curl -s "http://localhost:3000/api/revalidate?path=${CHUNK}&secret=${NEXT_REVALIDATE_TOKEN}" > /dev/null
    echo "done"
}

function warmup() {
    echo -n "warming up endpoint: ${1}..."
    curl -s "http://localhost:3000${1}" > /dev/null
    echo "done"
}

cd /app/.next/static/chunks/pages

find . -regex ".*/[^_]*-.*\.js" | sed -rn 's/^\.(.*)-[0-9a-z]+\.js$/\1/p' | sed -r 's/^\/index$/\//' | while read -r line ; do
    revalidate "${line}"
done

find . -regex ".*/[^_\[]*-.*\.js" | sed -rn 's/^\.(.*)-[0-9a-z]+\.js$/\1/p' | sed -r 's/^\/index$/\//' | while read -r line ; do
    warmup "${line}"
done
~~~

So what happens here is that I introduce a variable called *NEXT_REVALIDATE_TOKEN* with some random-enough value so that not just anyone can ask for revalidating the content. Then I fork a process that first calls the revalidate endpoint for every route I have, the list of which I gather from *.next/static/chunks/pages* with the help of little regular-expression-find-sed -combo. Then, since I can, I'm also calling all the static routes and pre-generating them. For the dynamic ones I realize I cannot do the same as I don't  know the routes here, but at least the index-page and all the other static routes are ready to be pounded immediately. The dynamic routes have no content and they will be "forcefully" generated on first request due to the *fallback: "blocking"* from the *getStaticPaths()* and that's good enough for me now.

## Final thoughts

Is this a good idea? Probably not. Should you (nor I) do this? Also probably no. This was more a can-I-do-this -challenge and will probably revisit this whole thing and implement something more feasible and sane later once I have more time on my hands.

When I started re-writing this website (again) I decided to go with the old-faithful Next.js.

How I hacked the crap out of Next.js ISR

I have re-written this website from scratch maybe three or four times already and scrapped all the written content as I wasn't happy with the stuff I wrote or wasn't sure about the direction I want to take with this thing. One time I wanted to write articles about photography from learning/teaching point-of-view but as I climbed up the [Mount Stupid](https://medium.com/workmatters/the-dunning-kruger-effect-climbing-mount-stupid-navigating-the-valley-of-despair-and-ascending-b22d37c1e6f9) I realized I wasn't even sure who I was writing them for. At one point I wanted to make photography gear reviews, but then again I am not [Ken Rockwell](https://www.kenrockwell.com/tech/reviews.htm) nor do I want to be. This is all just a tip of an ice-berg, but hopefully you get the idea.

## ...So I was diagnosed with ADHD

Turns out I'm neurologically wired a bit different than an average person, which in my case means I have a tendency to lose interest "quite" quickly and find more interesting stuff to do "mid-journey". But its not all bad news as [ADHD](https://en.wikipedia.org/wiki/Attention_deficit_hyperactivity_disorder) *can* be a "superpower": for example if I find something interesting I will most definitely handle it, be it a chore at home or a challenging task at work. The hyper-focus is also an actual thing: there's no time- nor effort-limit when it comes doing something I really really want to do. The trick is to manage these tendencies, and boy am I a challenging person to manage as I don't simply do as told. Instead, I need to be fed with interesting things and challenges.

## Back to this website

I most definitely love writing software and learning about new technologies and so forth. I also enjoy [photography](/photography) and even I don't see myself being hugely talented I don't mind publishing the photos on this website. So I decided if I find something interesting to publish in technology/software engineering I will publish it or if I finally have time some day to take more photos I will most likely publish them here. My website, my rules. Most likely you'll see me ranting or being excited about anything related building and developing this website as I go, explaining my technology-choices and how I deploy all this.

...or the topics might just as well completely different next week :D

Ps. note to self: stop using smileys in blog posts...

Pps. also you shouldn't use those stupid three commas at the end of a sentence.

I also do realize this whole thing could be hosted on [Wordpress](https://wordpress.com/) for a few dollars a month, but where's the fun in that?

I have re-written this website from scratch maybe three or four times already and scrapped all the written content as I wasn't happy with the stuff I wrote or wasn't sure about the direction I want to take with this thing.

Me, myself and I; photo credits: Teemu Riihelä

Another new beginning

Strobotti.com is where yours truly exhibits his photography and rants about technology and such