DEV Community: Magic Labs

Build a Paid Membership Site with Magic and Stripe: Pt. 4 - Deploy to Heroku

Maricris Bonzo — Wed, 10 Mar 2021 01:28:26 +0000

This is the final part of the Build a Paid Membership Site with Magic and Stripe series. Make sure to read the following articles before proceeding:

Quickstart to set up Stripe and Magic.
How the React client side is built.
How the Node server side is built.

Deploying to Heroku

Create a Project

🚀 Want to deploy your app on Heroku? First, install the Heroku CLI. Then run heroku create to generate a new Heroku project. It will return your Heroku app URL, similar to what is shown below.

$ heroku create

Creating app... done, ⬢ cryptic-waters-25194
https://cryptic-waters-25194.herokuapp.com/ | https://git.heroku.com/cryptic-waters-25194.git

Set Config Vars (.env)

Now let's set the production .env variables for our app. Locate your new project on Heroku and go to Settings. In Heroku, we set up .env variables under Config Vars. Click Reveal Config Vars and enter both of your client and server side environment variables.

Update Server.js

Add the following into your server.js file so that Heroku knows how to build your app.

/* File: server.js */

// For heroku deployment
if (process.env.NODE_ENV === 'production') {
  app.use(express.static('client/build'));
  app.get('*', (req, res) => {
    res.sendFile(path.resolve(__dirname, 'client', 'build', 'index.html'));
  });
}

Update Package.json

In package.json, add this to the scripts object:

/* File: The server's package.json */

"heroku-postbuild": "NPM_CONFIG_PRODUCTION=false npm install --prefix client && npm run build --prefix client"

Now you can run the following commands to deploy your application:

$ git add .
$ git commit -m 'your message'
$ git push heroku master

Heroku should have given you a link to your live app. Congrats! 🎉

Outro

That's it for today! If you'd like more tutorials on Stripe x Magic, (e.g. how to create a subscription membership website) please let us know in the comments section below.

Until next time 🙋🏻‍♀️ ♡.

Build a Paid Membership Site with Magic and Stripe: Pt. 3 - Node Server

Maricris Bonzo — Wed, 10 Mar 2021 01:25:10 +0000

This is the third part of the Build a Paid Membership Site with Magic and Stripe series. Make sure to read the following before proceeding:

Quickstart to set up Stripe and Magic.
How the React client side is built.

Server

Now that we understand how the Client side is built and how it works, let's learn about our Server side code (located in server.js).

Here are the major functions our server needs to work seamlessly with the Client:

Validate the Auth Token (didToken) returned by Magic's loginWithMagicLink().
Create a Stripe PaymentIntent to keep track of the Customer's payment lifecycle.
Create a Stripe Customer so that we can tie the Customer to a matching PaymentIntent and keep track of whether or not the Customer has successfully paid.
Validate that the user is indeed a Customer who has lifetime access to your Premium Content.

Validate the Auth Token (didToken)

As mentioned, when the user clicks the email link to log in, we send the didToken to a server endpoint called /login in order to validate it. It's best practice to validate the DID Token before continuing to avoid invalid or malformed tokens.

We verify the didToken with Magic's validate method. If the didToken is indeed valid, we then send a 200 status code back to the client.

/* File: server.js */

// Import, then initiate Magic instance for server-side methods
const { Magic } = require("@magic-sdk/admin");
const magic = new Magic(process.env.MAGIC_SECRET_KEY);

// Route to validate the user's DID token
app.post("/login", async (req, res) => {
  try {
    const didToken = req.headers.authorization.substr(7);
    await magic.token.validate(didToken);
    res.status(200).json({ authenticated: true });
  } catch (error) {
    res.status(500).json({ error: error.message });
  }
});

Create a Stripe Payment Intent and Stripe Customer

Once a user decides to buy a lifetime access pass to our Premium Content, we consider them a customer. In order to keep track of the customer's payment cycle, we'll need to add a new server endpoint called /create-payment-intent in server.js that:

Creates a customer with their email address.
And then creates a PaymentIntent that is linked to this customer.

The PaymentIntent will keep track of any failed payment attempts and ensures that the customer is only charged once.

/* File: server.js */

// Import & initiate Stripe instance
const  stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

// Add the user to your list of customers
// Then create a PaymentIntent to track the customer's payment cycle
app.post("/create-payment-intent", async (req, res) => {
  const { email } = req.body;

  const paymentIntent = await stripe.customers
    .create({
      email,
    })
    .then((customer) =>
      stripe.paymentIntents
        .create({
          amount: 50000, // Replace this constant with the price of your service
          currency: "usd",
          customer: customer.id,
        })
        .catch((error) => console.log("error: ", error))
    );

  res.send({
    clientSecret: paymentIntent.client_secret,
    customer: paymentIntent.customer,
  });
});

As you can see, we'll be charging our customers $500 for a lifetime access pass to our awesome Premium Content. 😎

Update the Stripe Customer's Info

As soon as the payment goes through, the Client side will send a request to /update-customer to update the Stripe Customer's information with a metadata of { lifetimeAccess: true }. Since we have a special use case; charging customers a one time fee, setting this metadata will help us validate whether or not the customer has paid.

/* File: server.js */

// Update the customer's info to reflect that they've
// paid for lifetime access to your Premium Content
app.post("/update-customer", async (req, res) => {
  const { customerID } = req.body;

  const customer = await stripe.customers.update(customerID, {
    metadata: { lifetimeAccess: true },
  });

  res.send({
    customer,
  });
});

Validate a Paid Customer

Now that the user has successfully paid, they should be able to access the Premium Content page. To check whether or not the user is authorized, we'll be using the /validate-customer endpoint. It expects the user's email address, and returns a list of customers who has that email.

Ideally, your customer should know to only buy their lifetime access once. This way, the list that stripe.customers.list() returns will always have the single customer who paid.

However, accidents do happen. 🤷🏻‍♀️

To prevent users from purchasing a lifetime access twice, I suggest adding some logic to your SignUp component that checks whether or not the user who's trying to sign up is already a Stripe Customer with lifetime access. If they are, send them to the Premium Content page. Otherwise, they can continue to the Payment page.

/* File: server.js */

// Collect the customer's information to help validate
// that they've paid for lifetime access
app.post("/validate-customer", async (req, res) => {
  const { email } = req.body;

  const customer = await stripe.customers.list({
    limit: 1,
    email,
  });

  res.send({
    customer: customer.data,
  });
});

Test the integration

Alright, now that we know how the paid membership app works on both the Client and Server side, let's give it a test run! Here are a few UX flows I suggest testing out:

Head to the Premium Content page to sign up and pay for lifetime access.
Log in as a paid Customer and try to access the Premium Content page.
Using a different email, log in as an unpaid Customer and try to access the Premium Content page.

Btw, you can make your payments with this test card number: 4242 4242 4242 4242

What's next

YAY! You now have a paid membership site. Read our final article of this series to learn how to deploy your app to Heroku.

Build a Paid Membership Site with Magic and Stripe: Pt. 2 - React Client

Maricris Bonzo — Wed, 10 Mar 2021 01:01:25 +0000

This is the second part of the Build a Paid Membership Site with Magic and Stripe series. Make sure to follow our Quickstart article before proceeding.

