I am using Auth0 NextJs SDK for authentication in my NextJS App. I am following this tutorial https://auth0.com/blog/introducing-the-auth0-next-js-sdk/. In my local machine, everything works fine.
The configuration for Auth0 in my local server:
AUTH0_SECRET=XXXXX
AUTH0_BASE_URL=http://localhost:3000
AUTH0_ISSUER_BASE_URL=https://myappfakename.us.auth0.com
AUTH0_CLIENT_ID=XXXX
AUTH0_CLIENT_SECRET=XXXX
In the Auth0 Dashboard, I added the following URLs :
Allowed Callback URLs: http://localhost:3000/api/auth/callback
Allowed Logout URLs: http://localhost:3000/
My local app works locally fine.
I uploaded the app on Vercel. And changed the
AUTH0_BASE_URL=https://mysitefakename.vercel.app/
In Auth0 Dashboard, updated the following information:
Allowed Callback URLs: https://mysitefakename.vercel.app/api/auth/callback
Allowed Logout URLs: https://mysitefakename.vercel.app
I am getting the following error:
Oops!, something went wrong
Callback URL mismatch.
The provided redirect_uri is not in the list of allowed callback URLs.
Please go to the Application Settings page and make sure you are sending a valid callback url from your application
What changes I should make it works from Vercel as well?
You can try to check if vercel isn't changing the url when redirecting to auth0. Your configurations seems good to me. The error is very explicit though. I think a good option should be to verify that the redirect (if handled by vercel) is doing with the same url as auth0 expects.
And don't forget to add the url you're currently on when performing the callback. Are you in https://mysitefakename.vercel.app/api/auth/callback when the callback is executed? (call auth0).
you have to change your base url in the env.local file
AUTH0_BASE_URL=https://mysitefakename.vercel.app/
you can also make two more env files namely env.development and env.production and set different base urls for different cases so that the correct base url is automatically loaded depending on how ur web app is running.
You need to add handleLogin under api/auth/[...auth0].js and that will solve it:
import { handleAuth, handleLogin } from '#auth0/nextjs-auth0';
export default handleAuth({
async login(request, response) {
await handleLogin(request, response, {
returnTo: '/profile',
});
},
});
Don't forget to also add allowed callback url in [Auth0 Dashboard]: https://manage.auth0.com/dashboard for your hosted app for both local and hosted instance:
http://localhost:3000/api/auth/callback, https://*.vercel.app/api/auth/callback
Related
I know that the signInWithRedirect() flow in Firebase does not behave correctly in some browsers because it uses cross-origin.
https://github.com/firebase/firebase-js-sdk/issues/6716
When using signInWithRedirect(), the following article is a best practice.
https://firebase.google.com/docs/auth/web/redirect-best-practices
I have an app created in Next.js with authentication using signInWithRedirect() and deployed it to Vercel.
If I do nothing, it will not work in Safari as described in the above issue.
So I took the following 3 actions and confirmed that it works correctly.
Reverse proxy settings(next.config.js)
/** #type {import('next').NextConfig} */
module.exports = {
reactStrictMode: true,
async rewrites() {
return [
{
source: '/__/auth/:path*',
destination: `https://${process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN}/__/auth/:path*`,
},
]
},
}
Changed authDomain when initializing FirebaseApp to the app's domain
In GCP, change approved redirect URI to https://<the-domain-that-serves-my-app>/__/auth/handler.
These are the third method in Best practices.
I do not fully understand why this setup solves the problem, and I would like to correct my understanding.
My understanding is as follows
authDomain = a.com (domain of the app)
An authentication request is generated from the browser and redirected to authDomain (a.com)
The request is forwarded to https://<project>.firebaseapp.com/__/auth/ because a reverse proxy is set up
Host the login helper code to the identity provider at <project>.firebaseapp.com.
Return to a.com
Access login helper storage from browser
Authenticated redirect URI is set to the app domain, so the information is stored in the browser's storage in the app domain. And since the authDomain is the same as the app's, the authentication iFrame is referenced to it.
Is this understanding correct?
I have a javascript file hubspot.js on src/api folder of my gatsby project which become functions automatically with paths based on their file name (according to Gatsby Documentation).
This API is called when submitting one form which should create a contact in hubspot.
When I run the project in development, it successfully returns the response and contact is created. But, while using "serve public" to test in production, it returns:
POST http://localhost:3000/api/hubspot 404 (Not Found)
and also in deploying using nginx configuration, it returns 405 error.
I also have another api function called status which is like this and is a GET api.
export default function handler(req, res) {
res.status(200).json({ status: 'ok' });
}
Even this function is not called and returns not found error.
I don't have any backend as gatsby can handle that part by itself, as described here.
Functions let you build dynamic applications without running servers. Submit forms, authenticate users, securely connect to external services, build GraphQL/REST APIs, and more.
Gatsby Function
So, even in production, this must be handled and the api should be called when the form submits or when I make a GET request to /api/status.
But, all I am getting is 404 not found and 405 error.
I'm using Meteor v1.9 Webapp API to have my app listen to HTTP requests, specifically from a link to the app itself from a website, let's say example.org.
The documentation says to use
WebApp.connectHandlers.use([path], handler)
Where the [path] is defined as such:
path - an optional path field. This handler will only be called on
paths that match this string. The match has to border on a / or a ..
For example, /hello will match /hello/world and /hello.world, but not
/hello_world.
My question:
Let's say my meteor application is hosted on abc.com and the POST data being sent over to it is from example.org (where the link to abc.com is as well).
For the [path] argument mentioned above, in this case, should I have it as "/example" since example.org is where my app is listening to requests from (getting the POST data)? Or does it have to be a different format? I tried the former, but it doesn't seem to be working for it, so I'm trying to find the root of the issue.
Additional information that might be useful: I know it says 'optional' so I tried omitting it, but when I tested it out via 'meteor run' where it runs off of localhost:3000, it just yielded a blank page, with no errors and a success sent back, probably because it uses a GET request instead of POST.
My code for the webapp in my meteor application is as follows:
WebApp.connectHandlers.use("/[example]", async (req, res, next) => {
userName = req.body;
res.writeHead(200);
res.end();
});
Also technically my meteor application is built/bundled and deployed as a Node.js application on the website, but that shouldn't affect anything regarding this as far as I could tell.
That path is the path (part of the URL) on your meteor server. So in your example, for instance,
WebApp.connectHandlers.use("/example", async (req, res, next) => {
userName = req.body;
res.writeHead(200);
res.end();
});
means that you will need to send your POST requests to abc.com/example.
I have a middleware page on a route that first makes a check against the backend server.
In that middleware I'm trying to call a next.js api page using the fetch API, which in turn communicates with the backend. This flow works as expected in the local development environment, but when deployed to vercel, this fails.
The caught error displayed in vercel is: TypeError: Fetch API cannot load: /api/make-check-at-backend/].
The URL used is a relative path: fetch("/api/make-check-at-backend/", ...).
What is the issue there? Do I need to include the fully qualified URL value where the next.js app is hosted, including domain, protocol, etc? If that's the case, how can the server/host name be retrieved from Vercel? Should I use env variables?
This is the fetch code used in the middleware:
const retrievedValue = await fetch("/api/make-check-at-backend/", {
method: "POST",
headers: headers,
body: JSON.stringify({ someKey: 'someValue' }),
});
P.S. I've also tried using axios to make the http call directly to the backend, but this failed with an axios adapter known issue. This same backend call works as expected from any api/* page. Is all this due to middleware functionality being still in Beta?
Turns out that the Vercel setup has a number of system environment variables which are available in their corresponding deployed sites.
From my experience, in those deployed sites, the fetch API needs to have the full URL, including protocol, host, pathname, etc.
After some trial and error, I have found the code that works in the deployed sites is:
const retrievedValue = await fetch(`https://${process.env.VERCEL_URL}/api/make-check-at-backend/`, {
method: "POST",
headers: headers,
body: JSON.stringify({ someKey: 'someValue' }),
});
Below follows a screenshot of the Vercel's environment variables documentaiton, in case the link above becomes broken over time.
I read a lot of questions about 'history.push nginx react-router' but I didn't find the solution for the problem I'm facing.
The problem is, when I log in my application in my Login component I do something like this after the ajax call is executed:
cb = (res) => {
if (res.token!== null && res.token !== undefined){
localStorage.setItem("token",res.token);
localStorage.setItem("expiresIn",res.expiresIn);
localStorage.setItem("email", res.email);
**history.push('/home/0/0');**
}else{this.setState({errorTextMail:"wrong mail or wrong password!"})}}
Locally it works fine but in the console the history.push('/home/0/0') fires a request that nginx doesn't handle and return 404, but in my browser the app log me in and I don't see the error.
Instead when I build the app and put the build folder under nginx to serve static files, when I try to login it show me the 404 page. Then if I refresh the page (removing the /home/0/0 from the url) it works fine, recognize the token and log me in and I can browse other route of the app.
I was supposed that history.push would have been handled by react-router, just changing the component mapped by the appropriate <Route path="/home/:idOne/:idTwo" component={Home} /> component and not firing a new request to nginx.
My question is, there is a way to switch compoent when the cb function return my token instead of using history.push('/home/0/0')?
Note the history object is defined this way
import history from './history';
and the history.js's content is :
import createHistory from 'history/createBrowserHistory'
export default createHistory({
forceRefresh: true
})
Thanks for any suggestion.