I know that the Google Drive API allows for drive integration with Chrome Apps, but what about extensions? Can/How do I use the Drive API in a chrome extension? For example I want an extension that will have a popup that list a user's docs, how do I get access to their drive box?
I know it starts with authentication, but I'm not sure how to do that either.
Regarding authentication, chrome.identity is the place to start.
Taking a (not so) quick look at the GDrive App I didn't really spot any app-specific stuff (i.e. something not available to extensions). So, I would certainly start by trying to "port" the GDrive App to an extension.
There is, also, this tutorial I totally recommend about Building Apps with AngularJS, which actually walks you through building the GDrive App. It is super cool, has a fairly detailed explanation regarding how to set up authentication related stuff (of course, you'll have to slightly adapt that to apply to an extension) and you can just ignore the AngularJS-related stuff (if you are not interested - although AngularJS is super cool too).
Recommended road-map:
Read the docs about chrome.identity, to gain some understanding regarding the API(*).
Study the tutorial, to understand the basic concepts of the GDrive App.
Study the source code of the GDrive App, to get filled in on the implementation details not covered in the tutorial.
Port the GDrive App to a Chrome Extension. (Feel free to come back here on SO if you stumble upon a specific problem during the process.)
[Check out Zig Mandel's answer below for an interesting alternative.]
It's incredibly easy.
chrome.identity.getAuthToken() will handle the authorisation and return an access token. You then use that access token to set an http header when calling the Drive API.
There is some sample code here Chrome Manifest with Google API
Some answers are using chrome identity or the drive api directly. You dont need to use the drive api directly just to get a file-id from a user's drive. If you use chrome identity you have to include the explicit user authorization when they install/upgrade the extension plus the user is giving permissions to the app when it might not be necessary / more risky to the user. Avoid getting/storing tokens when you dont need to. Google has a library called docpicker which does what you need and doesnt require you to deal with authorization nor does it ask authorization to the user. The catch is that you have to download it and possibly adapt it for use from an extension since files need to be all local in an extension.
Ive done it but not for this particular library. Some libraries require that you fiddle with content_security_policy as in:
"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",
See https://developers.google.com/picker/docs/index for an example.
Update 13/122013 - Google have said that the Picker will shortly be changed to require an oauth token
https://stackoverflow.com/a/58380137/8627279
https://github.com/malik55khan/speardsheet-reader/
Demo: https://www.loom.com/share/d7d432c513a44b05a615fa0bd170fb23
Create a client-auth key in google console and select chrome extension. after that push the project id and save it. then you will get client_id.
Next step create a api key.
add a new project.
- select google cloud or Spreadsheet
- Enable API.
Hope it will be more helpful.
Related
I would like to access my Google Drive account via their API inside of a Rails application. The idea is that I will store files, but I don't believe I need to implement any authorisation for it (like with Oauth2, for example), since I only want to access my account.
I have been researching for 2 days, but the Google documentation seems very confused and not very clear.
I started in vain with this guide https://developers.google.com/drive/api/v3/quickstart/ruby and tried to co-opt it for use inside of Rails, but since it relies on storing a token file returned upon authentication, I figured this wasn't really the right approach.
I don't have any code to share, just looking for some clarity on how I can achieve what I'm trying to do, or indeed if it's even possible.
Additional Info:
I'm using Devise for my own authentication, so implementing omniauth through that would be an option if it's necessary. I looked through some documentation around that which Devise has on their side, but I didn't want to go through that (it seemed like a lot) before knowing it was the correct course of action.
You need OAuth 2.0 to authorize requests on the Drive API as described on the documentation. In that link, you can find: «All requests to the Drive API must be authorized by an authenticated user».
To complete that authorization process, you should follow the instructions on the Drive API Ruby Quickstart linked on your question. Generating and saving a credentials.json for later use is the normal approach in this situation. Here you can read about using OAuth 2.0 over different scenarios.
I hope to have cleared your doubts on this topic, but feel free to ask further questions.
I'm working on a fairly basic Alexa skill that, in essence, searches through a specific Twitter feed looking for a hashtag, parses that tweet, and reads it back. The simplest way to do this seems to be using the Twitter API, since scraping appears to be against the TOS.
... crawling the Services is permissible if done in accordance with the provisions of the robots.txt file, however, scraping the Services without the prior consent of Twitter is expressly prohibited.
I've been having some trouble understanding how account linking works, as I've never dealt with OAuth before. I've been trying to follow the one tutorial around, but neither the text or video version were clear me.
Why the need for an external webapp?
...we need an OAuth implementation of our own to make the integration work correctly
What's wrong with the one provided by Twitter? Why can't any issues be fixed within the Lambda method, since the account integration isn't being touched otherwise AFAIK? Isn't having the tokens passed around via the URL a bad idea too? Their example code seems to require that the Consumer Secret be hard coded too.
Enter: “https://alexa-twitter-airport-info.herokuapp.com/oauth/request_token?vendor_id=XXXXXX&consumer_key=YYYYYY&consumer_secret=ZZZZZZ”.
At the very least, their webapp seems to be down for the time being, and it'd be nice to have an option that doesn't require paying money to host another copy.
I've seen this post discussing a Node.js OAuth implementation, but the necessity for such an implementation still escapes me.
I implemented a simple API.ai bot and I wanted to add it to google home platform but I really need help for the linking account part.
I don't understand if I need to implement an oauth2 protocol for my service or not. Is there any exemple or framework that allow implement this linking account step (any language is ok, it's just for a simple POC).
My goal is to ask my bot some informations and send him some orders to achieve simple processing on a server.
Hope that someone can help me, add a simple bot to google home to access and modify some informations in a server isn't really easy for me ^^
As #Leon noted, you will need to implement the OAuth2 server yourself. The Actions on Google documentation give details about what they are expecting and what steps you can do to implement it yourself. The Authorization Code flow is slightly preferred (additional features from the Assistant will require it in the future), but you're also allowed to use the https://developers.google.com/actions/identity/oauth2-implicit-flow if you wish since it is slightly easier.
There are several packages that are out there that allow you to provide OAuth2, but require you to build the connection to your own account database. I've seen packages for .NET and JavaScript, but it shouldn't be too difficult to find one that meets your needs or to write one yourself.
If you need to authenticate the user, then you will need your own OAuth server. How to hook that up to an action is described in the docs: https://developers.google.com/actions/develop/identity/account-linking
If however, this is just a personal project and you want to test it on your own device, then account linking is not necessary for you to get the action to work. You simply need to hook up your server logic to the action fulfillment. We recommend that you use the API.AI Actions integration. The docs cover how to do that: https://developers.google.com/actions/develop/apiai/dialogs-and-fulfillment
It's now trivial to create a web app that sits atop Parse.com. Now that I have this webapp, I want to expose parts of it to other developers via an oauth accesible api. So, they can develop an app that lets my site users 'give them permission' via oauth and they can now access the api.
How would I start going about doing this?
Update: After #Mubix response, I felt the following clarification would help
Currently I am accessing Parse from the server via a REST api, to get around any javascript security issues re:api keys etc. So, the api would be served of a server other than Parse. Also, the server code is in javascript / nodejs. I came across https://github.com/jaredhanson/oauth2orize which seems a likely candidate, was wondering how others are doing it and if anyone has actually gone a further step and integrated Parse access.
Hmmm .. Intereesting question!
Legal:
First of all their ToS doesn't seem to prohibit what you are trying to do but you should read it carefully before you start.
Implementation:
While parse doesn't provide feature to build your own APIs you could implement something yourself. You could treat the third party developers as users of your app. And you can use the ACL to control access.
Problems:
I don't see any way to implement oAuth entirely within parse.
How will third party apps access your API? Ideally you would like them to use a REST interface but with the parse.com REST API you won't be able to manage access to different parts of your data.
Conclusion:
It seems like too much trouble to implement the API entirely within parse. I would suggest that you write a thin API layer that takes care of auth and uses parse as the backend. You can use one of the service side libraries available for parse. eg. PHP Library, Node Parse.
I'm trying to create a redistributable web application that will integrate with Google Analytics through the Google Reporting API. Customer will install the application on their server.
I'm following this tutorial (I'm using PHP, but I believe this is not of importance for my question)
https://developers.google.com/analytics/resources/tutorials/hello-analytics-api
This works fine. No issues there.
However I can't figure out one missing element:
The tutorial starts with sending me to the Google APIs console where I have to create and configure a new API project and create and configure a client ID.
That's a lot of work that requires fairly technical knowledge (redirect url, selecting correct API, error-prone copy-and-pasting, etc.)
So my questions:
Is there an API so I can programmatically set this up for my user?
If that's not possible, is there a more user-friendly way to obtain Analytics reporting that is future-proof? (I noticed they are currently deprecating a few older APIs)
Unfortunately that's AFAIK not possible.
You could go one of the following ways:
Move client_id and client_secret to some configuration file and help your customer with deployment.
Show a one-time setup wizard for your app and guide your customer step-by-step. There you can at least provide him with the right callback URLs.
Regard your application as "installed application" and instrument curl or something similar for sending the requests.