Trouble Writing to a Google Sheet

[FourthWorld]

How is an unauthenticated agent able to modify the document?

If you can modify it without authenticating, couldn't anyone else?

[simon.schvartzman]

@FourthWorld you have a very good point.

Not sure if your question refers to the method that was shared or to the suggestion using Google APIs (or both)

In the first case the Google Form (which is the origin of the process) is open, meaning that anyone with the link can submit a response and therefore there is no authentication required. In our case the Livecode script is the one submitting a response.

In the case of using Google APIs there is a need to be authenticated but I guess the project owner could use her/his Oauth key as a parameter to the library to be developed. Just brainstorming

It is going to be really interesting to see if/how the whole idea develops

[FourthWorld]

Thanks, Simon. I missed the part about the non-API solution being dependent on a form already world-writable.

I can't imagine a scenario in which an app would depend on data whose integrity is subject to the whims of nefarious passersby, but if that's the scenario the OP has it would seem a simple solution.

[egolombek]

Thank you... that connects to my other post about using APIs. I guess it's my next step in this process...

[mrcoollion]

I have been doing some testing with the Google Sheet API..
It ain't simple ...

[Mikey]

Just a reminder that when LC decided to deprecate mergGoogle, they also OSS'd it, so if you want to make a run at wrapping the newer C libs, the original is in a repo https://github.com/macMikey/merggoogle.
I had been hoping that someone would answer my RFQ for implementing the REST API in LC but that didn't happen, so I decided to get a library written in another tool that we use.
The Oauth piece was the PITA. It was a lot of slogging. The rest of it has been pretty straightforward. The learning and reference materials are extensive, and the examples are generous. The test environment gives you the full URLs and the output shows you exactly what you're going to get.
Everything is in JSON, both directions, so it doesn't seem complicated, so far.
Don't forget to refresh the oauth access token once per hour. If you can do that, you should be golden.
What I would suggest is this:
1. Look at the LC Dropbox Library. Monte did a really nice job with taking Gerard's dropbox v2 library and making it asynchronous and generally optimizing it. It's a great read, full of great ideas. That should give you some ideas on some general things you should do to skin this cat - how to make it modular, how to make wrapping the API easier, etc.
2. Let me know when you get the authorization working. The rest of the API is literally cake. It's not even that the oauth piece was that hard, it's just a lot of crap you have to do. I would suggest starting with figuring out how to get the JWT built and encrypted.

[FourthWorld]

AFAIK LC 9's OAuth2 lib works on every platform but Linux.

http://lessons.livecode.com/m/2592/l/67 ... h2-library

[Mikey]

oauth2 isn't oauth2. every site is different, and what i see in the library doesn't look like the workflow for a google service account. while there is a workflow for webservers that uses a refresh token, the google cloud API does not use one for service accounts. You have to change the connection type to use the webserver workflow. i also don't see any of the jwt generation that google uses for service accounts.
if i get some time i might play with it next week, or if someone has the oauth2 workflow going with google, that would save fighting through it, and then we can get down to implementing the REST API in LC.

[Mikey]

By the way, if you want to save yourself half-a-minute, here are the references to the different oauth2 issues with google
https://developers.google.com/identity/protocols/oauth2
https://developers.google.com/identity/ ... t#httprest
https://support.google.com/a/answer/162106

On the last one, the reasons to use domain-wide delegation are several fold, but the most important one is that you don't have to have your server app have someone hitting the console to reauthorize all the time because the service account can operate headless.

[FourthWorld]

Does this help?
https://forums.livecode.com/viewtopic.p ... 0&p=174188

[Mikey]

hmmm. nope. it's throwing a couple of errors for me.
i'll have a look at it next week.

[Mikey]

ok, i see what's happening, now.
the workflow is different because the use case is different.
the lc oauth library is user/client-driven, i.e. one where user interaction is necessarily part of the process (not built for headless or server-to-server). i was wondering why the lc oauth library was so short.
we are doing server-to-server applications, so the authentication process is (very) different. you can try the calendar stack to see if it works for you. you would have to go through the oauth setup for your app, and then test it https://developers.google.com/identity/protocols/oauth2. make sure you read the entire document, because it is organized with a brief explanation at the top and then more detail on each step below.
after that the code for manipulating the spreadsheet is going to be similar to what we are using for server-to-server.
the two endpoints that will get you up the fastest are get values and set values. there are samples of getting values and setting values.