Client

Let's dive right in by going over the major steps we need to follow to build the paid membership site's Client side:

Set up the user sign up, payment, login, and logout flows.
Build the payment form as well as the Payment page that will house the form.
Make this Payment page accessible to the user by creating a Payment Route.

Standard Auth Setup

Keep Track of the Logged In User

We'll be keeping track of the logged in user's state with React's useContext hook. Inside App.js, wrap the entire app in <UserContext.Provider>. This way, all of the child components will have access to the hook we created (namely, const [user, setUser] = useState();) to help us determine whether or not the user is logged in.

/* File: client/src/App.js */

import React, { useState, useEffect } from "react";
import { Switch, Route, BrowserRouter as Router } from "react-router-dom";
import { UserContext } from "./lib/UserContext";

// Import UI components
import Home from "./components/home";
import  PremiumContent  from  "./components/premium-content";
import Login from "./components/login";
import  SignUp  from  "./components/signup";
import Profile from "./components/profile";
import Layout from "./components/layout";

// Import Magic-related things
import { magic } from "./lib/magic";

function App() {

  // Create a hook to help us determine whether or not the  user is logged in
  const [user, setUser] = useState();

  // If isLoggedIn is true, set the UserContext with user data
  // Otherwise, set it to {user: null}
  useEffect(() => {
    setUser({ loading: true });
    magic.user.isLoggedIn().then((isLoggedIn) => {
      return isLoggedIn
        ? magic.user.getMetadata().then((userData) => setUser(userData))
        : setUser({ user: null });
    });
  }, []);

  return (
    <Router>
      <Switch>
        <UserContext.Provider value={[user, setUser]}>
              <Layout>
                <Route path="/" exact component={Home} />
                <Route path="/premium-content" component={PremiumContent} />
                <Route path="/signup" component={SignUp} />
                <Route path="/login" component={Login} />
                <Route path="/profile" component={Profile} />
              </Layout>
        </UserContext.Provider>
      </Switch>
    </Router>
  );
}

export default App;

Note: Once a user logs in with Magic, unless they log out, they'll remain authenticated for 7 days.

Keep Track of the Paid User

We'll also be keeping track of whether or not the user has paid for lifetime access with the useContext hook. Again, inside of App.js, we wrap the entire app with two new contexts: <LifetimeContext>, then <LifetimeAccessRequestStatusContext>.

/* File: client/src/App.js */
import React, { useState, useEffect } from "react";
import { Switch, Route, BrowserRouter as Router } from "react-router-dom";
import { UserContext } from "./lib/UserContext";
import { LifetimeContext } from "./lib/LifetimeContext";
import { LifetimeAccessRequestStatusContext } from "./lib/LifetimeAccessRequestStatusContext";

// Import UI components
import Home from "./components/home";
import  PremiumContent  from  "./components/premium-content";
import Login from "./components/login";
import  SignUp  from  "./components/signup";
import Profile from "./components/profile";
import Layout from "./components/layout";

// Import Magic-related things
import { magic } from "./lib/magic";

function App() {

  // Create a hook to check whether or not user has lifetime access
  const [lifetimeAccess, setLifetimeAccess] = useState(false);
  // Create a hook to prevent infinite loop in useEffect inside of /components/premium-content
  const [
    lifetimeAccessRequestStatus,
    setLifetimeAccessRequestStatus,
  ] = useState("");
  // Create a hook to help us determine whether or not the  user is logged in
  const [user, setUser] = useState();

  // If isLoggedIn is true, set the UserContext with user data
  // Otherwise, set it to {user: null}
  useEffect(() => {
    setUser({ loading: true });
    magic.user.isLoggedIn().then((isLoggedIn) => {
      return isLoggedIn
        ? magic.user.getMetadata().then((userData) => setUser(userData))
        : setUser({ user: null });
    });
  }, []);

  return (
    <Router>
      <Switch>
        <UserContext.Provider value={[user, setUser]}>
          <LifetimeContext.Provider value={[lifetimeAccess, setLifetimeAccess]}>
            <LifetimeAccessRequestStatusContext.Provider
              value={[
                lifetimeAccessRequestStatus,
                setLifetimeAccessRequestStatus,
              ]}
            >
              <Layout>
                <Route path="/" exact component={Home} />
                <Route path="/premium-content" component={PremiumContent} />
                <Route path="/signup" component={SignUp} />
                <Route path="/login" component={Login} />
                <Route path="/profile" component={Profile} />
              </Layout>
            </LifetimeAccessRequestStatusContext.Provider>
          </LifetimeContext.Provider>
        </UserContext.Provider>
      </Switch>
    </Router>
  );
}

export default App;

As you can see, we've added two new hooks. The first hook will help us determine whether or not user has lifetime access:

const [lifetimeAccess, setLifetimeAccess] = useState(false);

While the second hook will help us prevent an infinite loop of component re-renderings caused by the useEffect inside of /components/premium-content.

  const [
    lifetimeAccessRequestStatus,
    setLifetimeAccessRequestStatus,
  ] = useState("");

Log in with Magic Link Auth

In client/src/components/login.js, magic.auth.loginWithMagicLink() is what triggers the magic link to be emailed to the user. It takes an object with two parameters, email and an optional redirectURI.

Magic allows you to configure the email link to open up a new tab, bringing the user back to your application. Since we won't be using redirect, the user will only get logged in on the original tab.

Once the user clicks the email link, we send the didToken to a server endpoint at /login to validate it. If the token is valid, we update the user's state by setting the UserContext and then redirect them to the profile page.

/* File: client/src/components/login.js */

  async function handleLoginWithEmail(email) {
    try {
      setDisabled(true); // Disable login button to prevent multiple emails from being triggered

      // Trigger Magic link to be sent to user
      let didToken = await magic.auth.loginWithMagicLink({
        email,
      });

      // Validate didToken with server
      const res = await fetch(`${process.env.REACT_APP_SERVER_URL}/login`, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
          Authorization: "Bearer " + didToken,
        },
      });

      if (res.status === 200) {
        // Get info for the logged in user
        let userMetadata = await magic.user.getMetadata();
        // Set the UserContext to the now logged in user
        await setUser(userMetadata);
        history.push("/profile");
      }
    } catch (error) {
      setDisabled(false); // Re-enable login button - user may have requested to edit their email
      console.log(error);
    }
  }

Sign up with Magic Link Auth

We'll be applying practically the same code as in the Login component to our SignUp component (located in client/src/components/signup.js). The only difference is the user experience.

When a user first lands on our page, they'll have access to our Free Content.

We can also show them a sneak peek of our awesomeness in the Premium Content page.

Once they realize how awesome we are, and have decided to pay $500 for a lifetime access pass, they can click Count Me In.

Since the user is not logged in, our app will ask them to first sign up for a new account. Once they've been authenticated by Magic, they'll be redirected to the Payment page where they can seal the deal to a lifetime access of awesomeness!

Log out with Magic

To allow users to log out, we'll add a logout function in our Header component. logout() ends the user's session with Magic, clears the user's information from the UserContext, resets both the user's lifetime access as well as the lifetime access request status, and redirects the user back to the login page.

/* File: client/src/components/header.js */

