Information
I am writing a piece of code that will be going up on a web server that I do not have control over. This webserver does not have https. In this code I use the Google Javascript API. When I put in the example code with all the correct API keys and client ID's and whatnot I get a Protocols must match error on an iframe it tries to create to get OAth2 information.
This Protocols must match error is of course caused by the fact that the webserver is http and the OAth2 url it is using is https.
Main Question
Is there any way to use Google API's on a server that does not have https? Is it possible to shut off this Security feature and make the https OAth2 iframe work on a http server?
Note:
The Google API is creating the iframe that is giving me problems.
You shouldn't be creating your own iframe. The Google JS library takes care of this for you.
Related
I have done code for getting list of google analytics accounts
and its works fine with a static clientid
I have used this tutorial: Hello Analytics API: JavaScript quickstart for web applications
The problem is:
I want this functionality for all users means my users logged in from their Google Accounts and they all can see their Google Analytics accounts list.
However I am seeing an error: "origin_mismatch"
I want this without set origin because I can not set origin for all users.
Origin mismatch is normally caused by the Javascript origins incorect in the project on google developers console. Check and make sure that the Javascript origins match the domain from which your requests are coming and to which you are returning the user after login in.
Creating a Google API Console project and client ID
In the Authorized JavaScript origins field, enter the origin for your
app. You can enter multiple origins to allow for your app to run on
different protocols, domains, or subdomains. You cannot use wildcards.
In the example below, the second URL could be a production URL.
http://localhost:8080 https://myproductionurl.example.com
Answer: If you are using JavaScript you need to set the origin for the server that you are returning authentication to. There is no way around this. Just add your server and your users will be able to access it. There is no need to set it for each user. The origin is to your server hosting the script.
I'm writing a Chrome packaged app for diagnosing web services. I want to be able to send a GET request to a URL and look at the headers and data in the response.
My problem is if a users visits a site that has the HSTS header set before using my app, my app will then be unable send GET requests to the http:// URLs for that domain because Chrome will automatically convert the http:// URLs to https:// ones before the request is sent out.
Is there anything at all I can do to prevent this? I've looked into the webrequest API and webview tag but I'm finding nothing that lets me ignore HSTS.
Is it possible to use https://developer.chrome.com/apps/sockets_tcp for this (I would need to be able to support http, https and gzipped data)?
Is there anything at all I can do to prevent this?
Probably not. If you already tested <webview> and it shares the HSTS list with the browser, then the network layer will transparently rewrite this for you.
Is it possible to use chrome.sockets.tcp for this?
Technically, yes, HSTS shouldn't matter for that. Practically, you would need to implement something like wget+SSL+gzip from ground up (in JS, NaCl or a Native Host - but in the latter case you don't really need built-in sockets).
This question already has answers here:
Ways to circumvent the same-origin policy
(8 answers)
Closed 9 years ago.
Trying to access http://www.kawa.net/works/ajax/romanize/romanize.cgi?q=%ED%96%88%EB%8B%A4?&mode=hangulis I only get the error "not allowed by Access-Control-Allow-Origin." I tried Googling this problem and found 2 suggestions, 1 saying I should start Chrome with --allow-file-access-from-files and one saying I should run the page/script on a WAAMP server. Neither of these worked. From what I gather this is due to security reasons. I'm thinking about simply making the $http request go to my server instead where I will have a PHP file that contacts the external URL instead. I guess my question is: is it necessary to do that or is there any way I can do it from the client script?
In an attempt to secure them from cross site scripting attacks, browsers have a built in security feature that prevents javascript from making HTTP (a.k.a AJAX) requests to URLs that are not within the same domain as the originally requested HTML page.
[In particular Chrome restricts any HTTP request when the original HTML file was received from the local file system (i.e. file:///...). As you state you can turn this off with the --allow-file-access-from-files option, or fix it by always loading your page from a web server rather than directly from the file system.]
This turns out to be rather restrictive, since there are a number of valid cases where your javascript application would want to access a web service provided by a 3rd party, which is located on a different domain. In your case you want to access a service that will romanize Korean Hangul characters.
So there are a number of ways around this restriction:
Proxy On Your Servery
The first is to provide a proxy service on your own server that will pass on the request to the 3rd party service and then return it to the browser. The browser is making a request to the same server (i.e. domain) from where it got the original HTML and so is happy.
JSONP
The second is to use a hack, such as JSONP (http://en.wikipedia.org/wiki/JSONP), which involves dynamically adding a new script tag to your HTML that will load up a new JavaScript file and execute it. You have to configure the server to wrap up the data you requested in a call to a function that is provided by your application in the browser to unwrap the data and use it. This is supported by AngularJS $http service using the .jsonp method: http://docs.angularjs.org/api/ng.$http#jsonp. Take a look at the example at the bottom of the page for more information.
CORS
The final, and most sophisticated method is to take advantage of a standard called Cross Origin Resource Sharing (CORS) : http://en.wikipedia.org/wiki/Cross-origin_resource_sharing. This is a standard provided in most browsers now where the browser is able to negotiate with a server hosting a resource on a different domain to agree that certain data can be returned. It needs no changes in the client application, and as such is fully supported for $http, but it requires you to set up the server to be able to respond appropriately. I guess that the service you are referring to is not supporting this. By the way, when CORS is in operation, you will see a number of extra OPTION requests being sent to the server. This is part of the negotiation mechanism and is perfectly normal.
I have been thinking about building a service that would use a similar approach as used by Google CSE - https://developers.google.com/custom-search/docs/js/rendering I have not been able to understand how Google gets around the XSS. Is it because they host the JS file that they are able to write into the DIV? Are they using CORS headers? Please share your inputs if you have experience using this pattern.
It uses a combination of same-origin requests and jsonp. It requests www.googleapis.com/customsearch/v1element and www.google.com/uds via the <script> tag and then those scripts are allowed to request from www.googleapis.com and www.google.com respectively.
For our APP we have a Web App and a API service, On A certain event the Web app polls the api service for the state of the event using Javascript. Both the apps run on a separate HTTPS sub domain and with a self signed certificate(as it is still in alpha). The problem occurs that the polling is aborted because the https api connection is untrusted. Is it some way for the Javascript request to override the untrusted certificate issue?
Is it some way for the Javascript request to override the untrusted certificate issue?
No, it's because of the same origin policy restriction.
In your case I suppose that you have a page hosted on https://foo.bar.com and you are trying to send an AJAX request to https://baz.bar.com which is not allowed.
You may take a look at the following guide which covers the different possibilities to circumvent this restriction. They range from JSONP, server side script bridges, Flash proxies, screen scraping with YQL, ...
No, you have to add the self-signed certificate to your machine/browser's trusted certificate store.
You also have cross-domain origin issues (the different subdomain), which is separate from any certificate issues. If you're already using JSONP, you're fine; but if you're trying to make an XHR request to a different domain, it's not going to work.