GeoServer, OpenLayers3 getGetFeatureInfo cross-site (different approach) - javascript

I think we are all familiar with the cross-site problem, but just in case:
I am using OpenLayers3, GeoServer on port 8080 and Apache on port 80. I render some features on map, and on click I would like to get feature info from WMS. I found the code in OpenLayers3 examples:
var viewResolution = v.getResolution();
var url = wmsSource.getGetFeatureInfoUrl(
evt.coordinate, viewResolution, viewProjection,
{'INFO_FORMAT': 'application/json'});
if (url)
$.get(url, null, function(data)
{
});
Of course I get: XMLHttpRequest cannot load localhost:8080/geoserver/Re... . No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'localhost' is therefore not allowed access.
I was searching the net and found different approaches how to handle this matter. I am asking witch way should I choose. The known facts are: hosting server will be owned, linux or windows unknown (for now). This also means that I don't know if apache or IIS will be used so lets stay opened.
The options I found are:
CORS
JSONP
proxy on apache
URL rewriting IIS 7
What should I choose if hosting web site on apache or IIS? I am not looking the easy way, I am looking for the right way.

Ciao,
I think you have two main options:
Using JSONP OutputFormat for GetFeatureInfo
Using a proxy (with some protection)
I believe 1 as a solution is clean and actually preferrable IMHO if you are developing a specific application and you know that you always be hitting GeoServer or something that supports JSONP. It avoids having to fiddle with proxies and eventual admins.
In the general case 2 is more flexible, although I would recommend to somehow limit what people can do with such a proxy to avoid having a black-hole in your infrastructure.
In our webgis MapStore (based on OL) we use this very lean http-proxy we developed that can be configured to let pass only certain requests (e.g. getfeatureinfo) and only to certain servers if needed.
My 0.02€.

Related

How to handle CORS in a service account call to Google oAuth?

