Now I just get and post Firebase request through sending https request using C language.
Is there any way to use callback for this?
Because I want to get the latest data, now I just polling the https get requests. The SSL handshake may cause delay, so I want to add callback for this.
Related
I want to trigger a Supabase function whenever a new email arrives in Gmail.
If I understand Google's Instructions correctly, this needs to be done using Google's Pub/Sub service.
However, Supabase requires an authorization header to be sent with the POST request to the webhook, and while Pub/Sub allows for authorization, it only seems to support service accounts, and not just setting a simple Bearer token.
It seems like either polling or setting up a proxy webhook would be the only feasible options left—unless I'm missing a simpler way?
Thanks!
You can deploy the function to not require the auth headers by adding the --no-verify-jwt flag when deploying your functions.
From the edge functions docs
By default, Edge Functions require a valid JWT in the authorization header. This header is automatically set when invoking your function via a Supabase client library.
If you want to use Edge Functions to handle webhooks (e.g. Stripe payment webhooks etc.), you need to pass the --no-verify-jwt flag when deploying your function.
I am having frontend in React and backend in Spring boot. I am having GET/PUT/POST/DELETE HttpMethods in Rest API, but for every request from the client OPTIONS call is sent by the client(browser). Due to security reasons, I need to restrict these OPTIONS method call from the client. At this moment of time changing on API level is not feasible Is there any configuration kind of thing to prevent this.
React application is deployed on IIS and Spring boot application on Tomcat.
React application using Axios as HTTP Client.
Note: I know the preflight request is sent by browser and for this OPTIONS are getting invoked, I don't want to go in that direction.
These OPTIONS requests are part of the CORS specification which states that every PUT or POSTs with content type application/json must be preflighted with OPTIONS to check Access-Control-Allow-Origin header without causing any side effects.
I can't see any security issues with allowing OPTIONS, but in fact this is a security feature enforced by your browser.
To stop this behavior you should use same origin requests. Other possibilities which I won't recommend would be to just use GETs for your post requests or POST with content type other that application/json. And of course, you can write your own browser or connect from a native environment (as HttpClient on a desktop or mobile app).
Alright, first of all, I am absolutely aware that we have a bunch of answers on this and there is a plethora of articles on the topic. I just read these answers a second before typing this:
Why is CORS without credentials forbidden?.
Is CORS considered bad practice?
Etc. My particular situation is this - I just set up WebAPI2 for my practice project, the front end for which is running via gulp browser-sync. I have no idea how these ports get picked, but lets say the Web API is running on port http://localhost:1234/ and browser-sync generates the website on http://localhost:4321/. So I hit the API via angular's $http and get the famous CORS error (API controller method does get hit), so I am guessing it's the API returning not allowed. Edit: I fixed this via installing a CORS for Web API package via NuGet (Article Here) before asking this Q, just referencing for anyone who might need it later.
So, I was thinking, if I deployed this, ANY request would get denied, unless I am missing something. Or would it not be denied because of something I don't understand? Is disallowing CORS just a throwback from the MVC days? Or is there some purpose to it with APIs?
Maybe I am just ranting, but this confuses the **** out of me.
CORS is based on the response headers returned from the API. It is not the API that rejects responding to the request, the web browser explicitly disallows handling the response. The API will process the request as normal.
When dealing with anything other than a GET, CORS also requires a "preflight" request to the API first, to ensure subsequent requests are allowed. This amongst sending the headers back is what the Web API nuget package provides.
CORS is off by default for security purposes.
I have an AngularJS application that talks to various java services. In the application I have a global http header setting in an http interceptor. That means all the service requests from my application will get the header values.
Now the trouble is that all the services CORS settings won't allow this header value. Couple of services does, while others does not. The service calls to the servers that do not support the header fails, since the http interceptor always puts the header values.
Is there a better way to design, in the above said case, so as to avoid the issue stated?
Appreciate any help...
How about adding a response interceptor, looking for a 401 status? If you get a 401, attempt to do the same request again without the headers this time. If this succeeds, 'whitelist' this domain to make all following requests without the headers that you don't want.
Otherwise, if you have a limited number of services that you are making calls to, maybe whitelist them inside of your request interceptor? This would probably be easier, but it's not very elegant.
I am using libcurl's "easy" interface to access network devices over HTTP, currently using HTTP Basic authentication (which is the default in curl). I've found that it's possible to allow Digest authentication using curl_easy_setopt(curl, CURLOPT_HTTPAUTH, CURLAUTH_BASIC|CURLAUTH_DIGEST) but unfortunately this makes curl try all requests without any auth information at all, and then choosing the appropriate method according to WWW-Authenticate header in the response.
I know this has to be done the first time a specific device is accessed, but doing this for every single request seem quite excessive to me. Is it possible to make curl remember authentication state, and using the info in subsequent requests?
Re-use the same easy handle for the subsequent requests!