const logout = () => {
  magic.user.logout().then(() => {
    setUser({ user: null }); // Clear user's info
    setLifetimeAccess(false); // Reset user's lifetime access state
    setLifetimeAccessRequestStatus(""); // Reset status of lifetime access request
    history.push('/login');
  });
};

Build the Payment Form

This is where we'll build out the PaymentForm component that's located in client/src/components/payment-form.js.

Set up the State

To create the PaymentForm component, we'll first need to initialize some state to keep track of the payment, show errors, and manage the user interface.

/* File: client/src/components/payment-form.js */

  const [succeeded, setSucceeded] = useState(false);
  const [error, setError] = useState(null);
  const [processing, setProcessing] = useState("");
  const [disabled, setDisabled] = useState(true);
  const [clientSecret, setClientSecret] = useState("");

There are two more states we need. One to keep track of the customer we create:

/* File: client/src/components/payment-form.js */

  const [customerID, setCustomerID] = useState("");

And the other to set the lifetime access state to true if the user's payment was successful:

/* File: client/src/components/payment-form.js */

  const [, setLifetimeAccess] = useContext(LifetimeContext);

Store a Reference to Stripe

Since we're using Stripe to process the Customer's payment, we'll need to access the Stripe library. We do this by calling Stripe's useStripe() and useElements() hooks.

/* File: client/src/components/payment-form.js */

  const stripe = useStripe();
  const elements = useElements();

Fetch a PaymentIntent

As soon as the PaymentForm loads, we'll be making a request to the /create-payment-intent endpoint in our server.js file. Calling this route will create a Stripe Customer as well as a Stripe PaymentIntent. PaymentIntent will help us keep track of the Customer's payment cycle.

The data that the Client gets back includes the clientSecret returned by PaymentIntent. We'll be using this to complete the payment, so we've saved it using setClientSecret(). The data also includes the ID of the Customer that the PaymentIntent belongs to. We'll need this ID when we update the Customer's information, so we’ll also be saving it with setCustomerID().

/* File: client/src/components/payment-form.js */

  useEffect(() => {
    // Create PaymentIntent as soon as the page loads
    fetch(`${process.env.REACT_APP_SERVER_URL}/create-payment-intent`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ email }),
    })
      .then((res) => {
        return res.json();
      })
      .then((data) => {
        setClientSecret(data.clientSecret);
        setCustomerID(data.customer);
      });
  }, [email]);

Update the Stripe Customer

If the Stripe payment transaction was successful, we'll send the Customer's ID to our server's /update-customer endpoint to update the Stripe Customer's information so that it includes a metadata which will help us determine whether or not the user has lifetime access.

Once this request has completed, we can finally redirect the Customer to the Premium Content page and let them bask in the awesomeness of our content.

/* File: client/src/components/payment-form.js */

  const handleSubmit = async (ev) => {
    ev.preventDefault();
    setProcessing(true);
    const payload = await stripe.confirmCardPayment(clientSecret, {
      payment_method: {
        card: elements.getElement(CardElement),
      },
    });

    if (payload.error) {
      setError(`Payment failed ${payload.error.message}`);
      setProcessing(false);
    } else {
      setError(null);
      setProcessing(false);
      setSucceeded(true);
      setLifetimeAccess(true);
      // Update Stripe customer info to include metadata
      // which will help us determine whether or not they
      // are a Lifetime Access member.
      fetch(`${process.env.REACT_APP_SERVER_URL}/update-customer`, {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify({ customerID }),
      })
        .then((res) => {
          return res.json();
        })
        .then((data) => {
          console.log("Updated Stripe customer object: ", data);
          history.push("/premium-content");
        });
    }
  };

Add a CardElement

One last task to complete the PaymentForm component is to add the CardElement component provided by Stripe. The CardElement embeds an iframe with the necessary input fields to collect the card data. This creates a single input that collects the card number, expiry date, CVC, and postal code.

/* File: client/src/components/payment-form.js */

        <CardElement
          id="card-element"
          options={cardStyle}
          onChange={handleChange}
        />

Build the Payment Page

Now that our PaymentForm component is ready, it's time to build the Payment component which will house it! This component is located in client/src/components/payment.js.

The two most important points to note about the Payment component are:

We'll be using the user state that we set in UserContext to check whether or not the user is logged in.
The component will take in Elements, PaymentForm, and promise as props to help us properly render the Stripe payment form.

/* File: client/src/components/payment.js */

import { useContext, useEffect } from "react";
import { useHistory } from "react-router";
import { UserContext } from "../lib/UserContext";
import Loading from "./loading";

export default function Payment({ Elements, PaymentForm, promise }) {
  const [user] = useContext(UserContext);
  const history = useHistory();

  // If not loading and no user found, redirect to /login
  useEffect(() => {
    user && !user.loading && !user.issuer && history.push("/login");
  }, [user, history]);

  return (
    <>
      <h3 className="h3-header">
        Purchase Lifetime Access Pass to Awesomeness 🤩
      </h3>
      <p>
        Hi again {user?.loading ? <Loading /> : user?.email}! You successfully
        signed up with your email. Please enter your card information below to
        purchase your Lifetime Access Pass securely via Stripe:
      </p>
      {user?.loading ? (
        <Loading />
      ) : (
        <Elements stripe={promise}>
          <PaymentForm email={user.email} />
        </Elements>
      )}
      <style>{`
        p {
          margin-bottom: 15px;
        }
        .h3-header {
          font-size: 22px;
          margin: 25px 0;
        }
      `}</style>
    </>
  );
}

Add the Payment Route to App.js

Alright, with the PaymentForm and Payment components complete, we can finally route the user to the /payment page by updating client/src/App.js!

First, we import Stripe.js and the Stripe Elements UI library into our App.js file:

/* File: client/src/App.js */

import { loadStripe } from  "@stripe/stripe-js";
import { Elements } from  "@stripe/react-stripe-js";

Then we'll load Stripe.js outside of the App.js's render to avoid recreating the Stripe object on every render:

/* File: client/src/App.js */

const  promise = loadStripe(process.env.REACT_APP_STRIPE_PK_KEY);

Note: As we saw in Build the Payment Page, promise is a prop that is passed into the Payment component and is used by the Elements provider to give it's child element, PaymentForm, access to the Stripe service.

Next, let's add a new route called /payment which returns the Payment component we created earlier with the props required to properly render the Stripe payment form.

/* File: client/src/App.js */

function  App() {

...
                <Route
                  path="/payment"
                  render={(props) => {
                    return (
                      <Payment
                        Elements={Elements}
                        PaymentForm={PaymentForm}
                        promise={promise}
                      />
                    );
                  }}
                />
 ...               
}
export  default  App;

What's next

Now that you know how the sign up, payment, login, and logout pages were built and how they work, it's time to learn how the Node server powers the paid membership site. Click here to continue.

Build a Paid Membership Site with Magic and Stripe: Pt. 1 - Quickstart

Maricris Bonzo — Wed, 10 Mar 2021 01:01:14 +0000

Resources

🍰 Test the live demo here!

Test card number: 4242 4242 4242 4242!
Choose a valid and random MM/YY (e.g. 09/23), as well as a random CVC (e.g. 123).

🧁 The full code base can be found here.

A Paid Membership Site