I access a Google calendar using a service account. This means that the owner of the calendar will not be prompted for his authorization.
This works fine in Python, where I make a requests call to https://accounts.google.com/o/oauth2/token with a specific body. This gets me back a token I can use later.
I now need to have an application running in a standalone browser (Chrome - without user interaction) and tried to directly port this call as
fetch('https://accounts.google.com/o/oauth2/token',
{
method: 'POST',
body: JSON.stringify(body),
})
.then(function(res) { return res.json(); })
.then(function(data) { alert(JSON.stringify(data)) })
but I get a reply from Google
Failed to load https://accounts.google.com/o/oauth2/token: No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'http://devd.io' is therefore not allowed access. The
response had HTTP status code 400. If an opaque response serves your
needs, set the request's mode to 'no-cors' to fetch the resource with
CORS disabled.
My limited understanding of CORS (a previous answer was a very good read) is that
No 'Access-Control-Allow-Origin' header is present on the requested
resource
means that it is not present in the response headers, which means that Google does not want me to access its resources via JS when ran from the browser (which points to something else that https://accounts.google.com).
This may be a good idea but I control all elements, from the code to the browser and would like to get that token the same way I get it in a non-browser environment, specifically my working Python code.
How can I tell https://accounts.google.com to send me back a Access-Control-Allow-Origin header which tell my browser that it is OK to accept the call?
You can't.
Client side and server side code need to interact with OAuth in different ways.
Google provide documentation explaining the client side process.
Importantly, part of it involves redirecting to Google's servers instead of accessing them with fetch or XMLHttpRequest.
#Quentin's answer "You can't" is the right one for my question ("how can I force the server to send back the right header").
This is a decision at Google not to provide this header, effectively cutting off any non-interactive applications.
As a solution, I will look at
how to force the browser not to take into account the security mechanisms provided by CORS (there seems to be some ways through extensions or command-line arguments, I will update this answer once I find it)
or write an intermediate layer which will query the data for me and pass them verbatim to the application (this is equivalent, in my case, of just making the query from JS - but it adds an extra layer of code and server)

How to call an API on a different subdomain in Javascript/Jquery

I have 2 sub domains (1 site we host one we don't) - they both have SSL certs.
api.mydomain.co.uk (the domain we do host with a valid ssl cert)
test.mydomain.co.uk (the domain we don't host with an invalid cert but the same domain)
I have an AJAX call from test.mydomain.co.uk to api.mydomain.co.uk. Now obviously I get a No 'Access-Control-Allow-Origin' header is present on the requested resource error which I would expect.
But then a put document.domain = "mydomain.co.uk" in the code on test.mydomain.co.uk.
I thought that would solve the issue (I've never done this before though) as it is a subdomain. So my question is - is the invalid SSL causing a problem, or do I need to do something more like CORS etc?
Yes, you need to config cors on your subdomain to make it behave like an api.
Let's say your page is requested from test.mydomain.co.uk, all ajax calls made to test.mydomain.co.uk are from the same origin, so no CORS config needed.
When you try to make calls to api.mydomain.co.uk, it will see it as another origin, even tough it's the same domain, so you gotta configure it to accept CORS requests. You do it on your NGINX, node, or whatever you're using as a webserver.
Here's how you'd do it on NGINX.
http://enable-cors.org/server_nginx.html

Cross domain Ajax JSON POST support against RESTful WCF service using transportCredentialOnly security

I've posted before on this subject, but after a year of getting on with other things, I've managed to get into a pickle once again. I'll try and give a brief overview of the scenario and the current attempts to make things work:
IIS web server hosting HTML, JS etc. on host: iis.mycompany.com (referred to as foo)
WCF RESTful web services hosted via a Windows Service on host: wcf.mycompany.com (referred to as bar)
The Javascript served from foo works by making RESTful ajax calls (GET or POST depending on the action) to the WCF services on bar, obviously these are cross domain calls as they aren't on the same host.
The Javascript uses the jQuery (1.7.2) framework to manipulate the DOM and perform ajax calls to bar, the expected content type for POSTS is JSON, and the response from GETS is expected to be JSON too (application/json).
Bar has it's WCF services configured using TransportCredentialOnly as the security mode and the transport client credentail type is NTLM, so only authed users to contact the services.
CORS Support has been added to bar's WCF services using an extension to WCF:
http://blogs.msdn.com/b/carlosfigueira/archive/2012/05/15/implementing-cors-support-in-wcf.aspx
We have added additional headers and modfied some that the post already contained based on numerous internet articles:
property.Headers.Add("Access-Control-Allow-Headers", "Accept, Content-Type");
property.Headers.Add("Access-Control-Allow-Methods", "POST, GET, OPTIONS");
property.Headers.Add("Access-Control-Max-Age", "172800");
property.Headers.Add("Access-Control-Allow-Origin", "http://iis.mycompany.com");
property.Headers.Add("Access-Control-Allow-Credentials", "true");
property.Headers.Add("Content-type", "application/json");
Sites giving information on enabling CORS suggest that the Access-Control-Allow-Origin response header should be set to "*" however, this is not possible in our case as we make jQuery ajax calls using the following setup:
$.ajaxSetup({
cache: "false",
crossDomain: true,
xhrFields: {
withCredentials: true
}
});
As it turns out you cannot use "*" for the accepted origin when you are using "withCredentials" in the ajax call:
https://developer.mozilla.org/en/http_access_control
"Important note: when responding to a credentialed request, server
must specify a domain, and cannot use wild carding."
Currently in our development lab, this doesn't matter as we can hard code the requests to the IIS (foo) server URL.
The main problem now appears to be attempting POST requests (GET is working using the above configuration). When the browser attempts the POST process, it first sends an OPTIONS header to the server requesting allowed OPTIONS for the subsequent post. This is where we would like to see the headers we've configured in the CORS Support WCF extension being passed back, however we aren't getting that far; before the response comes back as "401 Unauthorized", I believe this is to do with the transport security binding configuration requesting NTLM, but I'm not sure.
Also, I'm not very experienced with this, but I haven't seen much information about POST using application/json content type as opposed to text/plain when performing cross domain requests.
I know that people will probably suggest JSONP as the one true solution, I'm not against different approaches, indeed I encourage anyone to suggest best practices as it would help others reading this question later. However, please attempt to answer the question before suggestion alternatives to it.
Many thanks in advance for anyone who contributes.
peteski
:)
UPDATE:
It appears that Chrome (20.x.x) doesn't suffer the problem of not negotiating NTLM to retrieve the OPTIONS header response from the server, but Firefox (13.0.1) does.
We've also noticed that someone has already posted a bug up on the Firefox forum, which we've added information to:
http://bugzilla.mozilla.org/show_bug.cgi?id=751552
Please vote for this bug to be fixed on the bugzilla site!
Using the following code, we can watch the network trace to see Firefox failing and Chrome working fine:
var url = "http://myWebServiceServer/InstantMessagingService/chat/message/send";
var data = '{ "remoteUserUri" : "sip:foo.bar#mydomain.com", "message" : "This is my message" }';
var request = new XMLHttpRequest();
request.open("POST", url, true);
request.withCredentials = true;
request.setRequestHeader("Content-Type", "application/json");
request.send(data);
console.log(request);
On a separate note, IE8 doesn't support the XMLHttpRequest for cross domain calls, favouring it's own magical XDomainRequest object, so we've got some work to do in changing the client side code to handle IE8 vs the world cases. (Thanks IE8).
/me crosses fingers that Mozilla fix the Firefox bug.
UPDATE 2:
After some digging it appears that IE8's XDomainRequest cannot be used to make cross domain requests where NTLM must be negotiated, this basically means that the security on our WCF binding can't be used thanks to limitations in a web browser.
http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx
"No authentication or cookies will be sent with the request"
So, I guess we've taken this as far as it is going to go for now.. It looks like we're going to have to create our own custom token authentication and pass it across to the WCF service in a cookie, or in IE8's case, POST it with the JSON. The WCF service will then have to handle decrypting the data and using that instead of the ServiceSecurityContext.Current.WindowsIdentity we previously had access to with NTLM auth.
I know you said you would rather have the problem itself addressed, but you may consider using a "reverse proxy."
I don't know what technologies you are using, but we use Apache web server and have a Java RESTful API running on a different server that required authentication. For a while, we messed with JSONP and CORS, but were not satisfied.
In the end, we setup an Apache Reverse Proxy and it worked miracles. The web browser believes it is communicating with its own domain and acts appropriately. The RESTful API doesn't know it is being used via a proxy. Therefore, everything just works. And Apache does all the magic.
Hopefully, all web servers have a feature like Apache's reverse proxy.
Here is some documentation on the feature: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
All we had to do is ensure the mod_proxy module was installed, then add the following lines to our Apache config file:
ProxyPass /restapi http://restfulserver.com/restapi
ProxyPassReverse /restapi http://restfulserver.com/restapi
Then restart the web server and voila!

How to tackle same origin policy in Mozilla

I am implementing YUI autocomplete in my project. I have created a web service which provides autocomplete suggestions. All things are working fine when I deploy my application and web service on same machine. But when I deploy the web service on different machine then it do not work in Firefox (But it do work in IE). I think because of same origin policy its not working in Mozilla.
Here is my autocomplete code
<script type="text/javascript">
YAHOO.example.BasicRemote = function() {
// Using an XHRDataSource to connect to web service
var oDS = new YAHOO.util.XHRDataSource("http://host_other_than_my_machine/i2b2/services/AutocompleteService/getCodes");
// Set the responseType as XML
oDS.responseType = YAHOO.util.XHRDataSource.TYPE_XML;
// Define the schema of the delimited results
oDS.responseSchema = {
resultNode: 'code',
fields: ['value']
};
// Enable caching
oDS.maxCacheEntries = 0;
// Instantiate the AutoComplete
var oAC = new YAHOO.widget.AutoComplete("myInput", "myContainer", oDS);
return {
oDS: oDS,
oAC: oAC
};
}();
</script>
My questions are
1) Is same origin policy is actual problem ? If yes then Is IE not bound to same policy as my code is working in IE ?
2) How to get rid of it ? I know some php code can be used to redirect request but how I can use it here ?
~Ajinkya.
Your problem is probably with the origin of the AJAX request, you should look into this: Cross Origin Request Security.
Basically, for apache you will need to add the following to the "host_other_than_my_machine" .htaccess file:
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://trusted.site"
</IfModule>
Of course, replacing "http://trusted.site" with the domain you will be making the requests from.
Edit: If you need to allow access for multiple remote domains you could simply use:
Header set Access-Control-Allow-Origin "*"
This should usually not be a security concern, but be sure to thoroughly consider your specific case, ie if you are making sensitive information available through AJAX responses.
Used PHP proxy provided by Yahoo and redirected all requests to it.
http://developer.yahoo.com/javascript/howto-proxy.html

secure xmlhttprequest from nonsecure page

I want to make an XMLHttpRequest to a secure uri (https://site.com/ajaxservice/) from javascript running inside a nonsecure page (http://site.com/page.htm). I've tried all kinds of nutty stuff like iframes and dynamic script elements, so far no go. I know I am violating 'same origin policy' but there must be some way to make this work.
I will take any kind of wacky solution short of having the SSL protocol written in javascript.
That won't work by default due to the same origin policy, as you mentioned. Modern browsers are implementing CORS (Cross-Origin Resource Sharing) which you could use to get around this problem. However this will only work in Internet Explorer 8+, Firefox 3.5+, Safari 4+, and Chrome, and requires some server-side work. You may want to check out the following article for further reading on this topic:
Cross-domain Ajax with Cross-Origin Resource Sharing by Nicholas C. Zakas
You can also use JSONP as Dan Beam suggested in another answer. It requires some extra JavaScript work, and you may need to "pad" your web service response, but it's another option which works in all current browsers.
You can't circumvent cross-domain origin with XHR (well, only in Firefox 3.5 with user's permission, not a good solution). Technically, moving from port 80 (http) to 443 (https) is breaking that policy (must be same domain and port). This is the example the specification itself sites here - http://www.w3.org/Security/wiki/Same_Origin_Policy#General_Principles.
Have you looked into JSONP (http://en.wikipedia.org/wiki/JSON#JSONP) or CSSHttpRequests (http://nb.io/hacks/csshttprequest)?
JSONP is a way to add a <script> tag to a page with a pre-defined global callback across domains (as you can put the <script>s src to anywhere on the web). Example:
<script>
function globalCallback (a) { /* do stuff with a */ }
And then you insert a <script> tag to your other domain, like so:
var jsonp = document.createElement('script');
json.setAttribute('src','http://path.to/my/script');
document.body.appendChild(jsonp);
</script>
And in the source of the external script, you must call the globalCallback function with the data you want to pass to it, like this:
globalCallback({"big":{"phat":"object"}});
And you'll get the data you want after that script executes!
CSSHttpRequests is a bit more of a hack, so I've never had the need to use it, though feel free to give it a try if you don't like JSONP, :).
You said you would take anything short of having the SSL protocol written in JavaScript... but I assume you meant if you had to write it yourself.
The opensource Forge project provides a JavaScript TLS implementation, along with some Flash to handle cross-domain requests:
http://github.com/digitalbazaar/forge/blob/master/README
Check out the blog posts at the end of the README to get a more in-depth explanation of how it works.

Categories