Securing Gatsby with Auth0

Blog Discussions
, ,
42

Interesting @myhendry, thanks for sharing! I will look into this as I build out my next sample app.

Glad you are having a good experience with Auth0!

44

Hi Sam, based on your securing gatsby with auth0 codes, how can we use returnTo to control the URLs to go to when logging out? I have a localhost:8000 for dev and hendry-gatsby.netify.com as logout URLs on auth0 dashboard. Thanks

45

Found this one: GitHub - NWRichmond/gatsby-auth0-spa-example: Example Gatsby app which uses the auth0-spa-js SDK for protected routes
Still uses wrapRootelement and useAuth0()

On a separate not, is there an easy way if I have two SPAs on the same domain that they share Auth0 credentials / tokens somehow, or will they always do a callback loop when I navigate between them?

46

I agree that Auth0 authentication is fast (much faster than Firebase Web!) but I found Firebase to be simpler to set up, and Meteor account ridiculously easy, and truly a breeze (one line of code).

Anyway, I wanted to ask, is this tutorial still the recommended method to start with when using Gatsby on a new project? Or is the auth0-SPA version / React Quickstart recommended now?

In the latter case, it would help to mention that at the top of this blog post.

1 Like
47

Friendly ping @sam.julien!

48

Hey @Civility (and everyone else on this thread :wave:),

We’re actually writing a new article as we speak about using auth0-spa-js with Gatsby that should be published in the next month. Once that’s published, we’ll add a notice to the top of my article. We haven’t because many folks are still using auth0.js and so the article is still valid in that case.

We’re also doing two collaborative streams with Gatsby that will walk through this process:

On May 2nd, I’m giving a talk at ByteConf React (it’s free!) about Gatsby auth. It doesn’t mention Auth0 specifically but is the same basic process. I’ll be posting the slides and code here.

Hope that helps!

Cheers,
Sam Julien

1 Like
49

Thanks @sam.julien!

And to prevent this from happening again, I’d like to mention that (at least) two Gatsby themes have been built based on this post:

2 Likes
50

Thanks for sharing that @Civility!

51

I might be late to the party but has anyone ever run into webpack issues when running “npm run build”. Developer mode runs fine but as soon as a I try to build it crashes with:
WebpackError: TypeError: auth0_js__WEBPACK_IMPORTED_MODULE_0___default.a.WebAu th is not a constructor
I’ve tried deleting the cache and public folders along with a fresh install and im getting the same error.
I cant tell if this is version issue or not

I followed this blog pretty closely heres a link to my project: GitHub - L-Town-FC/we-roast: Dont talk to me before i've had my coffee

52

Hey there @atmollohan, thanks for joining the community! Some folks have had to update the entry in gatsby-node.js to include the develop-html stage:

if (["build-html", "develop-html"].includes(stage)) { }

Give that a try and see if that fixes it.

53

Thanks for the quick response Sam! When I changed my gatsby-node.js’s onCreateWebpackConfig function to also apply to the ‘develop-html’ stage I still see the same issue:

WebpackError: TypeError: auth0_js__WEBPACK_IMPORTED_MODULE_0___default.a.WebAuth is not a constructo

I can run ‘npm run develop’ and everything works fine. I cant tell if this is an issue with gatsby or with auth0-js or with my implementation of the two.

I put a log in the onCreateWebpackConfig function and its showing up when I run ‘npm run build’ but then it still complains about . Any thoughts? Ive seen a couple github issues and auth0 threads about this issue but havent found a workaround yet.

Im still pretty new to gatsby and dont know a ton about what its doing with webpack and babel. I read somewhere that it could have to do with updates made to gatsby in version 2 and it left auth0-js in a weird place.

Any thoughts?

54

So I think I found the issue any time I referenced isBrowser I used ‘isBrowser’ instead of ‘isBrowser()’ which actually calls the function to check the context. I was losing my mind thinking that I needed to open up the hood on gatsby’s babel configuration. Everything works now!

1 Like
55

@atmollohan that’s awesome, glad to hear it!

56

Is there a way to fix the problem with every page just redirecting to “/account/” when following the original instructions for Gatsby? The actual tutorial is amazing and we got up and running in about 20 minutes. We were surprised at how easy it was, until
we realized that every single page then just redirects to /account/ . We’ve spent the entire day trying to figure out how to fix this with no luck. We looked at the solutions here and none seemed to work. We tried installing the gatsby-theme-autho0, but that just broke our site.