If you’re looking for a way to finally charge people for your hard-earned digital work, look no further! In this tutorial, you’ll learn how to create a paid membership app where users can pay for a lifetime access pass to your Premium Content 💸.

We'll be using Stripe as our payment processor, Magic as our auth solution, React as our front end framework, Express as our server framework for Node.js, and Heroku to deploy our app!

Prerequisites

If you’re unfamiliar with building a membership app with React, Express, and Magic, take a look at Build Magic auth into your React + Express app. We'll be reusing a lot of the code from this guide 😏.
Also, feel free to check out Stripe’s guide on the Custom payment flow. We followed the steps listed in this guide to help implement our Stripe payment page 🎊.

File Structure

The root directory will contain the server-side files. The client folder will have all of the frontend files.

├── README.md
├── client
│ ├── .env
│ ├── package.json
│ ├── public
│ │ └── (static files, such as images)
│ ├── src
│ │ ├── App.js
│ │ ├── components
│ │ │ ├── header.js
│ │ │ ├── home.js
│ │ │ ├── layout.js
│ │ │ ├── loading.js
│ │ │ ├── login-form.js
│ │ │ ├── login.js
│ │ │ ├── payment-form.js
│ │ │ ├── payment.js
│ │ │ ├── premium-content.js
│ │ │ ├── profile.js
│ │ │ ├── signup-form.js
│ │ │ ├── signup.js
│ │ ├── index.js
│ │ └── lib
│ │ │ ├── LifetimeAccessRequestStatusContext.js
│ │ │ ├── LifetimeContext.js
│ │ │ ├── UserContext.js
│ │ │ └── magic.js
│ └── yarn.lock
├── .env
├── package.json
├── server.js
└── yarn.lock

Quick Start Instructions

Magic Setup

Create a Magic account and then grab your REACT_APP_MAGIC_PUBLISHABLE_KEY and MAGIC_SECRET_KEY from your Magic Dashboard.

Stripe Setup

Create a Stripe account and then grab your REACT_APP_STRIPE_PK_KEY and STRIPE_SECRET_KEY from your Stripe Dashboard.

Start your Express Server

git clone https://github.com/magiclabs/magic-stripe.git
cd magic-stripe
mv .env.example .env
Replace MAGIC_SECRET_KEY and STRIPE_SECRET_KEY with the appropriate values you just copied. Your .env file should look something like this:

   MAGIC_SECRET_KEY=sk_test_XXX
   CLIENT_URL=http://localhost:3000
   STRIPE_SECRET_KEY=sk_test_XXX

yarn
node server.js

Note: Running yarn helped us pull the dependencies we need for our server, including the Stripe Node library.

Start your React Client

(in a new terminal session)

cd client
mv .env.example .env
Replace REACT_APP_MAGIC_PUBLISHABLE_KEY and REACT_APP_STRIPE_PK_KEY with the appropriate values you just copied. Your .env file should look something like this:

   REACT_APP_MAGIC_PUBLISHABLE_KEY=pk_test_XXX
   REACT_APP_SERVER_URL=http://localhost:8080
   REACT_APP_STRIPE_PK_KEY=pk_test_XXX

yarn
yarn start

Note: Running yarn helped us pull the dependencies we need for our client, including Stripe.js and the Stripe Elements UI library (both needed to stay PCI compliant; they ensure that card details go directly to Stripe and never reach your server.)

Magic React Storybook

This tutorial was built using Magic React Storybook 🤩. If you wish to swap the Magic UI components out for your own custom CSS, delete @magiclabs/ui and framer-motionfrom your client/package.json dependencies.

What's Next

Now that you've set everything up, let's get started with building the React client side! Click here to continue.

Securing a Go-Backed Scrappy Twitter API with Magic

Maricris Bonzo — Wed, 20 Jan 2021 23:35:34 +0000

Hi there 🙋🏻‍♀️. The Scrappy Twitter API is a Go-backend project that is secured by the Magic Admin SDK for Go. This SDK makes it super easy to leverage Decentralized ID (DID) Tokens to authenticate your users for your app.

Demo
A High-Level View
Getting Started
- Prerequisites
- Magic
- Server
- Client
- Postman
The Scrappy Twitter Go Rest API
- File Structure
- A Local Database
- The Routes and Handlers
Securing the Go Rest API with Magic Admin SDK
- Magic Setup
- Magic Admin SDK for Go
  - checkBearerToken()
  - handleRequests()
  - createATweet()
  - deleteATweet()

Demo

To test out our Live demo, click the button below to import the Magic-secured Scrappy Twitter API Postman collection.

Alternatively, you could also manually import this static snapshot of the collection:

https://www.getpostman.com/collections/595abf685418eeb96401

This Postman collection has the following routes:

POST a tweet (protected): https://scrappy-secure-go-twitter-api.wl.r.appspot.com/tweet
GET all tweets (unprotected): https://scrappy-secure-go-twitter-api.wl.r.appspot.com/tweets
GET a single tweet (unprotected): https://scrappy-secure-go-twitter-api.wl.r.appspot.com/tweet/1
DELETE a tweet (protected): https://scrappy-secure-go-twitter-api.wl.r.appspot.com/tweet/2

You’ll only be able to make requests with the Get All Tweets and Get a Single Tweet endpoints because they’re unprotected. To post or delete a tweet, you’ll need to pass in a DID token to the request Header.

💁🏻‍♀️ Create an account here to get a DID token.

Great! Now that you’ve got a DID token, you can pass it into the Postman Collection’s HTTP Authorization request header as a Bearer Token and be able to send a Create a Tweet or Delete a Tweet request.

Keep reading if you want to learn how we secured this Go-backed Scrappy Twitter API with the Magic Admin SDK for Go. 🪄🔐

A High-level View

Here are the building blocks of this project and how each part connects to one another.

Client

This Next.js app authenticates the user and generates the DID token required to make POST or DELETE requests with the Scrappy Twitter API.

✨ Noteworthy Package Dependencies:
- Magic SDK: Allows users to sign up or log in.
- SWR: Lets us get user info using a hook.
- @hapi/iron: Lets us encrypt the login cookie for more security.
Server

This Go server is where all of the Scrappy Twitter API requests are handled. Once the user has generated a DID token from the client side, they can pass it into their Request Header as a Bearer token to hit protected endpoints.

✨ API routes:
- POST a tweet (protected): http://localhost:8080/tweet
- GET all tweets (unprotected): http://localhost:8080/tweets
- GET a single tweet (unprotected): http://localhost:8080/tweet/1
- DELETE a tweet (protected): http://localhost:8080/tweet/2
✨ Noteworthy Packages:
- gorilla/handlers: Lets us enable CORS.
- gorilla/mux: Lets us build a powerful HTTP router and URL matcher.
- magic-admin-go/client: Lets us instantiate the Magic Admin SDK for Go.
- magic-admin-go/token: Lets us create a Token instance.

In this article, we’ll only be focusing on the Server’s code to show you how we secured the Go Rest API.

Getting Started

Prerequisites ✅

Go
Postman

Magic 🦄

Sign up for an account on Magic.
Create an app.
Keep this Magic tab open. You’ll need both of your app’s Test Publishable and Secret keys soon.

