Gatsby Deployment Issue - nginx

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.

Related

What path should I use for Meteor's Webapp API?

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.

How to fix "Callback URL mismatch" NextJs Auth0 App

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

firebase callable functions returning CORS error and not being called from client

I have been using firebase functions for quite some time and all deployments of functions have been going quite smoothly. All of a sudden any new functions deployed have stopped working and any calls from the client return a CORS error. If I check the functions list in the firebase dashboard I can't see the functions being called which is similar to what I would expect if the functions simply didn't exist at all.
I am now just trying a simple basic function like below:
exports.createSession = functions.region('europe-west2').https.onCall(async (data, context) => {
return ({status: 200})
});
On the frontend I am doing a simple call like below:
const createSessionFunction = functions.httpsCallable('createSession');
const response = await createSessionFunction({});
All the other functions that were create and deployed prior to this week are working fine. Any new functions are not.
The error I get is below:
Access to fetch at 'https://europe-west2-xxxxxxx.cloudfunctions.net/createSession' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
index.cjs.js:614 POST https://europe-west2-xxxxxxxz.cloudfunctions.net/createSession net::ERR_FAILED
My function list on the firebase GUI show this function does exist:
createSession - Request - https://europe-west2-xxxxxxxx.cloudfunctions.net/createSession-europe-west2-Node.js 8 -256 MB - 60s
However the logs show that it is never called from the client when I'm trying to test it which means the client might not be detecting this function at all.
I have tried the following steps with no luck:
Delete and redeploy the functions
Rename the function and redeploy
Deploy the same new function on different applications (dev/test etc)
Any ideas?
This was resolved on the google cloud dashboard by granting all my functions public access. The default permissions has changed from public to private.
https://cloud.google.com/functions/docs/securing/managing-access-iam#allowing_unauthenticated_function_invocation

Return custom error from appengine behind Google Cloud Endpoints

I am using flask and python 3.6 as a backend service that is deployed to App Engine in GCP. This backend is sitting behind Google Cloud Endpoints deployed in Cloud Run. Endpoints takes all my 404 messages and just returns 404 Not Found. I want to send a more informative error message with the 404 code. Is there any way to do so using my current setup? Thanks
You can create a custom 404 html page:
#app.errorhandler(404)
def page_not_found(e):
return render_template('404.html'), 404
Then, you need to create 404.html file.
You can use the Python Endpoints library to send HTTP error codes with a custom message as follows:
message = 'No entity with the id "%s" exists.' % entity_id
raise endpoints.NotFoundException(message)
You can find more info in the docs

Why do I get auth'ed when I test hitting my Firebase Cloud Function in a browser?

I have a Firebase Cloud Function that handles HTTP requests, using:
export const foo = functions.https.onRequest((req, res) => {
// etc.
}
When I hit the URL for it in a browser, I see a Google sign in page, listing my Google accounts. If I sign in, I then get a 403:
Error: Forbidden
Your client does not have permission to get URL /foo from this server.
Why? There's nothing about this in the docs that I can find. I'm on the free plan ("Spark"), if that makes any difference.
[edit]
I'm accessing the function using the URL:
https://us-central1-[project name].cloudfunctions.net/[function name]
There's no vanity URL.
The 403 message is originating from the main url https://us-central1-[project-name].cloudfunctions.net/ which is fully managed by Google.
It seems cloud functions does not have an error handling for non-existing functions name. Thus everything that is not created are treated the same way as a forbidden link. I don't know if this is an intended behavior but since the functions are running on a managed environment, there's not much handling of not existing functions against your project cloud function url.
The following statement from the link above explains it all:
"Cloud Functions run in a fully-managed, serverless environment where Google handles infrastructure, operating systems, and runtime environments completely on your behalf. Each Cloud Function runs in its own isolated secure execution context, scales automatically, and has a lifecycle independent from other functions. "
Hope this helps.

Resources