I need to share to the employee tons of files of a specific Team Drive through our ERP. Since the files should be downloadable and I cannot redirect the users to the Drive page I need to download these files from the Drive by the API and show them to download on the ERP.
The point is that I cannot found a way to allow the Drive API through Browser connect to a single drive account with OAuth and allow every user on the App get the files on the view. All the ways I found request the current user an access to its own drive and it isn't what I want.
I found a way to do this with NodeJS API (without browser), but this will need too much data to transfer from the back to the front and it dont seems to much smart since (I believe) I can download directly from the Drive to the Client without need to pass by my server, but I can't found a way to do this.
What I really searching for is a way to allow a specific domain to aways access a specific user Google Drive with certains credentials and, knowing this, dont request to every user using the app authorization to its own drive.
Related
I'm making an open source Node module that will require access to each user's private Google Drive files. I've been trying to wrap my head around all of these different authentication types, and have come to a road block. From what I've gathered, there are two primary types of authentication
I, the library author, provide in my library the public and private keys necessary to authenticate each user with OAuth2. This means giving them a URL to go to to give my app permission to access their data, and have them copy and paste an access code back into their terminal. I was able to run through this tutorial and get it working, but this method seems dangerous, because of the keys I have to package with my library, and unnecessarily difficult.
Have the user go to the Google API console, get their own API key, and provide that to my library through some sort of configuration file. No URL redirection, no copying and pasting, just some private credentials that only they have access to.
2 sounds a lot better to me: This library has absolutely nothing to do with me once it's in the user's hands, so it feels incorrect to have them authenticate with me. But from what I can find, the only way to do this with Google's API is to create a Google Service account, download the JSON they give you, go through a flow similar to the top comment on this blog post, and then manually give the service account email access to my personal Google Drive files. This seems hacky, and a lot of work to gain access to my own private data. Is there a better way to go about this? It seems strange to me that this fairly standard flow in other APIs is only available in Google's API through service accounts, but maybe there is a way and I'm just not seeing it. I'm fairly new to authentication, so any help at all is appreciated. Thanks!
First off I want to say that you cant release your open source project with the client id and client secrete that you created on Google Developers console this is against googles terms of service.
1.Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep
your credentials confidential and make reasonable efforts to prevent
and discourage other API Clients from using your credentials.
Developer credentials may not be embedded in open source projects.
My Answer on another question about exposing client id in open source projects.
Second you could instruct your users to use either Oauth2 or a service account or both its really up to you.
If the user will only be accessing their own data and wont need to access someone else's data then they can use a service account you will need to instruct them in how to share a folder on Google Drive with the service account. However from your side permissions can be tricky when they are uploaded the service account will own the file uploaded to the users google drive account you will need to have the service account add permissions for the user so the user will then also be able to access said file.
The easiest way to go will be Oauth2 when the code uploads files they are owned by the authenticated user so you wont have the same permissions issue you had with a service account.
Would Google Drive be able to be used to store data such that a client side app could read from/write to it? The data is small and would easily fit in localstorage but a requirement is that the data not be left on the machine since the computers will be in a shared environment. SO has this thread (Frameworks to store data client side) which shows many ways to store data client side but they all leave the data on the user's computer which means it would be left behind after the user is done and that's not acceptable for the use case of a public computer such as at a cybercafe or library.
The data could be stored sever side but I'd rather leave the job of user authentication and secure data storage to Google who has a lot more resources and experience on that matter than I have access to.
I've looked at the Google Drive REST API and it looks like storing won't be too bad. I've also found plenty of ways to publish data publicly from Drive. What I haven't seen is the use case of a web page accessing private data back out of Drive.
I've also found that Drive can store application data (https://developers.google.com/drive/web/appdata) but it looks like that is just for plug-in apps and not for general web apps?
Is this even possible?
Ok techinclly speaking, you can do this but there is a few limitations.
To store the data you will have to authenticate a user and user there Drive account to write to. Google drive is nice and gives you a similar %appdata% solution.
If you want to write to one central drive account say one owned by you or you company and then have everyone's applications write to that. That is the one thing you cant really do. JavaScript doesn't allow for offline or service account access. Meaning you can't set up a default drive account and give everything permission to write to that.
You have to use Oauth2 and authenticate a user and write to there drive account.
I’m working on a web service where users can log in and upload videos to my YouTube channel. I’m OK with the risk of having unapproved content as long as I know who uploaded what. Moreover, I would like to avoid handling file uploads on my own servers.
I started with building a simple proof of concept on top of the YouTube Data API v3. Using OAuth, I obtained a refresh_token for my account. Every time user visits my service I make sure I have a valid access_token with upload permissions (I can generate one from a refresh_token). Because I don’t want to handle file uploads, I used code from https://github.com/youtube/api-samples/tree/master/javascript to build a JavaScript uploader. It needs an access_token to operate correctly, so JS gets one from the backend via an ajax call.
Now, the problem is that I can’t be sure who uploaded what. One of the users can take the token from his browser and initiate many video uploads out of my site (and my control). I won’t know who did that. I was thinking about generating a separate token for each user, but it seems that there is no way of knowing which access token was used to upload a specific video.
Is there a way to determine who uploaded what without handling file uploads on my end? Maybe something similar to AWS request signing, but for YT Data API? I went through the docs, but couldn’t find anything.
To put it in a different way: is there a way to hide access_token from the user, but still have a JavaScript based uploader that goes directly to YouTube?
Alternatively, I could send those files to S3 (where I can sign requests and know who uploaded what) and have a background job that would transfer those videos to youtube. This, however, is a slow and costly process.
I want to allow my anonymous website's visitors to upload files to Google Drive on behalf of my application. In a new app console I spotted some sort of Browser key, can I use it to reach my goal?
Or maybe there are some other ways of doing this by using Cloud Storage or something?
I don't want to involve server-side authentication, I need a pure Javascript solution.
PS: This article (https://developers.google.com/drive/quickstart-js) doesn't help, since it requires my users to have Google Account.
Screenshot of my API Console:
I have a web application that currently stores documents for users on my site in my Amazon S3 bucket. I am looking to enable users to open and edit their documents from my S3 bucket using Google Docs. How would I do that?
I don't think you will be able to open your documents hosted on S3 from Google Docs, unless you get your users to save them first.
I have a crazy idea that could work:
Share the documents with your users (either by making them public or just sharing the link).
Use Google Drive to sync those documents with some server.
Periodically upload the documents to s3.