Note: Test API keys are always allowed to be used on localhost. For added security, you can specify the URLs that are allowed to use your live API keys in Magic's Dashboard Settings. Doing so will block your Live API keys from working anywhere except the URLs in your whitelisted domains.

Server 💾

git clone https://github.com/magiclabs/scrappy-twitter-api-server
cd scrappy-twitter-api-server
mv .env.example .env
Go back to the Magic tab to copy your app’s Test Secret Key and paste it as the value for MAGIC_TEST_SECRET_KEY in .env:
```
MAGIC_TEST_SECRET_KEY=sk_test_XXXXXXXXXX
```
Run all .go files with go run .

Client 🖥

git clone https://github.com/magiclabs/scrappy-twitter-api-client
cd scrappy-twitter-api-client
mv .env.local.example .env.local
Populate .env.local with the correct Test keys from your Magic app:
```
NEXT_PUBLIC_MAGIC_TEST_PUBLISHABLE_KEY=pk_test_XXXXX
NEXT_PUBLIC_MAGIC_TEST_SECRET_KEY=sk_test_XXXXX
NEXT_PUBLIC_HAPI_IRON_SECRET=this-is-a-secret-value-with-at-least-32-characters
```
Note: The NEXT_PUBLIC_HAPI_IRON_SECRET is needed by @hapi/iron to encrypt an object. Feel free to leave the default value as is while in DEV.
Install package dependencies: yarn
Start the Next.js production server: yarn dev

Postman 📫

Import the DEV version of the Scrappy Twitter API Postman Collection:
Generate a DID token on the Client you just started up.

Note: When you log in from the Client side, the Magic Client SDK generates a DID token which is then converted to an ID token so that it has a longer lifespan (8 hours).
Pass this DID token as a Bearer token into the collection’s HTTP Authorization request header.

Awesome! Now that you have your own local Next.js client and Go server running, let's dive into the server's code.

The Scrappy Twitter Go Rest API

File Structure

This is a simplified view of the Go server's file structure:

├── README.md
├── .env
├── main.go
├── structs.go
├── handlers.go

A Local Database

To keep things simple, when you create or delete a tweet, instead of updating an external database, the Tweets array that’s globally defined and initialized in structs.go is updated accordingly.

// Tweet is struct or data type with an Id, Copy and Author
type Tweet struct {
   ID     string `json:"ID"`
   Copy   string `json:"Copy"`
   Author string `json:"Author"`
}

// Tweets is an array of Tweet structs
var Tweets []Tweet

And when you get all tweets, or a single tweet, the same Tweets array is sent back to the client.

The Routes and Handlers

In summary, this Scrappy Twitter Go Rest API has 4 key routes that are defined in main.go’s handleRequests function:

GET "/tweets" to get all tweets

myRouter.HandleFunc("/tweets", returnAllTweets)

DELETE "/tweet/{id}" to delete a tweet

myRouter.HandleFunc("/tweet/{id}", deleteATweet).Methods("DELETE")

GET "/tweet/{i}" to get a single tweet

myRouter.HandleFunc("/tweet/{id}", returnSingleTweet)

POST "/tweet" to create a tweet

myRouter.HandleFunc("/tweet", createATweet).Methods("POST")

Note: The POST and DELETE routes are currently unprotected. Move to the next section to see how we can use a DID token to protect them.

As you can see, each of these routes have their own handlers to properly respond to requests. These handlers are defined in handlers.go:

GET "/tweets" => returnAllTweets()

// Returns ALL tweets ✨
func returnAllTweets(w http.ResponseWriter, r *http.Request) {
   fmt.Println("Endpoint Hit: returnAllTweets")
   json.NewEncoder(w).Encode(Tweets)
}

DELETE "/tweet/{id}" => deleteATweet()

// Deletes a tweet ✨
func deleteATweet(w http.ResponseWriter, r *http.Request) {
   fmt.Println("Endpoint Hit: deleteATweet")

   // Parse the path parameters
   vars := mux.Vars(r)

   // Extract the `id` of the tweet we wish to delete
   id := vars["id"]

   // Loop through all our tweets
   for index, tweet := range Tweets {

       /*
           Checks whether or not our id path
           parameter matches one of our tweets.
       */
       if tweet.ID == id {

           // Updates our Tweets array to remove the tweet
           Tweets = append(Tweets[:index], Tweets[index+1:]...)
       }
   }

   w.Write([]byte("Yay! Tweet has been DELETED."))
}

GET "/tweet/{i}" => returnSingleTweet()

// Returns a SINGLE tweet ✨
func returnSingleTweet(w http.ResponseWriter, r *http.Request) {
   fmt.Println("Endpoint Hit: returnSingleTweet")
   vars := mux.Vars(r)
   key := vars["id"]

   /*
       Loop over all of our Tweets
       If the tweet.Id equals the key we pass in
       Return the tweet encoded as JSON
   */
   for _, tweet := range Tweets {
       if tweet.ID == key {
           json.NewEncoder(w).Encode(tweet)
       }
   }
}

POST "/tweet" => createATweet()

// Creates a tweet ✨
func createATweet(w http.ResponseWriter, r *http.Request) {
   fmt.Println("Endpoint Hit: createATweet")
   /*
       Get the body of our POST request
       Unmarshal this into a new Tweet struct
   */
   reqBody, _ := ioutil.ReadAll(r.Body)
   var tweet Tweet
   json.Unmarshal(reqBody, &tweet)

   /*
       Update our global Tweets array to include
       Our new Tweet
   */
   Tweets = append(Tweets, tweet)
   json.NewEncoder(w).Encode(tweet)

   w.Write([]byte("Yay! Tweet CREATED."))
}

Securing the Go Rest API with Magic Admin SDK

Now it’s time to show you how to protect the DELETE "/tweet/{id}" and POST "/tweet" routes, such that only authenticated users are able to create a tweet and only the author of a specific tweet is allowed to delete it.

Magic Setup

Get the Go Magic Admin SDK package:
go get github.com/magiclabs/magic-admin-go

Configure the Magic Admin SDK in handlers.go:

Import the following packages:

   "github.com/joho/godotenv"
   "github.com/magiclabs/magic-admin-go"
   "github.com/magiclabs/magic-admin-go/client"
   "github.com/magiclabs/magic-admin-go/token"

Load the .env file and get the Test Secret Key:

// Load .env file from given path
var err = godotenv.Load(".env")

// Get env variables
var magicSecretKey = os.Getenv("MAGIC_TEST_SECRET_KEY")

Instantiate Magic:

var magicSDK = client.New(magicSecretKey, magic.NewDefaultClient())

Magic Admin SDK for Go

In order to protect the routes to POST or DELETE a tweet, we’ll be creating a Gorilla Mux middleware to check whether or not the user is authorized to make requests to these endpoints.

💡 You can think of a middleware as reusable code for HTTP request handling.

checkBearerToken()

Let’s call this middleware checkBearerToken() and define it in handlers.go.

To implement the middleware behavior, we’ll be using chainable closures. This way, we could wrap each handler with a checkBearerToken middleware.

Here’s the initial look of our function:

func checkBearerToken(next httpHandlerFunc) httpHandlerFunc {
   return func(res http.ResponseWriter, req *http.Request) {
      /* More code is coming! */
      next(res, req)
   }
}

