This might be the stupiest question of the day but does Google Latitudes API work with unsecured pages, HTTP?
The Latitude API works over HTTPS only, but you can certainly have an application that makes requests to the Latitude API, and then returns results on HTTP pages.
Related
I am creating an API that would serve data to my frontend app. The API is on api.myapp.com and the app on www.myapp.com (same domain, just another subdomain). They communicate with AJAX requests and CORS is all set up, working fine.
But I have another app on another domain (www.myotherapp.com) which partialy uses the same data as myapp, so I was thinking of reusing the API so myotherapp could requests data from it too.
I think it is one use case of API, to be reusable, right?
But then, there is something that I may have missed, because as my API has CORS enabled with "Access-Control-Allow-Origin: www.myapp.com", it won't allow other apps to use its endpoints, right? Their AJAX requests would fail with CORS policies.
So how are public API built and configured? How should I set my API so it can serve several apps (ideally, only the ones I allow)?
Thanks for the explanations :)
There is an Origin header in the request and your API should check if this header is one of the allowed. If it is, then return it as an Access-Control-Allow-Origin header.
If the API is public, it can returns * as Access-Control-Allow-Origin header.
I have some WFS and WMS layers published in geoserver and trying to access from my application. I want to ensure geoserver allows POST request only and block other like GET, PUT etc. I followed the link https://docs.geoserver.org/stable/en/user/security/service.html and changed rest.properties to include only POST method but still GET is allowed. Is there anything missing?
Changing the REST API will only prevent the normal usage of the REST API which will have no effect on WMS and WFS services.
Turning GET access off will prevent the vast majority of WMS clients from accessing your service as a GET request for a getmap endpoint is the standard way to get a WMS map. WFS clients will be less affected as the normal mode of operation is POST. In none of the current OGC services is PUT used so turning that off will have no effect.
Since (pretty much) the whole point of GeoServer is to allow the open and interoperable exchange of data there is no way to turn HTTP methods on or off for OGC services (WMS, WFS etc).
If you are trying to implement some sort of security by obscurity then this will probably not work (for long) and you should set up a proper security system on the getMap or getFeature methods as you need.
If you really (really) must try to cripple the service like this then you can probably do it using nginx or apache as a restricted front end and passing only the "right" requests to GeoServer.
So my colleague ran into this error while attempting to add http referrers to our javascript maps api key. Our app needs to be able to hit the api from our client domains, and there are well over 1200 of them. Has anyone hit this limit, if so, how have you surpassed it?
I have github pages website which makes request to a hosted server which is HTTP and my browser blocks it.
Its assignment for university so I don't really want to pay for HTTPS on the server and I can't use something else for the front-end as I have sent the url to my professor expecting that this is where my web app will be hosted.
Is there anything I can do, which doesn't involve paying that much money?
I encountered this same issue when making API calls. Here's an easy workaround:
Get your api endpoint (for this example, let’s say
http://api.catphotos.io/)
Prepend the CORS API link https://cors-anywhere.herokuapp.com/ to
your link
Make sure to leave the http:// on your endpoint.
Your new link should look like this:
https://cors-anywhere.herokuapp.com/http://api.catphotos.io/
Make your API calls with your new link!
Source: johnalcher.me
According to the GitHub Pages help docs:
HTTPS enforcement is required for GitHub Pages sites created after June 15, 2016 and using a github.io domain.
That means you can't disable the https:// redirect. You could use a custom domain which then leaves the https:// stuff up to you.
Or you could move the stuff from the other server to GitHub Pages, assuming it's not too big.
I have two apps named opentripplanner-webapp and opentripplanner-api-webapp. I had successfully deployed them on local tomcat server. Apps has url as http://localhost:8080/opentripplanner-webapp and http://localhost:8080/opentripplanner-api-webapp. When i deployed apps on appfog , they give me different domains for both apps. The problems is that my apps use ajax request and responses which does not work on cross domains. I am searching for two days to find any solution but didn't find any suitable solution. Kindly guide me.
Thankss
Here's a couple of options for you:
Use JSONP (JSON with Padding). You would have to write your api so it supports this protocol, but it shouldn't prove too difficult.
Create both opentripplanner-webapp and opentripplanner-api-webapp so they support Cross Origin Resource Sharing. This means that your webapp sends an Origin header in the request, and the server responds with an Access-Control-Allow-Origin header, and if they match, the browser accepts the request. This is however not supported by all browsers, although most modern browsers do.
Use a proxy servlet in your opentripplanner-webapp that proxy requests to your API. You can "mount" this servlet at e.g. /api in the webapp, and it will forward all requests to opentripplanner-api-webapp internally. So you would send your AJAX requests to http://webappserver/api instead of http://apiserver. For the browser, this will look like an ordinary same origin request. This will work in all browsers, but might require some more setup.