Just a quick follow up on this, my co-worker Bruno made a quick example for you to look at (but don’t use a static value like this):
https://github.com/auth0-blog/react-tutorial/pull/7/files
Just make sure you use the state param properly, and not with some static value (like in the example). Our docs have more info about the state param and their purpose (like preventing CSRF): Prevent Attacks and Redirect Users with OAuth 2.0 State Parameters
Thank you Sam! I’ll take a look at this and let you know if I have any questions. I appreciate the response.
No worries! We’re here for you!
Hi @sam.julien!
Any luck yet with that branch how to put SPA on Gatsby?
Do I need any of the silentAuth SessionWrapping root wrapper stuff if I use the SPA SDK?
Will the SPA SDK now be the preferred solution for React/Gatsby projects?
Thanks!
Hey @aldegoeij,
Thank you for the reminder/poking – this is one of my top priorities right now.
I think you will still need to do wrapRootElement, but I want to try to integrate the new hooks wrapper the SDK team wrote: Auth0 React SDK Quickstarts: Login
This leads me to believe we’d wrap the root element in the Auth0Context provider, which should handle the silent authentication stuff. But I need to dig into it and make sure for myself.
I’d say the SPA SDK is the preferred/default solution for things like React/Gastby, but keep in mind that auth0.js isn’t going anywhere and supports some other use cases. The SPA SDK is slimmed down quite a bit to make it lightweight and focused on SPAs, but it’s not like you need to panic and refactor everything.
At any rate, this is a high priority for me, so please don’t be afraid to keep poking me! I’ll check in again with my next status update.
Thanks for your patience!
Cheers,
Sam
Please see the issue here Auth0 login on ipad not working for a Gatsby website, stays on callback URL a couple of us are having issues following this when using a custom auth0 domain and logging in from iPad. Not getting an access token. Desktop etc is fine.
Thanks! It works now by adding
auth.checkSession({
state: window.location.pathname+window.location.search
}, setSession(callback))
to the silentAuth function in auth.service.js, and in setSettion I added
const redirect = authResult.state || '/';
navigate(redirect)
Perfect glad to hear that and thanks for sharing with the rest of community @arn!
Am I correct, anybody can set the flag isLoggedIn to ‘true’ in local storage in his browser and get access to the route /account and he doesn’t need to login? It is not secure.
hi @arn, if I follow your code I get back a state that seems to be an encoded value, or a random value, but I’m not getting back the state I put in.
@sam.julien I’ve also tried the appState param, but that seems to always return ‘null’, I’m using the Universal login page…
@sam.julien friendly reminder on the Gatsby with SPA library, any time yet to whip up a new example?
Good weekend!
Ok got the state to work, but not using ‘state’, but in the login function in Sams sample, do:
auth.authorize({
appState: {
redirectUri: `${window.location.pathname}${window.location.search}`,
},
})
In setSettion you can now do the redirect as suggested by @arn
Perhaps this is related to me using the Universal Login, where I’ve seen some more cases of state not working.
If I remember correctly, a token is automatically placed in the authresult.state when no state is set (using universal login). I did a check like
if (authResult.state && authResult.state.charAt(0)==='/') {
navigate(authResult.state);
} else {
navigate('/');
}
Thanks guys for shaaring these code snippets!
@aldegoeij Hey there, good to hear from you! I’ve been working on a prototype of using auth0-spa-js with the Hooks wrapper inside of Gatsby. I’ve got it working in the browser, but it’s kind of useless right now because the build breaks due to the use of browser APIs. In the current implementation with auth0.js, you’ll notice we do a few isBrowser checks in the auth utility. Because it’s just a class, we can just return and pretend like nothing happened. With hooks, it’s a bit more complicated. I’m going to work with the SDK team to try to figure out the most idiomatic solution to this. Once I get that part figured out, I’ll be able to post the sample code here. Thanks for your continued patience! 
Fantastic tutorial. Thank you.
Question: what’s the simplest way to integrate this with Stripe and PayPal for subscriptions and handle user roles for different pages?
E.g. Customer makes a Gold subscription and can access all pages, but a Bronze subscription can only access some pages.
For Stripe and PayPal purchases, cancellations or billing changes, where to direct the webhook to add Auth0 account? I’d love a guide on this (I would even pay for it). No clear tutorials around that cover paid subscriptions + Auth0 + Gatsby.
Donovan, welcome to the Auth0 community 
It’s cool that you mention this use case of Stripe/PayPal. I’ve been polling internally for the demand for such content and collecting feedback from around our community.
Customer makes a Gold subscription and can access all pages, but a Bronze subscription can only access some pages.
This a pretty cool premise for a blog post 
I am going to open a new topic in this forum so we can move the discussion there, if you’d like. I’d love to get more of your thoughts on what the outline of such blog post may look like and also perhaps feedback from others 
Thank you!
UPDATE: Here’s the topic
Hi Sam Julien, I understand Gatsby is advocating using app.js for client-only routes and pages for statically rendered routes.
As your example is using pages for client-only routes, it will require additional codes in gatsby-node.js and will also not be in line with what Gatsby advocates in order to keep the codes cleaner and thus be easier to maintain down the road.
is it possible to rewrite your codes to use with app.js? Thanks
I’m sure Sam will cover that once he’s online!
Hey @myhendry, thanks for writing in.
Can you clarify what you mean by this and where you saw this recommendation?
The approach I took in the article was based on this livestream that Jason Lengstorf (former dev rel at Gatsby) did with Ado Kukic on adding Auth0 to Gatsby, so it’s definitely a viable way to do it (or at least it was at the time). It’s the same way they built the Gatsby swag store.
That said, as I’m building a new sample app with auth0-spa-js I will probably not take this same approach, so I’m curious to better understand what you mean.
Thanks!
Hi @sam.julien, my understanding is that the preferred way for dynamic apps in Gatsby is to use app.js. For static apps, we use pages. This way, we can better segregate concerns thus files in reserved ‘pages’ folder will be rendered statically whilst those in another folder will be rendered dynamically. I have done a demo authentication with Gatsby using Auth0 and simple-auth using Firebase. Firebase uses app.js while the Auth0 uses pages. Gatsby Auth Demo
I think consistency in pattern will make it easier for us to manage our project and separate portion of our apps which are dynamic and which are static.
Thanks for the excellent work with Auth0. it makes authentication a breeze 