💁🏻‍♀️ Now let’s update checkBearerToken to make sure the DID token exists in the HTTP Header Request. If it does, store the value into a variable called didToken:

func checkBearerToken(next httpHandlerFunc) httpHandlerFunc {
   fmt.Println("Middleware Hit: checkBearerToken")
   return func(res http.ResponseWriter, req *http.Request) {

       // Check whether or not DIDT exists in HTTP Header Request
       if !strings.HasPrefix(req.Header.Get("Authorization"), authBearer) {
           fmt.Fprintf(res, "Bearer token is required")
           return
       }

       // Retrieve DIDT token from HTTP Header Request
       didToken := req.Header.Get("Authorization")[len(authBearer)+1:]

      /* More code is coming! */
      next(res, req)
   }
}

Cool. Now that we’ve got a DID token, we can use it to create an instance of a Token. The Token resource provides methods to interact with the DID Token. We’ll need to interact with the DID Token to get the authenticated user’s information. But first, we’ll need to validate it.

💁🏻‍♀️ Update checkBearerToken to include this code:

func checkBearerToken(next httpHandlerFunc) httpHandlerFunc {
   fmt.Println("Middleware Hit: checkBearerToken")
   return func(res http.ResponseWriter, req *http.Request) {

       // Check whether or not DIDT exists in HTTP Header Request
       if !strings.HasPrefix(req.Header.Get("Authorization"), authBearer) {
           fmt.Fprintf(res, "Bearer token is required")
           return
       }

       // Retrieve DIDT token from HTTP Header Request
       didToken := req.Header.Get("Authorization")[len(authBearer)+1:]

       // Create a Token instance to interact with the DID token
       tk, err := token.NewToken(didToken)
       if err != nil {
           fmt.Fprintf(res, "Malformed DID token error: %s", err.Error())
           res.Write([]byte(err.Error()))
           return
       }

       // Validate the Token instance before using it
       if err := tk.Validate(); err != nil {
           fmt.Fprintf(res, "DID token failed validation: %s", err.Error())
           return
       }

      /* More code is coming! */
      next(res, req)
   }
}

Now that we’ve validated the Token (tk), we can call tk.GetIssuer() to retrieve the iss; a Decentralized ID of the Magic user who generated the DID Token. We’ll be passing iss into magicSDK.User.GetMetadataByIssuer to get the authenticated user’s information.

💁🏻‍♀️ Update checkBearerToken again:

func checkBearerToken(next httpHandlerFunc) httpHandlerFunc {
   fmt.Println("Middleware Hit: checkBearerToken")
   return func(res http.ResponseWriter, req *http.Request) {

       // Check whether or not DIDT exists in HTTP Header Request
       if !strings.HasPrefix(req.Header.Get("Authorization"), authBearer) {
           fmt.Fprintf(res, "Bearer token is required")
           return
       }

       // Retrieve DIDT token from HTTP Header Request
       didToken := req.Header.Get("Authorization")[len(authBearer)+1:]

       // Create a Token instance to interact with the DID token
       tk, err := token.NewToken(didToken)
       if err != nil {
           fmt.Fprintf(res, "Malformed DID token error: %s", err.Error())
           res.Write([]byte(err.Error()))
           return
       }

       // Validate the Token instance before using it
       if err := tk.Validate(); err != nil {
           fmt.Fprintf(res, "DID token failed validation: %s", err.Error())
           return
       }

       // Get the user's information
       userInfo, err := magicSDK.User.GetMetadataByIssuer(tk.GetIssuer())
       if err != nil {
           fmt.Fprintf(res, "Error when calling GetMetadataByIssuer: %s", err.Error())
           return
       }

      /* More code is coming! */
      next(res, req)
   }
}

Awesome. If the request was able to make it past this point, then we can be assured that it was an authenticated request. All we need to do now is pass the user’s information to the handler the middleware is chained to. We’ll be using Go's Package context to achieve this.

💡 In short, the Package context will make it easy for us to store objects as context values and pass them to all handlers that are chained to our checkBearerToken middleware.

Make sure to import the "context" in handlers.go.

