Using a Server API Key from 2 different dev boxes and Google Translate works fine. On the server I get the following error:
{
...
"code": 403,
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
I have added the Server IP to the list of approved IPs. I have tried using a browser key as well to no avail.
Related
I'm trying to sign in automatically when possible using following code (TypeScript, called from a React app):
google.accounts.id.initialize({
client_id: envSettings.auth.google.clientId,
callback: signInWithJwt,
auto_select: true,
});
google.accounts.id.renderButton(domElement, {
theme: "outline",
});
google.accounts.id.prompt();
I now have following situation:
Signing in via the rendered button always works (locally and on my "Static Web App" hosted in Azure)
google.accounts.id.prompt() however only works on localhost but not on the server, even though the URLs are added in the "Authorized JavaScript origins" section in the Google console. I get following message in the browser console: [GSI_LOGGER]: The given origin is not allowed for the given client ID.
The only difference I see between localhost and the server is that server is running on https and localhost is using http.
For me this does not really make sense, as obviously it does work with the button. Any thoughts on what is wrong here?
You need to follow the message, "The given origin is not allowed for the given client ID." Go to the google cloud console, and allow the origin that your server is on. Go to your project > APIs and Services > Credentials > your OAuth 2.0 Client ID, and edit it to allow your domain to be authorized.
This is for security purposes, so that a malicious actor cannot use your client ID to pose as your app on another domain, and access your users' data.
Google documentation
Found the issue thanks to this post: https://stackoverflow.com/a/70739451/4092115
I had to set the referrer policy in my index.html as follows:
<meta name="referrer" content="strict-origin-when-cross-origin" />
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
I signed up for an account to try out the REST geoencoding and the routing APIs. In both scenarios, I am getting a 500 internal server error with no details. Both example codes I have taken straight from the documentation and replaced my API key.
https://route.ls.hereapi.com/routing/7.2/calculateroute.json?apiKey=V6...oI&waypoint0=geo!52.5,13.4&waypoint1=geo!52.5,13.45&mode=fastest;car;traffic:disabled
https://geocoder.ls.hereapi.com/search/6.2/geocode.json?languages=en-US&maxresults=4&searchtext=Sunnyvale&apiKey=V6...oI
In both instances I get a generic 500 Internal Server error
{
"error": "Internal Server Error",
"error_description": "Internal Server Error"
}
I have tried signing up for two accounts just in case there was an issue with the first, but get the same response.
Any thoughts?
I just tested with my API key and it worked fine. It could have been a momentary issue, although I don't see any incidents in our status page (https://status.here.com/status). Can you try again please?
I've got a Meteor app that has been working fine. When deploying to iOS or Android, it still works fine.
But, when deploying to localhost, I now suddenly encounter this console error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at {{external json resource}}. (Reason: CORS
header ‘Access-Control-Allow-Origin’ does not match
‘http://localhost:12616’).
What I find eyebrow-raising is that my app, when running on localhost, runs on port 3000.
The app picks up external data from a Wordpress installation, using the Wordpress API. In that Wordpress installation I've got the following:
function add_cors_http_header(){
header("Access-Control-Allow-Origin: *");
}
add_action('init','add_cors_http_header');
How to resolve this?
I'm on Meteor 1.8.1.
When i try to validate the following page in the post inspector: https://www.cicomcopier.nl/nieuws/cicom-copier-levert-bijdrage-aan-de-ontwikkeling-en-realisatie-van-bellenschermen-tegen-verzilting-a-dam-rijnkanaal-en-noordzeekanaal/
I get the error: We encountered a server error while trying to inspect the URL.
and on the URL redirect trail i get: 0 undefined
I have no idea where to start debug this, is this a error on our side or linkedin side?
when i debug the URL using the facebook graph debugger everything seems to be right.
The problem in the end was the server from where I did the request wasn't setup correctly. Because from my side the site had a ssl installed and needed to do a ssl handshake with the LinkedIn server.
LinkedIn is made in java, and java has a more strict policy in validating the handshake. Because from my server setting the hostname for the ssl was not communicated correctly to LinkedIn there server did not validate the ssl and therefore could not connect to our server and receive a response. This ending in a unknown error on LinkedIn end of the site.
I keep getting the following error when I try to test one of my pages with Graph API Explorer:
{
"error": {
"message": "(#3502) Object at URL https://example.com/place/123456-Something has og:type of 'website'. The property 'bar' requires an object of og:type 'example:bar'. (http response code: 401)",
"type": "OAuthException",
"code": 3502
}
}
The problem is that this page is behind HTTP Basic Authentication and it returns 401 Unauthorized even if I pass proper credentials to authenticate for this page. I can't believe it but this seems to me that Graph API Explorer does not support HTTP Basic Authentication. Does anyone had this issue before and know how to force Graph API Explorer to be able to authenticate?
If the scraper (https://developers.facebook.com/tools/debug) cannot reach your page then it's not possible.
Open Graph pages must be public and reachable.
Using self-hosted objects requires that you host them as pages on your own webserver and all self-hosted objects are public.
https://developers.facebook.com/docs/opengraph/using-objects/
You can either punch a hole in basic auth via user agent (not secure, since that is trival to spoof) or Facebook's published list of crawler IP addresses.
I've written a quick PHP script here to generate an htaccess that includes simple auth and those IPs. FB says they shift the crawler IPs, so you'd want to do cron that script to regenerate the htaccess every so often.