I am sending an image to an API using my localhost address but for some reason it doesn't identify the image. It works fine if I use links on google. The code looks something like this:
unirest.post(requestString)
.header("X-RapidAPI-Key", API_KEY)
.field("urls", "http://localhost:4000/uploads/1570544614486-test.jpg")
.field("album", ALBUM_NAME)
.field("albumkey", ALBUM_KEY)
.field("entryid", entryId)
.end(result => {
console.log(result.body);
});
I believe this will work once on a domain but I need it to work now for testing. How can I make this work using my localhost?
You haven't exactly specified what API you're reaching out to, so your mileage may vary with different APIs.
However, based on your error message, I've determined you're trying to leverage the Lambda Face Recognition and Face Detection API via RapidAPI. This (linked) docs for this web service clearly show that the urls parameter you're attempting to use with your localhost URL above is actually meant to hold a comma-separated set of URLs to publicly-accessible image files. The remote API can't possibly resolve localhost in this context, because (a) it can't possibly have any idea what IP localhost should refer to, and (b) it's highly likely that your localhost here doesn't respond to HTTP requests from the broader Internet.
Instead, modify your request to use the files parameter (type binary) to upload the raw binary data for your image(s).
I'm making a chrome extension that injects an iframe on a webpage and show some stuff.
Content loaded in iframe is from https://example.com and i have full control over it. I'm trying to access cookies of https://example.com from the iframe (which i think should be available) by document.cookie. This is not letting me access httponly flagged cookie and i do not know reason for this. After all this is no cross-domain. Is it?
Here is the code i'm using to get cookie
jQuery("#performAction").click(function(e) {
e.preventDefault();
console.log(document.domain); // https://example.com
var cookies = document.cookie;
console.log('cookies', cookies);
var httpFlaggedCookie1 = getCookie("login_sess");
var httpFlaggedCookie2 = getCookie("login_pass");
console.log('httpFlaggedCookie1 ', httpFlaggedCookie1 ); // shows blank
console.log('httpFlaggedCookie2 ', httpFlaggedCookie2 ); // shows blank
if(httpFlaggedCookie2 != "" && httpFlaggedCookie2 != ""){
doSomething();
} else{
somethingElse();
}
});
Any suggestions what can be done for this?
By default in Chrome, HttpOnly cookies are prevented to be read and written in JavaScript.
However, since you're writing a chrome extensions, you could use chrome.cookies.get and chrome.cookies.set to read/write, with cookies permissions declared in manifest.json. And be aware chrome.cookies can be only accessed in background page, so maybe you would need to do something with Message Passing
Alright folks. I struggled mightily to make httponly cookies show up in iframes after third party cookies have been deprecated. Eventually I was able to solve the issue:
Here is what I came up with:
Install a service worker whose script is rendered by your application server (eg in PHP). In there, you can output the cookies, in a closure, so no other scripts or even injected functions can read them. Attempts to load this same URL from other user-agents will NOT get the cookies, so it’s secure.
Yes the service workers are unloaded periodically, but every time it’s loaded again, it’ll have the latest cookies due to #1.
In your server-side code response rendering, for every time you add a Set-Cookie header, also add a Set-Cookie-JS header with the same content. Make the Service Worker intercept this response, read that cookie, and update the private object in the closure.
In the “fetch” event, add a special request header such as Cookie-JS, and pass what would have been passed in the cookie. Add this to the request headers before sending the request to the server. In this way, you can send all “httponly” cookies back to the server, without the Javascript being able to see them, even if actual cookies are blocked!
On your server, process the Cookie-JS header and merge that into your usual Cookies mechanism, then proceed to run the rest of your code as usual.
Although this seems secure to me — I’d appreciate if anyone reported a security flaw!! — there is a better mechanism than cookies.
Consider using non-extractable private keys such as ECDSA to sign hashes of payloads, also using a service worker. (In super-large payloads like videos, you may want your hash to sample only a part of the payload.) Let the client generate the key pair when a new session is established, and send the public key along with every request. On the server, store the public key in a session. You should also have a database table with the (publicKey, cookieName) as the primary key. You can then look up all the cookies for the user based on their public key — which is secure because the key is non-extractable.
This scheme is actually more secure than cookies, because cookies are bearer tokens and are sometimes subject to session fixation attacks, or man-in-the-middle attacks (even with https). Request payloads can be forged on the server and the end-user cannot prove they didn’t make that request. But with this second approach, the user’s service worker is signing everything on the client side.
A final note of caution: the way the Web works, you still have to trust the server that hosts the domain of the site you’re on. It could just as easily ship JS code to you one day to sign anything with the private key you generated. But it cannot steal the private key itself, so it can only sign things when you’ve loaded the page. So, technically, if your browser is set to cache a top-level page for “100 years”, and that page contains subresource integrity on each resource it loads, then you can be sure the code won’t change on you. I wish browsers would show some sort of green padlock under these conditions. Even better would be if auditors of websites could specify a hash of such a top-level page, and the browser’s green padlock would link to security reviews published under that hash (on, say, IPFS, or at a Web URL that also has a hash). In short — this way websites could finally ship code you could trust would be immutable for each URL (eg version of an app) and others could publish security audits and other evaluations of such code.
Maybe I should make a browser extension to do just that!
We're trying to develop an geoplacement app for one of our clients, and we want first to test it in out own domain.
We have signed for Google Maps JavaScript API, and we have a valid browser key and our domain, www.grupocamaleon.com, has been authorized to use that key.
But we can't make even the easiest example to run without error.
We have, in our domain and with our key, the following demo:
(1) http://www.grupocamaleon.com/boceto/aerial-simple.html
But it doesn't work, and Firebug console says:
"Google Maps API error: Google Maps API error: RefererNotAllowedMapError (link to Google documentation on RefererNotAllowedMapError) Your site URL to be authorized: (1)"
My credential page is missing the possibility of adding referrers to accept, so solutions involving adding referrers are not possible right now.
My credential Page:
Why do we get that error? How can we fix it?
I know this is an old question that already has several answers, but I had this same problem and for me the issue was that I followed the example provided on console.developers.google.com and entered my domains in the format *.domain.tld/*. This didn't work at all, and I tried adding all kinds of variations to this like domain.tld, domain.tld/*, *.domain.tld etc.
What solved it for me was adding the actual protocol too; http://domain.tld/* is the only one I need for it to work on my site. I guess I'll need to add https://domain.tld/* if I were to switch to HTTPS.
Update: Google have finally updated the placeholder to include http now:
Come on Google, you guys are smarter than the API Credential page lets on. (I know because I have two sons working there.)
The list of "referrers" is far pickier than it lets on. (Of course, it should be more forgiving.) Here are some rules that took me hours to discover:
The order in the list is important. Moving your URL up in the list may make it work.
"http://" prefix is required.
Even "localhost" needs it: "http://localhost/foo/bar.html"
A trailing * as a wildcard seems to work as if it is a string compare.
Even with "http://localhost/foo/bar.html", "http://localhost/foo/bar.html?arg=1" will not work. (Will a wildcard help?)
For both prod dev, have (at least) two rows: "http://localhost/foo/bar.html" and "http://my.site.com/foo/bar.html"
A port number (8085? 4000?) does not seem to be necessary.
There are probably other rules, but this is a tedious guessing game.
Wildcards (asterisks) ARE NOT allowed in the subdomain part.
WRONG: *.example.com/*
RIGHT: example.com/*
Forget what Google says on the placeholder, it is not allowed.
According to the documentation, 'RefererNotAllowedMapError' means
The current URL loading the Google Maps JavaScript API has not been
added to the list of allowed referrers. Please check the referrer
settings of your API key on the Google Developers Console.
I have the Google Maps Embed API set up for my own personal/work use and thus far have not specified any HTTP referrers. I register no errors. Your settings must be making Google think the URL you're visiting is not registered or allowed.
Just remind that if you just change it, it may take up to 5 minutes for settings to take effect.
I tried many referrer variations and waiting 5 minutes as well until I realized the example Google populates in the form field is flawed. They show:
*.example.com/*
However that only works if you have subdomain. or www. in front of your domain name. The following worked for me immediately (omitting the leading period from Google's example):
*example.com/*
According the google docs
this happened because the url on which you are using the Google Maps API, it not registered in list of allowed referrers
EDIT :
From Google Docs
All subdomains of a specified domain are also authorized.
If http://example.com is authorized, then http://www.example.com is also authorized. The reverse is not true: if http://www.example.com is authorized, http://example.com is not necessarily authorized
So,Please configure http://testdomain.com domain, then your http://www.testdomain.com will start work.
Check you have the correct APIS enabled as well.
I tried all of the above, asterisks, domain tlds, forward slashes, backslashes and everything, even in the end only entering one url as a last hope.
All of this did not work and finally I realised that Google also requires that you specify now which API's you want to use (see screenshot)
I did not have ones I needed enabled (for me that was Maps JavaScript API)
Once I enabled it, all worked fine using:
http://www.example.com/*
I hope that helps someone! :)
The Problem
Google suggests the format *.example.com/*This format does not work.
The Solution
Check the browser console for the Google Maps JavaScript API error: RefererNotAllowedMapError
Underneath the error it should have: "Your site URL to be authorized: https://example.com/".Use that url for the referrer and add a wildcard * to the end of it (https://example.com/*, in this case).
I found that even your HTTP Referreres are valid enough, wrong set of API Restrictions causes Google Maps JavaScript API error: RefererNotAllowedMapError.
For example:
You are using Javascript API for the key.
Add http://localhost/* to Application Restrictions / HTTP Referrences
Choose Maps Embed API instead of Maps Javascript API
This causes RefererNotAllowedMapError
There are lots of supposed solutions accross several years, and some don’t work any longer and some never did, thus my up-to-date take working per end of July 2018.
Setup:
Google Maps JavaScript API has to work properly with…
multiple domains calling the API: example.com and example.net
arbitrary subdomains: user22656.example.com, etc.
both secure and standard HTTP protocols: http://www.example.com/ and https://example.net/
indefinite path structure (i.e. a large number of different URL paths)
Solution:
Actually using the pattern from the placeholder: <https (or) http>://*.example.com/*.
Not omitting the protocol, but adding two entries per domain (one per protocol).
An additional entry for subdomains (with a *. leading the hostname).
I had the feeling that the RefererNotAllowedMapError error still appeared using the proper configuration (and having waited ample time). I deleted the credential key, repeated the request (now getting InvalidKeyMapError), created new credentials (using the exact same setup), and it worked ever since.
Adding mere protocol and domain seemed not to have included subdomains.
For one of the domains, the working configuration looks like this:
(As text:)
Accept requests from these HTTP referrers (web sites)
https://*.example.com/*
https://example.com/*
http://*.example.com/*
http://example.com/*
None of these fixes were working for me until I found out that RefererNotAllowedMapError can be caused by not having a billing account linked to the project. So make sure to activate your free trial or whatever.
This is another sh1tty Google product with a terrible implemenation.
The problem I have found with this is that if you restrict an API key by IP address, it wont work... BUT far be it from Google to make this point clear... It wasn't until troubleshooting and researching I found:
API keys with an IP addresses restriction can only be used with web
services that are intended for use from the server side (such as the
Geocoding API and other Web Service APIs). Most of these web services
have equivalent services within the Maps JavaScript API (for example,
see the Geocoding Service). To use the Maps JavaScript API client side
services, you will need to create a separate API key which can be
secured with an HTTP referrers restriction (see Restricting an API
key).
https://developers.google.com/maps/documentation/javascript/error-messages
FFS Google... Pretty important piece of information that would be good to clarify on setup...
Accept requests from these HTTP referrers (web sites)
Write localhost directory path
I experienced the same error:
This link talks about how to set up API key restrictions: https://cloud.google.com/docs/authentication/api-keys#adding_http_restrictions
In my case, the problem was that I was using this restriction:
HTTP referrers (web sites) Accept requests from these HTTP referrers
(web sites) (Optional) Use *'s for wildcards. If you leave this blank,
requests will be accepted from any referrer. Be sure to add referrers
before using this key in production.
https://*.example.net/*
This means that URLs such as https://www.example.net or https://m.example.net or https://www.example.net/San-salvador/ would work. However, URLs such as https://example.net or https://example.net or https://example.net/San-salvador/ would not work. I simply needed to add a second referrer:
https://example.net/*
That fixed the problem for me.
I add 2 website domains, set "*" in subdomain is not working but specific subdomain "WWW" and non-subdomain have been worked for my websites using the same Google Map API key.
dont' use "*" in subdomain
Hope it help.
That your billing is enabled
That your website has been added to Google Console
That your website is added to the referrers in your app.
(do a wildcard for both www and none www)
http://www.example.com/* and http://example.com/*
That Javascript Maps is enabled and you are using the correct credentials
That the website has been added to your DNS to enable your Google Console above.
Smile after it works!
Enable billing for Google project fixed the problem.
you show a screenshot of your api credentials page, but you have to click on "Browser key 1" and go from there to add referrers.
For deeper nested pages
If you have a project in a folder for example or nested pages
http://yourdomain.com/your-folder/your-page you can enter this in
http://yourdomain.com/*/*
The important part being /*/*/* depending how far you need to go
It seems that the * will not match / or get into deeper paths..
This will give your full domain access, well unless you have deeper nesting than that..
I struggled to make this work as well, but here are some pointers:
The URLs set as referrers include http, e.g. http://example.com/*
Google Maps JavaScript API was enabled
Billing was set-up on this account
Once all of this above was resolved, the maps displayed as expected.
http://www.example.com/* has worked for me after days and days of trying.
I got mine working finally by using this tip from Google:
(https://support.google.com/webmasters/answer/35179)
Here are our definitions of domain and site. These definitions are specific to Search Console verification:
http://example.com/ - A site (because it includes the http:// prefix)
example.com/ - A domain (because it doesn't include a protocol prefix)
puppies.example.com/ - A subdomain of example.com
http://example.com/petstore/ - A subdirectory of http://example.com site
I was attempting to use the Places API (Autocomplete) and had to also enable the Maps Javascript API from within Google Cloud Console before the Places API would work.
Removing the restrictions (to None) worked for me.
In my experience
http://www.example.com
worked fine
But, https required /* at the end
Chrome's Javascript console suggested I declare the entire page address in my HTTP referrer list, in this instance http://mywebsite.com/map.htm Even though the exact address is http://www.mywebsite.com/map.htm - I already had wildcard styles listed as suggested by others but this was the only way it would work for me.
This worked for me. There are 2 major categories of restrictions under api key settings:
Application restrictions
API restrictions
Application restrictions:
At the bottom in the Referrer section add your website url
" http://www.grupocamaleon.com/boceto/aerial-simple.html " .There are example rules on the right hand side of the section based on various requirements.
API restrictions:
Under API restrictions you have to explicitly select 'Maps Javascript API' from the dropdown list since our unique key will only be used for calling the Google maps API(probably) and save it as you can see in the below snap. I hope this works for you.....worked for me
Check your Script:
Also the issue may arise due to improper key feeding inside the script tag. It should be something like:
<script async defer src="https://maps.googleapis.com/maps/api/jskey=YOUR_API_KEY&callback=initMap"
type="text/javascript"></script>
If you are working on localhost then do not include http or https in the url.
Use "localhost" without protocols. I struggled for days and found it working.
Something no one else seems to have mentioned in here that may be important is also this:
Http referrers are case sensitive.
So say you have someone access https://www.example.com/webpage, and someone wrote a link to that page as https://www.example.com/Webpage, you need BOTH entries, otherwise one of them is not going to work (unless you URL-rewrite to remove caps, or replace /Webpage with /*, but in our case, we want to limit down to folders under a certain domain, so this is a pain in the butt).
I feel like this is a bit stupid. Yes, URLs can be case sensitive, but not to the point where you would restrict a folder if its in caps, but not if it's lowercase, right?
I have a javascript application that loads data asynchronously from a server within my company's firewall. We sometimes need to show this application outside of the firewall but it is not always possible to get on the VPN. For this reason, we configured the firewall to allow public requests for this data on a specific port. The catch: when I am inside the corporate network, I can only load data using the server's DNS name due to a peculiar configuration of the firewall. Outside of the corp network, I have to use the server's public IP address..
Currently we distribute two versions of the javascript application -- one which works within the firewall and one that works outside of it. We would like to distribute one app -- one that tests the URLs and then, depending on which is reachable, continue to use that address to load data.
I have been using jQuery's $.ajax() call to load the data and I noticed there is a timeout parameter. I thought I could use a short timeout to determine which server is unreachable.. However, this "countdown" doesn't seem to start until the initial connection to the server is made.
Any thoughts on how to determine, in javascript, which of two servers is reachable?
Use the error event:
$.ajax({
url: dnsUrl,
success: ... // Normal operation
error: function () {
$.ajax({
url: ipUrl,
success: ... // Normal operation
});
}
});
You may put some dummy-images on the server and try to load them. the onload-event of the image that was successfully loaded should fire.