Google Script doPost accept from a single URL only - javascript

Is there a way that once request received from a specific URL then the doPost will trigger and if incorrect URL will send error response back?

Only the url query parameters sent from the client are accessible server side. The origin header is not accessible server side. So, if you POST to
https://script.google.com/[DEPLOYMENT_UD]/exec/?secret=udggurahtdlDCkyyrxkymjgugsutdoyfitsittjrsktdwqFusuuwUrsDdfgUTT
from client, The secret is accessible from doPost(e) in e.parameter.secret and you may be able to verify it, but you cannot check the Host sending the request.

Related

How to send data with GET method to another domain?

My Javascript file generates a JSON and there are some necessary values which I want to send it to the link www.leaderpush.com/Send/Getjson?Endpoint=endpoint&P256dh=p256dh&Auth=auth
var obj = JSON.parse(t);
var endpoint = obj.endpoint;
var p256dh = obj.keys.p256dh;
var auth = obj.keys.auth;
But I cannot send it to another domain. When I try, the URL that is sent becomes www.AnyDomain.com/www.leaderpush.com/Send...
What is your suggestion?
You need to format the URL correctly.
url = "//www.leaderpush.com/Send/Getjson?Endpoint=endpoint&P256dh=p256dh&Auth=auth";
You need // at the beginning to indicate that the domain name of the URL follows, otherwise it's treated as a filename relative to the current URL.
BTW, this still might not work if the other domain prohibits CORS. You may need to make the request from your server rather than from the client.
Since you have not mentioned the protocol absolutely(HTTP / HTTPS) or relatively(//) in the request URL, the browser treats it as a path and appends the request URL after the origin domain. And the request domain does not seem to support and have valid HTTPS certificate and hence make sure your origin domain is HTTP and the request domain (//www.leaderpush.com) is CORS supported.
Note: Try including crossDomain: true in $.ajax() request header, in case the target server might serve on request to enable cross domain to the client.

Ignore response from a PUT call - javascript

I've a JS (Angular) client that makes a PUT request (REST API) to server and server sends back a large payload that I'm not using in the client currently.
Is there a way to just fire the request and ignore any response that comes back? The main need here is to avoid the data cost incurred by receiving that payload. I've looked at closing the connection once the request is fired, but am not sure if that's the best way to handle this.
If able, I think the only way to change this would be to change the api endpoint to not include a payload from the put request.
I'm assuming you are using angular's http class and using Observables. But even if you aren't, your angular client is going to need to read the response status sent back from the server to determine whether or not the put request was successful or not. In order to read the status, you'll need to response, and unfortunately the full response sent from the server.
You could close the connection right after the request, but as I've mentioned you'll have no way of knowing whether or not the request was successful.
To ignore the request just don't do anything if the request is successful.
If you don't want the request to exist at all then do it on the backend.

Basic authentication with header - Javascript XMLHttpRequest

I am trying to access Adyen test API that requires basic authentication credentials. https://docs.adyen.com/developers/ecommerce-integration
My credentials work when accessing the API page through browser.
But I get an 401 Unauthorized response when trying to access the API with XMLHttpRequest POST request.
Javascript Code
var url = "https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise";
var username = "ws#Company.CompanyName";
var password = "J}5fJ6+?e6&lh/Zb0>r5y2W5t";
var base64Credentials = btoa(username+":"+password);
var xhttp = new XMLHttpRequest();
xhttp.open("POST", url, true);
xhttp.setRequestHeader("content-type", "application/json");
xhttp.setRequestHeader("Authorization", "Basic " + base64Credentials);
var requestParams = XXXXXXXX;
xhttp.send(requestParams);
Result
That screenshot shows “Request Method: OPTIONS”, which indicates the details displayed are for a CORS preflight OPTIONS request automatically made by your browser—not for your POST.
Your browser doesn’t (and can’t) send the Authorization header when it makes that OPTIONS request, and that causes the preflight to fail, so the browser never moves on to trying your POST.
As long as https://pal-test.adyen.com/pal/servlet/Payment/v25/authorise requires authentication for OPTIONS requests, there’s no way you can make a successful POST to it.
The reason is because what’s happening here is this:
Your code tells your browser it wants to send a request with the Authorization header.
Your browser says, OK, requests with the Authorization header require me to do a CORS preflight OPTIONS to make sure the server allows requests with that header.
Your browser sends the OPTIONS request to the server without the Authorization header—because the whole purpose of the OPTIONS check is to see if it’s OK to send that.
That server sees the OPTIONS request but instead of responding to it in a way that indicates it allows Authorization in requests, it rejects it with a 401 since it lacks that header.
Your browser expects a 200 or 204 response for the CORS preflight but instead gets that 401 response. So your browser stops right there and never tries the POST request from your code.
The PAL is a Payment Authorisation API. You never want to call it from a browser. You only want to expose your username and password to send in payments in your backend code.
In Client-side encryption, the encryption is done in the browser. You then send the encrypted data to your own server. On your server you then create a payment authorization request (of which the encrypted data is one of the elements, along side payment amount, etc).
If you would be able to manage to make this run from your browser, your end solution will allow your shoppers to change amounts, currency's, payment meta data etc from the JavaScript layer. This should never be the case.
The authorization is for that reason part of the "Server side" integration part of documentation: https://docs.adyen.com/developers/ecommerce-integration?ecommerce=ecommerce-integration#serverside
Depending on your server side landscape the CURL implementation in your favorite language differs, but most of the time are easy to find.
Kind regards,
Arnoud

Setting Basic authorization details in request headers

In our application we validate user name/password. Once validation is done, credentials are encoded using base64 and then needs to be set at request header for subsequent rest calls.
Need to set below in request header.
Authorization:Basic AQNLzR69OFTNJE8X
In the response setting as below from the java code,
javax.ws.rs.core.Response.status(200).entity("").header("Authorization:","Basic AQNLzR69OFTNJE8X").build();
And in the javascript tried setting as below,
sessionStorage.setItem('Authorization:', 'Basic AQNLzR69OFTNJE8X');
But in the subsequent rest service calls in the same session can see the header request is not set with authorization. Request to provide some pointers on setting the Authorization in javascript, so that it is retained for the entire session.
I think you misunderstand how authentication works (or should work).
You are supposed to send the Authorization header only once during the authentication. If the authentication is successful, the server sends you back a session cookie and your session is marked as authenticated (server-side).
You never send back the content of the header, and you don't have to send it each request.
1) The Authorization header is not automatically added. But the cookie will be automatically sent.
2) You should not send the credential and return them: for security purposes, you want to transport them the less you can.
3) You don't want to store the credential in the sessionStorage, I don't know if this is a secure place for a password (i doubt it), but here, the password is only encoded in B64, and it's reversable. So it's as well as cleartext (which is bad for a password).
Hopes this helps!

Accept server only GET request

I'm making an GET request to my server with AJAX+JS. I'm using it to delete file like this:
delete.php?file_id=0123456789&user=555555
When I send GET request delete.php will delte file with ID 0123456789, but is there a way to accept only request that server makes to itself.
For example if user opens new tab and types www.mysite.com/delete.php?file_id=0123456789 server will decline that request, but if I call it with JS function server will accept the request.
How about using X-XSRF-TOKEN
in combination with Angular JS?
This will require your webapplication to generate and check this token, but your AJAX request will be authenticated.

Categories