Is there a way to update the code so that the log in still works, but then the logged in user is not redirected to /account/ on every page? Anyone have any code that works? This /account/ issue seems like such an obvious roadblock to using Autho0 with Gatsby, that I would imagine it would be in the interest of the company to provide code to fix this, so that using Autho0 with Gatsby is actually practically feasible. Thanks very much for your help.

1 Like
57

@ddsgadget here’s the solution earlier in the thread:

Hope that helps!

58

Thanks. But, I’m not at all clear as to what needs to be changed. what is added and where? Can you git this so it’s clear what needs to be changed in the current code? It’s not clear to me what we are supposed to change in setSession and what we are supposed to delete. Also, how are we supposed to use state here? Doesn’t that require an additional { useState } somewhere? Any chance you can just publish an updated auth.js so this tutorial works?

1 Like
59

BTW, we changed our code per the above and it doesn’t do anything. Application still just redirects to /account/ on every page after login. Our code is below. This application is so promising, but we are pulling our hair out with this one issue. Would be great if Auth0 just publish updated code that fixes this issue. It’s impossible to use Autho0 with Gatsby without a fix to this. Thanks.

export const silentAuth = callback => {

  if (!isAuthenticated()) return callback()

  auth.checkSession({state: window.location.pathname+window.location.search}, setSession(callback))

}

const setSession = (cb = () => {}) => (err, authResult) => {

  if (err) {

    const redirect = authResult.state || '/';

navigate(redirect)

    //navigate("/")

    cb()

    return

  }
1 Like
60

@ddsgadget did you remove or change navigate("/account") from setSession in the auth util?

I also forgot to include what you change wherever you are logging in when you call the authorize function on auth0.js SDK if you want to specify the redirect route:

auth.authorize({
    appState: {
      redirectUri: `${window.location.pathname}${window.location.search}`,
    },
})

The original tutorial won’t be updated because we’re in the process of publishing a new guide to auth in Gatsby using the auth0-spa-js SDK. See above :point_up: in this thread for more on that.

Cheers,
Sam

61

Did we remove or change "navigate ("/account")?

No. Are we supposed to? If we remove that, the page never gets past the callback stage.

I also forgot to include what you change wherever you are logging in

Honestly, I do not understand this comment at all. Where does the auth.authorize code go? Do we just put this in current function?

auth0-spa-js SDK

Will the auth0-spa-js guide fix this /account/ issue or does the problem still persist that once you log in will you also be stuck on /account/ page? If users can navigate the website after logging in with the autho0-spa-js, we’ll wait for that new code, because the current code just doesn’t work.

BTW, it would be helpful to put a notification on the top of the current guide page saying it is just a proof of concept, and you can’t actually use it in a real application.

62

@ddsgadget

No. Are we supposed to? If we remove that, the page never gets past the callback stage.

This is what’s causing it to navigate to the account page each time. You can change it to navigate('/') or remove it in conjunction with the other code changes I’ve posted. What’s happening is that Auth0 is sending the user back to the application, processing the token, and then sending them to the protected /account route. You can change that to be whatever you’d like it to be.

Honestly, I do not understand this comment at all. Where does the auth.authorize code go? Do we just put this in current function?

Replace your current call to authorize with what I’ve posted if you’re interested in redirecting the user back to where they came from. This page of the docs explains the state param and how to use it to redirect users to where they logged in from. You can also see here for an example with vanilla React of that use case.

Will the auth0-spa-js guide fix this /account/ issue or does the problem still persist that once you log in will you also be stuck on /account/ page? If users can navigate the website after logging in with the autho0-spa-js, we’ll wait for that new code, because the current code just doesn’t work.

The reason users are being sent to the account page is because of the call to navigate('/account'); it doesn’t matter which SDK is used in that case. You can change that to whatever you’d like and then use the login and redirect properties of the SDK to send the user back to what you want. The only difference is that in the new SPA SDK tutorial we’ll be using regular Gatsby pages instead of the protected route we use here with Reach router.

BTW, it would be helpful to put a notification on the top of the current guide page saying it is just a proof of concept, and you can’t actually use it in a real application.

It does work in many real applications, including the Gatsby store. We just need to get to the bottom of what’s happening in your app. :smiley:

If you’d like to post your code, we can take a look and see what’s happening.

Cheers,
Sam