I currently have a hangout application and I'd like to add some collaborative functionality to it given the realtime API.
Following the realtime API quickstart guide (adding two text areas and a button to authorize with), I've added the relevant code to the hangout XML module(Is this the correct name for this?)
It looks like, however, whenever I click the "authorize" button from within the google hangout instance, the page might refresh (or something?) and a GET request comes back with a: 400 (Bad Request) response.
Is there something I've overlooked?
Perhaps, some documentation I missed?
Is there a better approach to what I'm trying to accomplish?
EDIT: More information on the GET request and response from chrome's javascript console:
https://015isqam6kq3vfnd0h572bpk4rvnem82-a-hangout-opensocial.googleusercon…dgets/ifr?fileId=0B2FRfMTFpkH0S3RDUlhDMWNsbjQ&userId=103345858281489162915 400 (Bad Request) 015isqam6kq3vfnd0h572bpk4rvnem82-a-hangout-opensocial.googleusercontent.com…ets/ifr?fileId=0B2FRfMTFpkH0S3RDUlhDMWNsbjQ&userId=103345858281489162915:1
The page (where the hangout content should be) then shows:
"Missing or malformed url parameter"
The problem lies in the realtime-client-utils.js that the documentation provides.
The idea with the authorization is that upon authorization, it tries to redirect the page via window.location.href and adds parameters to the end of the URL.
Removing the redirect, setting the parameters in the parameters object manually, and restarting the authorization process fixes the problem.
Related
I want to Create a new API app usin Google Apps script and Hello sign API
I have specified the redirect URL as https://script.google.com/macros/s/AKfycbyKw3oLmpqINGsDml281iUbxBboKn950dqVFXNibMfLurxYcRPf/exec and the screenshot is shown below
Also, the code of the apps script file is
function doPost(e) {
return ContentService.createTextOutput("Hello API Event Received.");
}
The documentation says: https://app.hellosign.com/api/eventsAndCallbacksWalkthrough
I get error message as shown like here
Illustation image here
405(http-status-code-405) is "method not allowed", where a incorrect method is used. In this case, ContentService uses a specific pattern of redirection (post-redirect-getwiki), where the POST request to script.google.com is redirected(302) to a one time url at script.googleusercontent.com, to which a GET request should be made.
302 specification did not intend the method to change from POST to GET, but this pattern is very common in the web. But, hellosign-api seems to make another POST request to the one time redirected url at script.googleusercontent.com. There isn't much you could do from apps script to change this behavior. It is possible to change to HtmlService to avoid the redirection, but Hellosign specifically requires you to provide a specific text content as response: Hello API Event Received. This isn't possible with HtmlService.
You could make a feature request/bug fix request to Google to change redirect status to 303, where method change to GET is explicitly specified. Or Make a request to Hellosign to follow 302 redirects with GET request, as that is the most common way, things are done in the web.
References:
Curl redirect preferred method -L
ContentService Redirect
Post redirect get wiki
RFC7231 § 6.4.3
RFC7231 § 6.4.4
Looking at our backend logs, we see that your callback URL is not allowing our POST call to be granted to fetch "Hello API Event Received" response. This can be due to they way your [callback handler is set up][1].
Would you mind taking a look at this similar ask and they way they tackled the POST/Allow header field and let us know how it goes by emailing at apisupport#hellosign.com?
App Script sends 405 response when trying to send a POST request
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405#:~:text=The%20HyperText%20Transfer%20Protocol%20(HTTP,supported%20by%20the%20target%20resource.
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.
Hello I'm doing a PWA and I use Google spreadsheet to store info and send emails.
When I use the app, in the console shows me the "XHR finished loading" message with an url with json data from my entire sheet.
What I want is that people don't have access to that URL or the JSON data, is this possible? or What should I do so that information is not visible in that way?
if your UI can access a URL, anyone could.
You can protect it though, deepening on your server side capability.
If your server side can authenticate the request to have proper credentials, then the protection can be implemented.
But you can't mask anything from UI to prevent users from seeing it. What goes to browser -> user have visibility. PWA wont change that fact.
Today the Facebook oauth login to my website broke. I fired up the debugger and found that parsing the access token was failing. This appears to be because Facebook changed the format of the oauth response. It used to be CGI parameters:
access_token=EAAFO...cBUZD&token_type=bearer&expires_in=5183996
But all of a sudden it appears to be coming over as JSON:
{"access_token":"EAAFO...cBUZD","token_type":"bearer","expires_in":5183996}
The fix in my code looks pretty simple. I just need to change the parser from a CGI parser to a JSON parser and get the same variable that I'm interested in: access_token.
My question is about versioning of this. I don't like it when my site breaks.
Why did Facebook change this? Is this change documented? Is there some sort of versioning on Oauth that I should be using to prevent breakages like this? How do I get notified of future changes to Oauth by Facebook?
The Facebook API upgrade tool does not list any changes that I need to my app for the latest version of the API. In any case, none of the URLs that I'm using for Oauth appear to have a version number embedded in them:
https://www.facebook.com/dialog/oauth
https://graph.facebook.com/oauth/access_token
As WizKid states, it was announced in Facebook Developers Changelog two years ago under the title "[Oauth Access Token] Format". Facebook does have a tool to try to find things that will break, because of API changes, but it didn't alert this one.
You can put API version numbers into Oauth URLs for Facebook. With version numbers, the flow for Facebook login is:
Redirect the user to https://www.facebook.com/v2.9/dialog/oauth with a bunch of required parameters such as your client id, the list of permissions you are requesting, and a return URL.
Facebook lets the user log in, asks them to accept the permissions you requested, and then redirects them back to your site with a "code" parameter
Server-side you contact https://graph.facebook.com/v2.9/oauth/access_token with that code (and some other stuff) as parameters. Facebook responds with a token
Server-side you contact https:///graph.facebook.com/v2.9/me with that token to request information about the user
This is the process that is pretty much documented here: https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow
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]