First I apologize if I'm a dolt and am missing something obvious, but I've spent a few hours scouring documentation and am lost.
I'm trying to write a python script that will upload a bunch of images to a single user's Google Drive. The user already exists and will never change. I am not writing a web app and don't plan to use any user interface whatsoever. Everything will be done through code.
As best I can understand from the Google documentation, I have two choices:
1) Write a web app and register it to use the Drive DSK. This of course requires having urls and such for the web app.
2) Create a service account, which ties my "app" to a new service account email.
Neither of these options works for me. Is there any way to simply log in to a single user account and access their drive through python scripting?
There is a deprecated API called ClientLogin that would enable you to use the username and password for a login to access that Drive data.
But the basic idea is that you should be using something more secure -- from your users' point of view -- that allows them to authorize you without giving you their password.
For your use case it is possible that the user is you or someone you know and that you are accessing their account through a more personal kind of authorization. In that case, ClientLogin may be your best choice. If this is an application designed to be used by arbitrary users, the deprecation of ClientLogin is for a good reason and I would urge you to bite the bullet and choose one of the supported options.
The correct solution is to separate the authorization phase from the access phase. The authorization process needs to be run one time only, and can be done from a simple web site. The result of this is a refresh token which is analogous to a username/password. You will need to be aware of the security implications. Make sure you only grant drive.file scope to minimise the impact of a security breach.
Since you are uploading images, you might also want to look at the picassa api.
Related
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
I'm working on a an application where my back-end server will push and pull data over the google drive sdk. So, the back-end will only ever need a authorization via a single admin user's set of credentials.
Is the best way to do the authorization for this use-case to do what's described here?
https://developers.google.com/drive/web/auth/web-server
It looks like I would manually authorize my back-end's user once and store the refresh token for later offline access, thereby not needing manual/human interaction ever again.
But is that actually the best way for this use case? Is there another authorization workflow that I've overlooked?
The method described at the link you sent is appropriate when you are authing several end users. I find it's overkill if you only ever need to auth a single user. Too much code and faffing around for something that will only be used once.
Check out How do I authorise an app (web or installed) without user intervention? (canonical ?) which is a one-time procedure which gets you the same result, without writing any code.
Having worked on it some, I think the best way for my application is this:
https://developers.google.com/api-client-library/python/auth/service-accounts
You create a Service Account through the admin console. There's no messing around with a manual authorization step that could later break the app.
I want to create a script that runs on a Google site. The script would perform a specialized calculation for a given user and then display the answer for the user. The script would depend upon user input, but the code itself should not be viewable by the user. I want the code to exist in a "black box" so that the calculation formula can be kept secret. Is this possible?
I searched the documentation, but only found this, which does not address this question:
https://developers.google.com/apps-script/guides/services/authorization#permissions_and_types_of_scripts
Whether your App script is embedded in a site or written as a standalone script does not change a lot of things... the only difference will be the way you include it on a page as a gadget.
If it is embedded it will be available from a list of scripts in the page editing, if not you'll have to use the .exec url of the deployed webapp.
Anyway, that does not change the way people will have access to the app.
You can define these parameter when you deploy the app (which is mandatory in both cases), allowing for anonymous access or requiring to be logged in.
If I understood you correctly, you would like to restrict the access to some people but not share the code.
Depending on how you defined the access mode above and wether you are using a Google Apps inside a domain or not, you will be able to do it using 2 ways :
in a domain you can get the logged user identity and use that to accept/deny showing the app.
in a "normal" gmail account you will have to implement some sort of logging feature to request a user name and password to give access to the active part of the app.
In both case you never need to share the script itself, this sharing parameter is independent from the webapp access.
I hope I understood your question correctly... if not, feel free to comment.
You might check out the Private Functions section of the following page.....the example is similar to what you're referring to, I think.
https://developers.google.com/apps-script/guides/html/communication?hl=ru
I don't fully understand how they work and haven't used them myself, but I bookmarked it to figure out later. Maybe another user who understands Private Functions better can explain...
I have developed a web application using Google scripts UIApp class which will collect the data of work done by each associate and writes data to my spreadsheet.
Problem I'm facing is I have to share my spreadsheet to all the associates with write permission where it enables them to see others data. I want to hide this sheet from all but they should also be able write data using the web application I shared.
Please let me know for more details or any code snippets
Note: I have Not used Google Form because I need change the list values dynamically based on the selection and the type of user.
You can deploy the app you have built with UiApp to be executed as "you" and allow access to anyone. The spreadsheet won't need to be shared anymore but as it is anyone (even anonymous if you are not in a domain) will be able to use it...
You'll have to implement an access control yourself, again this will be different in a domain or in a "normal" gmail account (in a domain you can get the user email, in a gmail account you can't)
(since apparently I can't comment.. but to follow up on this question.)
Is there a best practice for running as something other than really-yourself?
Say a team is managing it, or your a contractor who won't stay with the company, and so you're account and access is likely to go away.
I assume it results in creating a shared account, or perhaps a groups or something? You start getting into all sorts of ACL issues. And a simple ``run as yourself'' doesn't seem like a good long term solution.
I am looking at creating a good google chrome extension for tumblr.
Now tumblr uses Oauth as it's authentication method.
So my question becomes.
Do I:
Distribute a single key with the application and hope people are nice enough to not use it for illegitimate purposes.
Put in the options the ability for a user to enter their own key, hence asking each user to register an application.
Create an intermediary on my server that makes the actual request.
Something else?
I also had to consider this for my Template extension when using OAuth to communicate with the goo.gl URL shortener service on the user's behalf.
After reading Chrome's OAuth tutorial I managed to implement this simply using the following;
ChromeExOAuth.initBackgroundPage({
access_url: 'https://www.google.com/accounts/OAuthGetAccessToken',
app_name: chrome.i18n.getMessage('app_name'),
authorize_url: 'https://www.google.com/accounts/OAuthAuthorizeToken',
consumer_key: 'anonymous',
consumer_secret: 'anonymous',
request_url: 'https://www.google.com/accounts/OAuthGetRequestToken',
scope: 'https://www.googleapis.com/auth/urlshortener'
});
This is surrounded by quite a bit of logic due to the complexity of the extension but this results in the user simply being shown a page (on a new tab) the first time they attempt to shorten a URL using my goo.gl implementation. Here the user can decide to allow/deny the authentication. Since this is only done once (unless the user later removes it from their list of authorized applications) I thought this was fine and my users seem to agree.
I did also provide an option to toggle OAuth on/off but I'm guessing this will always be required for the tumblr API. On that note I must admit I'm not familiar with that particular API so I'm afraid I can't help you further.