Then create a userInfoKey at the top of handlers.go (we'll be passing userInfoKey into context.WithValue soon):

type key string
const userInfoKey key = "userInfo"

💁🏻‍♀️ Update checkBearerToken one last time to use context values to store the user’s information:

func checkBearerToken(next httpHandlerFunc) httpHandlerFunc {
   fmt.Println("Middleware Hit: checkBearerToken")
   return func(res http.ResponseWriter, req *http.Request) {

       // Check whether or not DIDT exists in HTTP Header Request
       if !strings.HasPrefix(req.Header.Get("Authorization"), authBearer) {
           fmt.Fprintf(res, "Bearer token is required")
           return
       }

       // Retrieve DIDT token from HTTP Header Request
       didToken := req.Header.Get("Authorization")[len(authBearer)+1:]

       // Create a Token instance to interact with the DID token
       tk, err := token.NewToken(didToken)
       if err != nil {
           fmt.Fprintf(res, "Malformed DID token error: %s", err.Error())
           res.Write([]byte(err.Error()))
           return
       }

       // Validate the Token instance before using it
       if err := tk.Validate(); err != nil {
           fmt.Fprintf(res, "DID token failed validation: %s", err.Error())
           return
       }

       // Get the the user's information
       userInfo, err := magicSDK.User.GetMetadataByIssuer(tk.GetIssuer())
       if err != nil {
           fmt.Fprintf(res, "Error when calling GetMetadataByIssuer: %s", err.Error())
           return
       }

       // Use context values to store user's info
       ctx := context.WithValue(req.Context(), userInfoKey, userInfo)
       req = req.WithContext(ctx)
       next(res, req)
   }
}

Looks good! Writing checkBearerToken() is the bulk of the work needed to Magic-ally protect the routes for posting or deleting a tweet.

All that’s left to do now is:

Wrap createATweet and deleteATweet handlers in main.go’s handleRequests function with this checkBearerToken middleware.
Update these handlers to get the user’s information from the context values, and then tag each tweet with the user’s email so that authors are able to delete their own tweet.

handleRequests()

All we did in main.go’s handleRequest() is wrap the deleteATweet and createATweet handlers with the checkBearerToken middleware function.

func handleRequests() {

   /* REST OF THE CODE IS OMITTED */

   // Delete a tweet ✨
   myRouter.HandleFunc("/tweet/{id}", checkBearerToken(deleteATweet)).Methods("DELETE")

   // Create a tweet ✨
   myRouter.HandleFunc("/tweet", checkBearerToken(createATweet)).Methods("POST")


   /* REST OF THE CODE IS OMITTED */
}

createATweet()

To access the key-value pairs in userInfo object, we first needed to get the object by calling r.Context().Value(userInfoKey) with the userInfoKey we defined earlier, and then we needed to assert two things:

userInfo is not nil
the value stored in userInfo is of type *magic.UserInfo

Both of these assertions are done with userInfo.(*magic.UserInfo).

// Creates a tweet ✨
func createATweet(w http.ResponseWriter, r *http.Request) {

   fmt.Println("Endpoint Hit: createATweet")

   // Get the authenticated author's info from context values
   userInfo := r.Context().Value(userInfoKey)
   userInfoMap := userInfo.(*magic.UserInfo)

   /*
       Get the body of our POST request
       Unmarshal this into a new Tweet struct
       Add the authenticated author to the tweet
   */
   reqBody, _ := ioutil.ReadAll(r.Body)
   var tweet Tweet
   json.Unmarshal(reqBody, &tweet)
   tweet.Author = userInfoMap.Email

   /*
       Update our global Tweets array to include
       Our new Tweet
   */
   Tweets = append(Tweets, tweet)
   json.NewEncoder(w).Encode(tweet)

   fmt.Println("Yay! Tweet CREATED.")
}

As you can see, we’ve also added the authenticated author to the tweet.

deleteATweet()

Now that we know which author created the tweet, we’ll be able to only allow that author to delete it.

// Deletes a tweet ✨
func deleteATweet(w http.ResponseWriter, r *http.Request) {
   fmt.Println("Endpoint Hit: deleteATweet")

   // Get the authenticated author's info from context values
   userInfo := r.Context().Value(userInfoKey)
   userInfoMap := userInfo.(*magic.UserInfo)

   // Parse the path parameters
   vars := mux.Vars(r)
   // Extract the `id` of the tweet we wish to delete
   id := vars["id"]

   // Loop through all our tweets
   for index, tweet := range Tweets {

       /*
           Checks whether or not our id and author path
           parameter matches one of our tweets.
       */
       if (tweet.ID == id) && (tweet.Author == userInfoMap.Email) {

           // Updates our Tweets array to remove the tweet
           Tweets = append(Tweets[:index], Tweets[index+1:]...)
           w.Write([]byte("Yay! Tweet has been DELETED."))
           return
       }
   }

   w.Write([]byte("Ooh. You can't delete someone else's tweet."))
}

Yay! Now you know how to protect Go RESTful API routes 🎉. Feel free to create and delete your own tweet, and also try to delete our default tweet in the Postman Collection to test our protected endpoints.

I hope you enjoyed how quick and easy it was to secure the Go-backed Scrappy Twitter API with the Magic Admin SDK for Go. Next time you want to build a Go REST API for authenticated users, this guide will always have your back.

Btw, if you run into any issues, feel free to reach out @seemcat.

Till next time 🙋🏻‍♀️.

How to Build a Blog Membership Site with Magic Auth and Webflow

Maricris Bonzo — Wed, 30 Dec 2020 18:07:58 +0000

Hi there 🙋🏻‍♀️. In this tutorial we’ll be building a Blog Membership site using Webflow and Magic auth. Webflow will help us design, build and launch responsive websites visually, while Magic will waive its wand to help us create a secure and reliable passwordless login.

💁🏻‍♀️ Note: This tutorial uses Webflow's Custom Code, which is available on paid Webflow accounts.

Here’s a Live Demo of the end result!

Magic Setup

Sign up for a Magic account here.
Create a new app and keep this page open (you're going to need the Test Publishable Key in a bit).

Btw, this tutorial uses the email link sign-in method, but you have plenty of other social login options to choose from (Google, GitHub, Facebook, Apple and LinkedIn)! You could also customize the Login form to your liking 😎.

Webflow Setup

Sign up for a Webflow account here.
Create a new project.
Select a Blank Site.
Create your first CMS Collection (this is where you'll be storing your blogs).
- Choose the ‘Blog Posts’ template.
- Click ‘Create Collection’ and add 5 sample items.

Create Webflow NavBar Links

Webflow provides you with a Home page by default, so design your navigation bar in there!

Drag and drop a Navbar component, change the background color to white and make sure each of the following links exist:

Home - with an ID of homeLink.
Login - ID: loginLink.
Profile - ID: profileLink.
Log out - ID: logOutLink.

Feel free to add your logo as well.

One more thing; you'll be needing this NavBar in all of your pages, so turn it into a Symbol. This turns the NavBar into a reusable component.

Design & Link Webflow Pages

It's time to design a few pages and link them to your NavBar. Here’s a list of pages you’ll need, each with a step-by-step guide on how to design them.

1. Home

Drag & drop:

A Section, underneath the NavBar, with a margin top and bottom of 50.
A Container on top of the Section.
A Heading on top of the Container, titled “🪄 Blog Membership Site ✨”.
A Collection List on top of the Container, underneath the title.
- This Collection List is how you'll be displaying your blog on the homepage. All you need to do is double-click it to connect to the Blog Posts collection you made earlier, and then design it so that it looks like a list of blog posts.
A Heading to one of the Collection items. Make sure to get the Heading’s text from a field in Blog Posts called Name.
A Rich Text field right under the Heading you just added. Make sure you get the text from a field in Blog Posts called Post Body.

By now, you should be able to see all of the blog posts from your CMS Collection!

Lastly, edit the Nav Link Settings for Home such that it has Type: Page, and Page: Home.

2. Login

Drag & drop:

The NavBar Symbol.
A Section, underneath the NavBar, with a margin top and bottom of 50.
A Container on top of the Section.
A Heading on top of the Container, titled “Login 🎉”.
A Form Block on top of the Container, underneath the title.
- Get rid of the label and text field for the name, you won’t need them.
- Rename the button to ‘Login’ and give it an ID of loginBtn (Note: The email text field already has an ID of email).

Again, edit the Nav Link Settings for Login such that it has Type: Page, and Page: Login.

3. Profile

Drag & drop:

The NavBar Symbol with a margin top of 50.
A Section, underneath the NavBar, with a margin top and bottom of 50.
A Container on top of the Section.
- Make sure the Layout > Display of this Container is set to Flex.
Two Headings in the Container.
- Flex will make it so that they’re positioned right next to each other.
- The first Heading should read, “Welcome ” while the second Heading reads a temporary text like “user_email”.
- Add some space between these Headings. Give the second Heading a margin-left of 15.
- Once the user is logged in, you’ll need to replace “user_email” with the email address they used to log in. To do this, give the second Heading an ID of emailAddress.

Edit the Nav Link Settings for Profile such that it has Type: Page, and Page: Profile.

4. Logout

When the user logs out, they'll need to be routed to the Login page. To do this, edit the Nav Link Settings for Logout such that it has Type: Page, and Page: Login.

Yay you for designing and linking your pages 🥳! Next you’ll learn how to use the Magic SDK to authenticate a user to log in or log out, and protect specific pages.

Write Webflow Site-Wide Custom Code

Webflow's site-wide custom code is applied to your entire site. You’ll be using this option to initialize the Magic SDK, protect certain pages, and allow users to log out.

All you need to do is paste the following code into your Webflow site’s Project Settings > Custom Code.

Head Code

Get the Magic SDK.

<!-- 1. Get Magic SDK -->
<script src="https://cdn.jsdelivr.net/npm/magic-sdk/dist/magic.js"></script>

Remember that page you left open earlier? Copy the Test Publishable Key from that page and paste it in 'your_test_publishable_key'. This code initializes the Magic SDK.
```

<script>
const magic = new Magic('your_test_publishable_key');
</script>
```

Footer Code

Ensure the logged in user has access to private pages, while the logged out user does not.

<!-- 4. When the user is logged in/logged out. -->
<script>
  let privatePages = [
    '/profile',
    '/' // This is where your private blogs live!
  ];

  let publicPages = [
    '/login'
  ]

  // Get the user & check whether or
  // not the user is logged in. Show or
  // hide pages depending on the outcome.
  const getUser = async () => {

    // The page user is currently on
    const currentPath = window.location.pathname;

    // Checks if a user is currently logged in
    // to the Magic SDK
    const isLoggedIn = await magic.user.isLoggedIn();

    // If the user is logged in...
    if (isLoggedIn) {

      // prevent them from accessing public pages.
      if (publicPages.includes(currentPath)) {
        window.location.replace('/');
      } else {
        // Or hide links they don't need to see
        loginLink.style.display = 'none';
      }
    } else {

      // If the user is logged out and
      // they try to access a private page,
      // send them back to the login page.
      if (privatePages.includes(currentPath)) {
        window.location.replace('/login');
      } else {

        // Or hide links they shouldn't be able to see
        profileLink.style.display = 'none';
        logOutLink.style.display = 'none';
        homeLink.style.display = 'none';
      }
    }
  };

  getUser();
</script>

Allow logged in users to log out.

<!-- 5. Log out the currently authenticated Magic user. -->
<script>
  const logOut = async () => {
    try {
      await magic.user.logout();
      const isLoggedIn = await magic.user.isLoggedIn();
      console.log('Is the user still logged in? ', isLoggedIn); // => `false`
    } catch (error) {
      // Handle errors if required!
      console.log('Ran into this error while logging out: ', error);
    }
    console.log('WHOO! User has logged out.');
  }

  // Call the logOut function when the user
  // clicks the Log Out Nav Link.
  logOutLink.addEventListener('click', logOut);
</script>

Write Webflow Page-Only Custom Code

The custom code in a particular page settings only works for that page. You’ll be using this option to implement the login and profile functionalities. Just paste the following code blocks into the appropriate Static Page, inside of the page Settings before the </body> tag.

Log In

Allow the user to log in.

<!-- 3. Log in with Magic Link -->
<script>
  // Log in or create a new user.
  const login = async () => {
    const emailVal = email.value;
    await magic.auth.loginWithMagicLink({
        email: emailVal
      })
      .then(() => {
        // Take user to the home page once they're
        // logged in.
        window.location.replace('./');
      })
      .catch((error) => {
        console.log("Error while logging in: ", error);
      })
  }

  // Call the login function when the user
  // clicks the Login button.
  loginBtn.addEventListener('click', login);
</script>

Profile

Ensure the user’s email is displayed.

<!-- 4. Ensure the user's email is displayed -->
<script type="text/javascript">
  const displayUserName = async () => {
    const {
      email,
      publicAddress
    } = await magic.user.getMetadata();

    let elementToDisplay = document.getElementById('emailAddress');
    elementToDisplay.innerHTML = email;
  }

  displayUserName();
</script>

Test your code

Awesome 🤩🪄! You’ve built a Blog Membership Site. To test the code, you’ll need to publish your site and visit the live url.

Adding a Loader

Have you noticed the lag in the UI when navigating between pages? This happens because the Magic SDK takes a few seconds to initialize. To resolve this, you can add a loader!

Drag & drop a Div Block into your Home page, above the NavBar.
1. Set it’s Layout > Display to Flex.
2. Set Align and Justify to Center.
3. Set it’s Width and Height to 100 VW.
4. Change it’s background color to a nice contrast to your logo.
Drag & drop an Image onto the Div Block, then upload your loader. It should automatically be centered.
Give the Div Block an ID of loader.

Update the getUser() function in Project Settings > Custom Code > Footer Code:

const getUser = async () => {

    // The page user is currently on
    const currentPath = window.location.pathname;

    // Checks if a user is currently logged in
    // to the Magic SDK
    const isLoggedIn = await magic.user.isLoggedIn();

    // If the user is logged in...
    if (isLoggedIn) {

      // prevent them from accessing public pages.
      if (publicPages.includes(currentPath)) {
        window.location.replace('/');
      } else {
        // Or hide links they don't need to see
        loginLink.style.display = 'none';
        // Get rid of loader when user gets to correct page
        loader.style.display = 'none';
      }
    } else {

      // If the user is logged out and
      // they try to access a private page,
      // send them back to the login page.
      if (privatePages.includes(currentPath)) {
        window.location.replace('/login');
      } else {

        // Or hide links they shouldn't be able to see
        profileLink.style.display = 'none';
        logOutLink.style.display = 'none';
        homeLink.style.display = 'none';
        // Get rid of loader when user gets to correct page
        loader.style.display = 'none';
      }
    }
  };

Turn the Div Block into a Symbol titled, “Loader”.
Drag & drop your Loader Symbol to the rest of the pages.

Publish your changes, and view your live site to see the Loader in action.

That’s it for today!

As you saw, designing a beautiful Blog Membership site with Webflow is easy; just drag and drop elements! Integrating Magic auth into your site for a secure authentication and authorization system was also just as seamless.

Next time you want to build any kind of Membership site with Webflow and Magic auth, this guide will always have your back. Till next time 🙋🏻‍♀️.

DEV Community: Magic Labs

Build a Paid Membership Site with Magic and Stripe: Pt. 4 - Deploy to Heroku

Deploying to Heroku

Create a Project

Set Config Vars (.env)

Update Server.js

Update Package.json

Outro

Build a Paid Membership Site with Magic and Stripe: Pt. 3 - Node Server

Server

Validate the Auth Token (didToken)

Create a Stripe Payment Intent and Stripe Customer

Update the Stripe Customer's Info

Validate a Paid Customer

Test the integration

What's next

Build a Paid Membership Site with Magic and Stripe: Pt. 2 - React Client

Client

Standard Auth Setup

Keep Track of the Logged In User

Keep Track of the Paid User

Log in with Magic Link Auth

Sign up with Magic Link Auth

Log out with Magic

Build the Payment Form

Set up the State

Store a Reference to Stripe

Fetch a PaymentIntent

Update the Stripe Customer

Add a CardElement

Build the Payment Page

Add the Payment Route to App.js

What's next

Build a Paid Membership Site with Magic and Stripe: Pt. 1 - Quickstart

Resources

A Paid Membership Site

Prerequisites

File Structure

Quick Start Instructions

Magic Setup

Stripe Setup

Start your Express Server

Start your React Client

Magic React Storybook

What's Next

Securing a Go-Backed Scrappy Twitter API with Magic

Table of Contents

Demo

A High-level View

Getting Started

Prerequisites ✅

Magic 🦄

Server 💾

Client 🖥

Postman 📫

The Scrappy Twitter Go Rest API

File Structure

A Local Database

The Routes and Handlers

Securing the Go Rest API with Magic Admin SDK

Magic Setup

Magic Admin SDK for Go

checkBearerToken()

handleRequests()

createATweet()

deleteATweet()

How to Build a Blog Membership Site with Magic Auth and Webflow

Magic Setup

Webflow Setup

Create Webflow NavBar Links

Design & Link Webflow Pages

1. Home

2. Login

3. Profile

4. Logout

Write Webflow Site-Wide Custom Code

Head Code

Footer Code

Write Webflow Page-Only Custom Code

Log In