I have a situation in which I am trying to use a single Http-Only authentication cookie across sub-domains.
I have verified that the authenticate response sets the cookie, I see the domain in the response as .mydomain.com. If I open the cookie viewer in Chrome (Settings -> Show Advanced Settings -> Content Settings -> All cookies and site data ...) I see my auth cookie stored under mydomain.com (no leading '.', not sure why).
However, when I do a simple get request back to my auth server to get a full authorization token, the authentication cookie is not sent:
//Sent from http://app.mydomain.com
$.get('http://auth.mydomain.com', null, function(fullAuthorizeTok) {});
Is it impossible to send cookies even in a cross sub-domain request like this?
I'm using an Http-Only authentication cookie to protect against XSS attacks and then using an authorization token manually submitted on potent operations to protect against XSRF attacks. This bit is the part where the app has already authenticated and is requesting an authorization token from the server, and I would prefer this to be possible from client JS.
The request must be explicitly cross-domain for the cookies to be sent. I thought the browser would implicitly send cookies across sub-domains if they were shared between the said sub-domains, but it is not so. The request needs to look like this:
$.ajax({
url: 'http://auth.mydomain.com',
method: 'GET',
crossDomain: true,
data: {},
xhrFields: {
withCredentials: true
},
success: function (tokenStr) {
//Do Stuff
},
error: function (jqXHR, type, exception) {
alert('Oh Dear.');
}
});
And of course the response should include the appropriate CORS headers.
As a side note. This does not work across domains if they don't share the same parent domain. So you can send a cookie from 'app.mydomain.com' to 'auth.mydomain.com', but not to 'auth.mydomain2.com'.
Related
I want to post my contact form to my google script that will send an e-mail to me. I use the following code:
var TO_ADDRESS = "example#gmail.com"; // where to send form data
function doPost(e) {
var callback = e.parameter.callback;
try {
Logger.log(e); // the Google Script version of console.log
MailApp.sendEmail(TO_ADDRESS, "Contact Form Submitted",
JSON.stringify(e.parameters));
// return json success results
return ContentService
.createTextOutput(callback+
JSON.stringify({"result":"success",
"data": JSON.stringify(e.parameters) }))
.setMimeType(ContentService.MimeType.JSON);
} catch(error) { // if error return this
Logger.log(error);
return ContentService
.createTextOutput(callback+JSON.stringify({"result":"error",
"error": e}))
.setMimeType(ContentService.MimeType.JSON);
}
}
When i try to post to the google script url, i get the following error:
Access to XMLHttpRequest at
'https://script.google.com/macros/s/~~myscriptid~~/exec' from origin
'http://localhost:4200' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource.
I have no clue how to add the CORS-filter to my google script.
I know the script is working i have tested it with this plugin:
https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi
Late answer, but totally working...
To pass data from appscripts to another website, just use mime type JAVASCRIPT on appscripts side, like so:
doGet(e){
return ContentService
.createTextOutput(e.parameter.callback + "(" + JSON.stringify(YOUR OBJECT DATA HERE)+ ")")
.setMimeType(ContentService.MimeType.JAVASCRIPT);
}
And on the front end access it as:
<script>
var url = "https://script.google.com/macros/s/AKfy*****ACeR/exec?callback=loadData";
// Make an AJAX call to Google Script
jQuery.ajax({
crossDomain: true,
url: url,
method: "GET",
dataType: "jsonp"
});
// log the returned data
function loadData(e) {
console.log(e);
}
</script>
This works without any CROB/ CROS headache
After a lot of hard work, the only solution which worked for me:
In Google Apps Script
function doPost(e) {
return ContentService.createTextOutput(JSON.stringify({status: "success", "data": "my-data"})).setMimeType(ContentService.MimeType.JSON);
}
In JavaScript
fetch(URL, {
redirect: "follow",
method: "POST",
body: JSON.stringify(DATA),
headers: {
"Content-Type": "text/plain;charset=utf-8",
},
})
Note the attribute redirect: "follow" that is very important;
Quick answer
You (frontend developer) can't fix cors error from remote server. Only the owner of the remote server (google app script server) could do it.
Workaround 1 (GET)
Use only GET method in app script. Get method will not throw CORS errors, no matter where you consume it from: csr, spa, frontend, react, angular, vue, jquery, pure javascript, etc
Workaround 2 (Backend)
If you are in the backend server (java, php, c#, node, ruby, curl, etc) not in the frontend (browser, react, angular, vue), you could consume any method published on google apps script.
CORS don't affect when the consumption is at the backend layer
So if only use get endpoints are not an option for you, you could use another server language (java, nodejs, php, etc) to consume the Post google app script, and return that information to your web
Explanation
Let's imagine this script with 02 methods deployed as web in google app script
function doGet(e) {
var response = {
"code": 200,
"message": "I'm the get"
};
return ContentService.createTextOutput(JSON.stringify(response)).setMimeType(ContentService.MimeType.JSON);
}
function doPost(e) {
var response = {
"code": 200,
"message": "I'm the post"
};
return ContentService.createTextOutput(JSON.stringify(response)).setMimeType(ContentService.MimeType.JSON);
}
and url like this after the deployment:
https://script.google.com/a/utec.edu.pe/macros/s/AKfy\*\*\*\*\*\*eo/exec
In the backend
You could consume the POST and GET methods without any problems with any language: java, nodejs, python, php, c#, go , etc and/or with any http client like postman, insomnia, soapui, curl, etc
In the frontend (js in the browser)
I was not able to consume the POST method. I tried with jsonp and other crazy attempts and the error was the same:
Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at
https://script.google.com/a/utec.edu.pe/macros/s/AKfy***A4B***eo/exec?foo=bar
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
So for any reason, the google server don't allow us to use POST operations from javascript side (2021)
In the frontend : GET Method
Only GET method worked for me. I will assume that google configuration at server layer has some CORS permission only for GET method.
The following ways worked for me, from a simple js to an advanced frameworks like react, vue or angular:
axios
const axios = require('axios');
axios.get('https://script.google.com/a/acme.org/macros/s/AKfy***A4B***eo/exec').then(resp => {
console.log(resp.data);
});
$.getJSON
$.getJSON('https://script.google.com/a/acme.org/macros/s/AKfy***A4B***eo/exec?foo=bar', function(result) {
console.log(result);
});
XMLHttpRequest
var xmlhttp = new XMLHttpRequest();
var theUrl = "https://script.google.com/a/acme.org/macros/s/AKfy***A4B***eo/exec?foo=bar";
xmlhttp.open("GET", theUrl);
xmlhttp.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
xmlhttp.send();
CORS : Cross-origin resource sharing
A lot of developers don't understand what is CORS. It is not easy to understand. Commonly the developer fix the error at the server layer and don't invest time (or don't let him) to understand what CORS is:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://portswigger.net/web-security/cors
https://youtu.be/4KHiSt0oLJ0
If you don't have time, check my definition, extreme summary bordering on wrong:
CORS is a protection offered by trusted browsers to avoid that a web acme.com can load in the background(ajax/js) an http resource from another domain like hacker-api.com/foo/bar
But if acme.com and hacker-api.com/foo/bar are developed by you and/or hacker-api.com/foo/bar is designed to be consumed by any web of the world, you could fix it at server layer
How to fix CORS errors?
Are very common and simple to control with a few lines in the server if the server belongs to us, but since we don't have control over the server(google), we can not do anything at this layer.
Here some samples of CORS configuration to allow consumption from webs is the backend server belongs to you:
java sample:
//only http://acme.com could consume my api
#CrossOrigin("http://acme.com")
#RequestMapping(method = RequestMethod.GET, "/{id}")
public Account retrieve(#PathVariable Long id)
nodejs sample:
//only http://localhost:8080 could consume my api
var corsOptions = {
origin: 'http://localhost:8080',
optionsSuccessStatus: 200 // For legacy browser support
}
app.use(cors(corsOptions));
//any web could consume my api
origin : "*"
I ran into the same issue while trying to create an application that logs data and retrieves log sections to/from a google sheet through Google Apps Script using Get and Post requests.
I did find a solution that may or may not be helpful to some people.
From the Google Docs:
There are two types of CORS requests: simple and preflighted. A simple
request can be initiated directly. A preflighted request must send a
preliminary, "preflight" request to the server to get permission
before the primary request can proceed. A request is preflighted if
any of the following circumstances are true:
It uses methods other than GET, HEAD or POST. It uses the POST method
with a Content-Type other than text/plain,
application/x-www-form-urlencoded, or multipart/form-data. It sets
custom headers. For example, X-PINGOTHER.
All I did was change the content type of my Get and Post requests
var request = new window.XMLHttpRequest();
request.open(opts.method, opts.url, true);
request.setRequestHeader("Content-Type", "text/plain");
And within the google script, parse to JSON to be used
function doPost(e) {
const d = JSON.parse(e);
...
As far as I understood you have application to be run on custom domain. And it should access script on google cloud.
The bad news: there are no way to skip CORS check on your application side(until request is simple that I believe is not your case).
You should specify Access-Control-Allow-Origin on Google Cloud side:
Cloud Storage allows you to set CORS configuration at the bucket level only. You can set the CORS configuration for a bucket using the gsutil command-line tool, the XML API, or the JSON API. For more information about setting CORS configuration on a bucket, see Configuring Cross-Origin Resource Sharing (CORS). For more information about CORS configuration elements, see Set Bucket CORS.
You can use either of the following XML API request URLs to obtain a response from Cloud Storage that contains the CORS headers:
storage.googleapis.com/[BUCKET_NAME]
[BUCKET_NAME].storage.googleapis.com
If this does not help for any reason you will need to get your own server working as a proxy:
your client application <-> your backend that returns Access-Control-Allow-Origin <-> google cloud
Well after several attempts, I was able to send the data through a web app form in angular 8.
The solution is simple, within "HttpClient.post" you can enter a third parameter to establish an HTTP connection header this for "https://script.google.com" may not be correct and will end with an http connection failed by CORS security.
Just don't add the HTTP connection header as the third parameter of HttpClient.post
const object = {
title: 'Prices',
phone: '999999999',
full_name: 'Jerson Antonio',
email: 'test#example.com',
message: 'Hello, .......'
};
return this.http.post(this.API_REST_FORM, JSON.stringify(object));
In App script always use New deployment to deploy the script.
Otherwise it will use old script and you will get CORS error
The CORS error is most probably caused by a fatal error in your Google Apps Web App script. In this case the Google error handling system displays a human-readable HTML page that does not contain CORS headers.
In my case I got the following error page:
I am attempting to retrieve some data from a 3rd party domain. When I enter the request url. I am able to see the data I requested. But when I attempt to make a call using ajax (to a different domain), it returns the error message. Why am I not able to retrieve the data? Might it have something to do with cross-domain policy and not using jsonp? Here is my code:
<script>
$(document).ready(function() {
$.ajax ({
type: 'GET',
url: 'https://crm.zoho.com/crm/private/json/Potentials/searchRecords?authtoken=xxx&scope=crmapi&criteria=(((Potential%20Email:test2#email.com))&selectColumns=Potentials(Potential%20Name)&fromIndex=1&toIndex=1',
dataType: 'json',
success: function(test) {
alert(JSON.stringify(test));
},
error: function(test) {
alert(JSON.stringify(test));
}
});
});
</script>
Because the request that you has send is blocked by the browser. When you perform a request using an object XmlHttpRequest and obviously javascript, the browser applied cross-domain policy, defined in WC3, and thus verify in url the origin and target domain (protocol, host and port), if those elements are in different domain (i.e. host and port), then the request never comes out from browser (a.k.a User Agent). You can use jsonp to "break" or "jump" this policy, simply is a tag "script" with a resource (src) defined in a different domain using a parameter called "jsonCallback=?" added in query string, who really receives the data in format json. This is more ugly and have a security risk, therefore never be used.
The other method is to use and enable a "technique" (is more than that) known like "CORS" (Cross Origin Request Sharing), where the client (browser) and server (resource at different domain), send, exchange and negotiate an Http Headers to secure that who send and who received are authorized to exchange information. The basics steps to realize CORS is:
Explicity define in client (ajax-jquery) that CORS will be used in request, specifying CrossDomain:true. This will enable HTTP Headers defined in CORS
Specify in the HTTP Server, a HTTP Header indicating the Domain Source that have permissions to call a resource hosted in server. The most general header can be defined like: Access-Control-Allow-Origin , with value asigned a domain, like "*" (all domain authorized) (Access-Control-Allow-Origin, *)
In some Browsers, sometimes they send a http header request called "preflight request", is like a discover via to know if the server is prepared to recieve cross-origin request. This Http Header contains a "Method HTTP" value or "Verb HTTP" (like PUT,POST,GET,DELETE) assigned to "OPTIONS", then the server must be configured too to recieve HTTP Headers with Method "OPTIONS", and therefore allow methods http like PUT, DELETE,POST or GET. In generals terms the server must have this headers when in the request had a method HTTP "OPTIONS":
Access-Control-Allow-Methods , "POST, PUT, DELETE, GET, OPTIONS"
Access-Control-Allow-Headers, ", "Content-Type, Accept"
Finally, the client (ajax) will recieve the data from the server.
This sounds a little confusing and the steps are few, sorry that not put a code like examples, but, really CORS is not hard to understand.
I hope this will help.
References from Mozilla:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
This show what is CORS and you can use in configuration server:
http://enable-cors.org/
I'm trying to receive data from SendGrid API
$.ajax({
type:'GET',
url:"https://sendgrid.com/api/bounces.get.json",
data: {api_user:'username',api_key:'userkey',date:1},
success: function(data){
console.log(data)
},
crossDomain: true,
dataType: 'jsonp',
error:function(a,b,c){
console.log(a);
}
});
Console shows:
Object { readyState=4, status=200, statusText="success"}
parsererror
Error: jQuery17208301184673423685_1374648217666 was not called
Where is the bug or issue ?
The issue is that SendGrid does not support jsonp.
Unfortunately, switching to plain JSON will not work either, as SendGrid has no CORS headers and browsers will not allow you to access the pages. In short you cannot make AJAX requests dorectly to SendGrid.
However, generally this is for the better as all SendGrid endpoints require authentication and having your username and password in an AJAX request would allow users to take them and then use them to send email.
To get these stats on the frontend, you'll need a server to get them and output them on your domain or a domain with CORS allowances.
Here comes a one click solution!
Deploy your instance of SendGrid Proxy to Heroku
Use {your-sendgrid-proxy}.herokuapp.com instead of api.sendgrid.com
Done (Really)
How it works:
It creates a node powered http proxy using express-http-proxy
It adds needed headers such as Authorization and Content-Type
It overrides Access-Control-Allow-Origin to * to make your browser CORS warning free
See how the magic is working. Feedback is welcome!
We are working on a RESTful Webservice with AngularJS and Java Servlets.
When the user logs in, our backend sends a "Set-Cookie" header to the frontend. In Angular we access the header via $cookies (ngCookie - module) and set it.
Now that the user is logged in he can for example delete some stuff. Therefore the frontend sends a GET request to the backend. Because we work on different domains we need to set some CORS Headers and Angular does an OPTIONS request before the actual GET request:
OPTIONS request:
GET request
We do this in Angular via $http module, but it just won't send the cookie, containing JSESSIONID.
How can I enable Angular to send cookies?
In your config, DI $httpProvider and then set withCredentials to true:
.config(function ($httpProvider) {
$httpProvider.defaults.withCredentials = true;
//rest of route code
})
Info on angularjs withCredentials: http://docs.angularjs.org/api/ng.$http
Which links to the mozilla article: https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-US&redirectslug=HTTP_access_control#section_5
$http.get("URL", { withCredentials: true })
.success(function(data, status, headers, config) {})
.error(function(data, status, headers, config) {});
Another thing to keep in mind: You need to have 3rd party cookies enabled. If you have it globally disabled in Chrome, click on the "i"-Symbol to the left of the domain name, then cookies, then "blocked" and unblock the target domain.
I have a web application for iPhone, which will ultimately run within a PhoneGap application - but for now I'm running it in Safari.
The application needs to access tweets from Twitter friends, including private tweets. So I've implemented OAuth using the Scribe library. I successfully bounce users to Twitter, have them authenticate, then bounce back.
At this point the web app has oAuth credentials (key and token) which it persists locally. From here on I'd like it to user the Twitter statuses/user_timeline.json method to grab tweets for a particular user. I have the application using JSONP requests to do this with unprotected tweets successfully; when it accesses the timeline of a private Twitter feed, an HTTP basic authentication dialog appears in the app.
I believe that I need to provide the OAuth credentials to Twitter, so that my web application can identify and authenticate itself. Twitter recommends doing so through the addition of an HTTP Authorization header, but as I'm using JSONP for the request I don't think this is an option for me. Am I right in assuming this?
My options therefore appear to either be putting the oAuth credentials as query-string parameters (which Twitter recommends against, but documentation suggests still supports); or proxying all the Tweets through an intermediate server. I'd rather avoid the latter.
I access the Twitter API using URLs of the form
http://api.twitter.com/1/statuses/user_timeline.json?user_id=29191439&oauth_nonce=XXXXXXXXXXX&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1272323042&oauth_consumer_key=XXXXXXXXXX&oauth_signature=XXXXXXXXXX&oauth_version=1.0
When user_id is a public user, this works fine. When user_id is a private user, I get that HTTP Basic Auth dialog. Any idea what I'm doing wrong? I'm hoping it's something embarrassingly simple like "forgetting an important parameter"...
The oAuth stanza needs to be exact, as per http://dev.twitter.com/pages/auth#auth-request - I ended up building an Authorization: header that I could first check with curl.
I built it using the really helpful interactive request checker at http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/
Here's a friends API request for a protected user:
curl -v -H 'Authorization: OAuth realm="https://api.twitter.com/1/friends/ids.json", oauth_consumer_key="XXXXXXXXXXXXXXXX", oauth_token="XXXXXXXXXXXXXXXX", oauth_nonce="XXXXXXXXXXXXXXXX", oauth_timestamp="1300728665", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_signature="XXXXXXXXXXXXXXXX%3D"' https://api.twitter.com/1/friends/ids.json?user_id=254723679
It's worth re-iterating that as you've tried to do, instead of setting the Authorization header via e.g. jquery's beforeSend function, that for cross-domain JSONP requests (which can't add HTTP headers) you can make oAuth requests by putting all the relevant key/value pairs in the GET request. This should hopefully help out various other questioners, e.g
Set Headers with jQuery.ajax and JSONP?
Modify HTTP Headers for a JSONP request
Using only JQuery to update Twitter (OAuth)
Your request looks like it has a couple of problems; it's missing the user's oauth_token plus the oauth_signature doesn't look like it has been base64 encoded (because it's missing a hex encoded = or ==, %3 or %3D%3D respectively).
Here's my GET equivalent using oAuth encoded querystring params, which you can use in a cross-domain JSONP call:
https://api.twitter.com/1/friends/ids.json?user_id=254723679&realm=https://api.twitter.com/1/friends/ids.json&oauth_consumer_key=XXXXXXXXXXXXXXXX&oauth_token=XXXXXXXXXXXXXXXX&oauth_nonce=XXXXXXXXXXXXXXXX&oauth_timestamp=1300728665&oauth_signature_method=HMAC-SHA1&oauth_version=1.0&oauth_signature=XXXXXXXXXXXXXXXX%3D
I was struggling with similar problem of making JSONP requests from Jquery, the above answer helped just to add what I did to achieve my solution.
I am doing server to server oauth and then I send oauth token, secret, consumer key and secret (this is temporary solution by the time we put a proxy to protect consumer secret). You can replace this to token acquiring code at client.
Oauth.js and Sha1.js download link!
Once signature is generated.
Now there are 2 problems:
JSONP header cannot be edited
Signed arguments which needs to be sent as part of oauth have problem with callback=? (a regular way of using JSONP).
As above answer says 1 cannot be done.
Also, callback=? won't work as the parameter list has to be signed and while sending the request to remote server Jquery replace callback=? to some name like callback=Jquery1232453234. So a named handler has to be used.
function my_twitter_resp_handler(data){
console.log(JSON.stringify(data));
}
and getJSON did not work with named function handler, so I used
var accessor = {
consumerSecret: XXXXXXXXXXXXXXXXXXXXXX,
tokenSecret : XXXXXXXXXXXXXXXXXXXXXX
};
var message = { action: "https://api.twitter.com/1/statuses/home_timeline.json",
method: "GET",
parameters: []
};
message.parameters.push(['realm', "https://api.twitter.com/1/statuses/home_timeline.json"]);
message.parameters.push(['oauth_version', '1.0']);
message.parameters.push(['oauth_signature_method', 'HMAC-SHA1']);
message.parameters.push(['oauth_consumer_key', XXXXXXXXXXXXXXXX]);
message.parameters.push(['oauth_token', XXXXXXXXXXXXXXX]);
message.parameters.push(['callback', 'my_twitter_resp_handler']);
OAuth.completeRequest(message, accessor);
var parameterMap = OAuth.getParameterMap(message.parameters);
Create url with base url and key value pairs from parameterMap
jQuery.ajax({
url: url,
dataType: "jsonp",
type: "GET",
});