I'm trying to make a REST call to a server that has restricted IP access. Therefore, I need to make the call from the client. To do so, I'm trying to use the XMLHttpRequest object within an HTML page loaded in the Google Sheet Sidebar. When I call XHR.send(), however, I always get an exception of the form:
"NetworkError: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'http://some.host.com/'."
Does XMLHttpRequest not work within a google sheet sidebar? Is there an alternative?
Thanks.
When you say that the server you're talking to has "restricted IP access" do you mean only whitelisted IP Addresses can call it? Have you added Google's servers to that whitelist?
This answer provides details:
Google App Engine - list of IP addresses?
As does the FAQ here
https://cloud.google.com/appengine/kb/
(see question "Static IP Addresses and App Engine apps").
I've discovered that making XHR requests from the sidebar is in fact possible.
The problem I was running into was that the browser was blocking the request due to it being a cross-origin request. And, unfortunately, I'm not able to add google to the list of acceptable origins on the server I'm communicating with. So, I may be stuck for my particular use case.
Related
I'm attempting to use Google Sign-In with a firebase function following Google's documentation for Google Sign-In for server-side apps, however I'm running into a redirect_uri_mismatch error (unlike the examples in that documentation, I am using Google's nodejs SDK).
The general flow I'm following is to use google's javascript SDK to request an offlineAccessCode() from a user, send that access code to the server (firebase function), use the access code to get an access token and refresh token, and save the refresh token for later use (this is the flow outlined in the documentation).
It might seem like the meaning of the term redirect_uri_mismatch is self-explanatory, but, as stated in the linked documentation, The Authorized redirect URI field does not require a value. Redirect URIs are not used with JavaScript APIs. That line comes from the section "Step 1: Create a client ID and client secret" and is explaining how to configure the OAuth client credentials. This is the only time in the documentation that a redirect uri is mentioned, and there is no indication that a redirect URI is needed when the server uses the authorization code to fetch an access token.
Indeed, the concept of a redirect uri doesn't seem to make sense in the context of a cloud function using an access code obtained from a client. If the server needs to supply a matching redirect_uri as the javascript client (which doesn't seem to be specified anywhere), I'm not sure what redirect_uri the javascript client uses.
So with that background, does anyone have any idea how to solve this redirect_uri_mismatch error?
Or, more generally, any pointers on implementing this auth flow (my cloud function is written in javascript using the google nodejs sdk). I'm finding it very hard to debug this issue.
Update
I realized that the reason why the error message says redirect_uri_mismatch is because I had been testing various values as redirect_uri. When I remove the (optional) redirect_uri param from the request, the response from google's servers is invalid_request: Missing parameter redirect_uri. So google's making it clear that it wants a redirect URI, even as the documentation seems to imply that it isn't necessary for this auth flow. As a larger problem, the documentation doesn't seem to describe how to set up a redirect URI for an auth flow on a single page app.
Ah HA! The answer (as given in this other S.O. answer) is to set the redirect_uri to "postmessage" on the server (firebase function in my case). I have no idea where this answer came from (i.e. I haven't been able to find it in the docs), but it works.
I am writing a Googlescript to fetch the contents from an internal URL. I want to call that URL through the browser. Currently on calling using fetch, it never hits my internal server.
If your internal server is preventing requests from Apps Script's UrlFetch, you may be able to send your request via HTMLService. However, there are restrictions to this; see HTTP restrictions. For your situation, these restrictions may prevent all such access through Apps Script.
Another (more complicated) approach would be to set up your internal server to allow external access with authorization.
I have this app that uses EWS to access mail, using the standard /EWS/Exchange.asmx SOAP endpoint.
One my user's mail servers is protected by Microsoft Forefront, and the initial HTTP request to
https://server_name/EWS/Exchange.asmx
is redirected (HTTP 302) to:
https://server_name/
CookieAuth.dll?GetLogon?curl=Z2FEWSZ2FExchange.asmx&reason=0&formdir=3
which is an regular HTML page, the point of which, I guess, is to make the user authenticate "manually".
I've not heard about Forefront until today, not sure how to handle it.
Is this normal behavior for Forefront (i.e. it always redirects the initial HTTP request), or is it triggered by something in my app? For example, user-agent?
If it's normal, how am I supposed to get past this page and access /EWS/Exchange.asmx?
If it's triggered by something my app is doing, how can I find out what it is?
My code runs on Android and forms its own XML requests without using any SOAP library. At the transport level, I use Apache HTTP client components. The code works fine with Office 365/Exchange Online, and, according to user reports, "self-hosted" corporate Exchange servers with NTLM.
However, in this case, I'm not even getting an HTTP 401: the HTTP 302 is returned by the very first HTTP roundtrip.
Trying to preemptively authenticate the initial request using Basic authentication didn't make any difference.
The user who reported this issue also mentioned that another EWS based app works, so there must be a solution to it.
I have a general comprehension question about OAuth access token retrieval for a Google Chrome Extension.
I have a popup HTML window in the browser that uses Jquery to request data from the server (a LAMP stack on AWS). The data is presented by PHP scripts which access a MySQL database. All very basic stuff.
I now want to implement a push messaging system using Google Cloud Messaging to alert users of new content that they can check. However I don't really understand where I should request the access token and how to listen for the response. I figure it should be in the PHP scripts but all the Google documentation that I've read states the user has to be present in order to allow access to push messaging. That tells me I should put it in the JavaScript but I feel this is a bad idea because every user could potentially request an access token when I think I only need one every 3000 seconds or so. If my app was completely implemented in PHP I'm sure this would be possible and now I'm worried that splitting it up like this leaves push messaging out of the question. Am I missing a crucial detail or just out of luck?
If the data access you need isn't user-specific, then you're right, there's no good reason to get a separate token for each user. Check out https://developers.google.com/accounts/cookbook/roles/Apps which discusses some options.
While creating the Client_ID I am stuck in these two textboxes (JavaScript Origins and Authorized Redirect URLs) appearing on that PopUp. I am not able to search the internet about those two things.
In a tutorial it was written that we just need to put our hostnames there! But why? What do they actually mean?
Hope I am clear.
Any help would be appreciated.
If you're using the JavaScript client, you need to set a valid JavaScript origin for us to authorize you.
Authorized redirect URIs are the endpoints we're going to call as a callback if you're using 3-legged OAuth 2.0 flow. https://developers.google.com/accounts/docs/OAuth2#webserver illustrates a sequence where Google endpoints pushes a code to your application. Push is done by calling a redirect url with a code query parameter.
http://yoursite/callback?code=[code to exchange]