Thank you for reading and welcome to our Community. I appreciate your kind feedback 
Let me ask you, please, was the order of the sections for this tutorial not too clear. I am wondering if I should rework it so that people donāt end up running on the same blocker.
These are excellent questions. I am consulting with our Security Team to find the best answer 
I think if you change " Below the App Variables section, create two new sections, Session Configuration and Passport Configuration :"
to say ā¦" Below the App Variables section but above App Configuration section, create two new sections, Session Configuration and Passport Configuration :" ā¦this will help others avoid the mistake that I made. Many thanks @Bastien227 for figuring this out. 
2 Likes
Glad you have it working now!
Excellent. Thank you for that feedback. Iāll be working on that today. I am going to revamp these tutorials Thereās something cool coming up!
I have an answer for question 1:
is it safer to save it as an environment variable?
Itās definitely recommended and a best practice to store the session secret in a .env file for the module to consume using a package like dotenv. I will update the tutorial to reflect this step. Thank you for bringing this up!
As far as question 2:
is there an easy way to encrypt it?
None of the services mentioned in this answer are endorsed by Auth0 but rather I am sharing with you common approaches used in the industry 
Select the option that best fits your requirements and use cases after youāve researched it more in depth to verify if your chosen infrastructure stores secrets securely
Iāll borrow a page from a blog post from Heroku:
The post stresses the importance of not storing application configuration variables in your code but rather to use your chosen infrastructure to store those variables. It suggests using Hashicorp Vault if you want to manage secrets on an external service.
There are other services like Vault offered by Google and Amazon:
I personally use Heroku and Vercel for deploying Single Page Applications and Traditional Web Apps. Vercel encrypts the environmental variables you store in their platform. I am not certain if Heroku does it natively but they also offer add-ons that add encryption and easier secret management. But when you use a platform to deploy your apps, you are delegating the storage and usage of those variables to the platform. I recommend for you to check the platformās documentation to verify how they manage environmental variables or ask their Support team directly.
@dan-auth0 Thanks for your speedy response. I shall look those resources up. I have used Heroku before but was investigating Firebase. I will post any findings here if successfull.
1 Like
@dan-auth0. I get a similar problem to @peterz2099 in that everything works on localhost but on heroku I get "The page isnāt redirecting properly
An error occurred during a connection to shielded-reaches-25776.herokuapp.com.
This problem can sometimes be caused by disabling or refusing to accept cookies. " Did you manage to solve this please?
I think I may have found the answer. On Heroku I checked out add ons and the free plan Auth0 addon does not allow redirect rules to be set .You have to subscribe $23 per month for the developer plan 
1 Like
I am investigating this Heroku issue for you. I was able to deploy mine to Heroku without any problem but we use a paid plan. Let me check what Sales or Support says about this and Iāll get back to you!
1 Like
@zettiliazee I checked with our Sales team and got as response that redirect rules are included in all plans, including the free plan. We donāt have a limit on that feature, so even if you were to purchase Auth0 through Heroku, that should not cause any issue regarding redirect rules. It could be something related to the actual deployment. Were you deploying this the end-result of this tutorial straight up?
I do recall there is a nuance with Heroku deployments. I wonder if these could help you out:
From Login README:
If youāre using a hosting provider that uses a proxy in front of Node.js, comment in the
trust proxyconfiguration in app.js. This is aexpress-sessionconfiguration setting that allows for trusting this first proxy.
Thereās also another issue related to cookies and setup:
Adding the following code fixed that issue but I think your error message is different 
if (app.get("env") === "production") {
// trust first proxy for Heroku production deployment
app.set("trust proxy", 1);
// serve secure cookies, requires https
sessionOptions.cookie.secure = true;
}
Iāve followed this and everything works great, thanks for the tutorial! However, once I put this into production, Iām stuck in a redirect loop between Auth0 and my page because there is no user instance in my requests, although logs show a successful login. Its because in production, we start up 3 containers with the frontend app. We need the resilience and backups. The load balancer distributes the requests among them (in dev, we only have 1 up). If we take prod down to 1 container, it works fine. It appears that the node server needs to be the same one that initiated the login, despite it being on the same url. Is there a way inside Auth0 around it or it does not support multiple server instances?
1 Like
Hello, Matic. Thank you for reading the post. Let me ask around about multiserver instances and Auth0.
Matic, I got you a response!
For regular web apps, like the one you build on this blog post using Node.js, Express, and Passport, you have the following options using a load balancer:
- Sticky sessions: The load balancer always redirects requests from the same user agent to the same node.
- Shared session storage: The session storage is separated from the nodes and shared across all of them.
It is up to the load balancer to decide how to distribute the requests and retry them in case of the failure. It can retry the request, redirect it to another node or do something in between.
The exact implementation is independent of Auth0 and depends on your application needs. If youād like assistance on developing this strategy, we have some consultancy offerings with our Professional Services team
1 Like
Thanks for the tips and the quick reply! weāve actually started looking into either the shared session storage or a completely new approach where we drop the session altogether and use the JWT approach.
1 Like
You are welcome! Best of luck in your implementation
Hey Dan,
I followed this tutorial and the one previous with no problems however after writing the /login /callback and /logout methods and tying in the router from the auth.js file Iām experiencing an problem.
When I click login Iām redirected to my auth0 social sign in portal as expected, but after selecting Google and confirming my details, Iām simply passed back to the portal and asked to sign in still.
Iāve noticed in the Dev Tools / Network tab, Iām getting an error 404 on the auth0.min.esm.js:8 initiator for ssodata.
Not sure if you have any insight. I manually typed the code up myself, but after experiencing the error I went back and copy pasted it to ensure it was written word for word correctly, but same error still.
1 Like
Howdy, Ash! Welcome to the Auth0 Community and thank you for reading the blog post. I am going to push an update to this post within the next two weeks, which I tested this past weekend. However, there is no much change on the structure of the code.
I didnāt experience any errors myself. If this is only happening with Google, it may be related to using the Auth0 Dev Keys for Google Authentication. Could you try setting it up with your own Dev Keys, please?
Yeah, no problem Dan, I wonāt get a chance until after the weekend now, but thanks for the response.
Iāll actually go back through it all again early next week once youāve updated it, itās all good learning!
1 Like
Sounds like a plan. Thank you