I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
Related
I have a Teams application (Tab). I am an ISV provider, and provide a multi-tenant application that is installed by customers via Teams App Store in their organizations.
How do I save settings for my application organization-wide for the customers? For example, CustomerA has installed the app and then CustomerB. I want some storage that would be unique for CustomerA and CustomerB and the app, and located in customer's environment. The settings I want to save are not per-user, but per-organization (tenant).
Somewhat similar to "App Data" folder you have in Windows Desktop for example.
Does such a storage exist? Does API for this storage exist?
A tab app is a simply a web application that you render inside of Teams. As a result, what the app does, and where and how it does it, is totally up to you. This includes any data storage you choose to have behind the scenes. For example, your tab could be built in PHP and use MySQL, or built in ASP.Net and use SQL Azure or CosmosDB. It's totally up to you, but you need to implement it yourself, as an ISV.
The important piece to differentiate clients, however, is being aware of the TenantId for each user, so you can look up which client's settings you need from the database. The most simple way to do this is simply the tid property on the Teams tab context. You can read more about that here. Unfortunately, because it's just accessed via Javascript, it's not entirely secure - for a more secure mechanism, you should be creating an Azure Application, and generating jwt tokens that you can authenticate against in your backend. It's a much more complex topic, but hopefully this answer at least gives the background you need. For more info on the security aspects (validating the token etc.), please see this question: How to restrict access to Azure Function to only allow requests from a custom Microsoft Teams App?.
I have a .NET console application that performs operations on files. I would like to allow clients to give us access to their Google Drive accounts so we can read and write files. Our console application runs as a service so there is no way for the user to interact with it and authorize our access to their Google Drive account.
I was looking at using a Google Service Account for application level authentication until I learned that a Service Account does not have access to the Google Drive folder of the user that sets up the Service Account. This sort of defeats the purpose because it is the client's Google Drive account I am looking to gain access to.
I saw a workaround posted by SO member #pinoyyid posted in this SO answer where the refresh token can be generated using Google's Oauth2 Playground, but I am concerned that the refresh tokens could expire and user intervention would be needed again to generate another one.
Another response mentioned the solution was to create the Service Account and then share the user's Google Drive account with the Service Account.
What is the recommended approach by Google? How best to gain access to a Google Drive account while only requiring the owner to authenticate on a one-time basis, yet allowing them the ability to revoke access at any time?
Both Service Account and a stored OAuth Refresh Token are viable approaches. Each has its pros and cons.
A Service Account will work where your users only need to grant access to a specific folder which they can share to the SA. Be aware that any files the SA creates are owned by, and consume quota of, the SA. You can't "share the user's Drive account to the SA", you can only share individual folders.
Storing a RT is the more permissive option. You wouldn't use the OAuth playground as described in my answer that you referenced as that's far to clunky to ask users to go through. Instead you would need to write your own registration/authorisation service (you can use AppEngine, Lambda, etc - so it's not difficult to write and host).
I have a single web application that's used by multiple customers that have their respective URLs.
We're in the process of integrating google accounts via Google API with OAuth2.
Right now we have a single project/application registered that's used by all systems.
The problem is if same account is connected on multiple systems, token is overwritten since there is a single project. Same thing if account is disconnected from system A and it's also connected on system B, system B stops working because Google API project/application is the same.
I'm wondering if there is a workaround to have multiple tokens/connections per account with a single application, or the only way to accomplish that is having one project per system and I'll need to programmatically create a project and setup everything accordingly when a new system is built.
I am working on writing a program using the Google Tasks API in Python. I have downloaded and run the sample application from Google, and it comes with a file called client_secrets.json. I understand that the file is used for OAuth authentication, but my question is should I distribute this file to users? Should I push it to my public source repo? Or is it supposed to be kept secret? If I shouldn't share it, how would other users do the authentication?
Thanks for reading.
The Google API Client Library OAuth2 docs states,
Keep your client secret private. If someone obtains your client
secret, they could use it to consume your quota, incur charges against
your Developers Console project, and request access to user data.
So don't commit or otherwise distribute the file.
If you want to publicly share your application source code, instruct others to use their own Google Developer account to register their own Google Developer project and generate their own app OAuth credentials (client_secrets.json file) for use with their "installation" of the app.
If you were making the application commercially available, you would seemingly need to share the app credentials with them in a trusted, legally protected, or secure manner.
Apparently the client_secrets.json file does not have to be kept secret for installed application. From https://developers.google.com/identity/protocols/OAuth2?csw=1#CS in the "Installed applications" section:
The process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)
So if you're making a webapp, keep it secret. If it's a python app that you distribute to users and they run on their own, it does not have to be kept secret.
I want to send info between a desktop/laptop/tablet app and Windows Phone. One possibility is to send data to the SkyDrive account and have the other end pick it up from there. Is this feasible? What I have in mind is the "Windows 8" app running on the desktop, laptop, or tablet allowing the Windows Phone app[s] to send data to its account. Is this possible, such as by providing the Windows Phone app with the Skydrive login info, or...???
From all the other questions you've posted around this query, it sounds like you want to put a mechanism in place to communicate between a Windows 8 app and a windows phone app. I would recommend you look at building a service to handle the communication instead of trying to leverage mechanisms that weren't designed for what you want to achieve.
In direct answer to the this question, though, you can probably achieve it in this manner, but what happens if the user deletes the file you create?
So, SkyDrive is unique to a user, not a device. This means if your application is running on more than one device you can use SkyDrive as a shared, unified storage option. Not just for files but also for application settings. There's an SDK for every platform, not just MS.
Here's what you need to consider.
The roaming API in Windows 8 puts information in a protected area of SkyDrive. As a result, the user cannot delete or screw up the files stored there. To that end, using SkyDrive as a shared location (like you are asking) doesn't have this benefit. The user can screw with your files or delete them - and wreck your app. There is no such thing as protecting your app files in SkyDrive (at this time).
Specifically, to your question:
The authorization model for SkyDrive requires a token that cannot be practically cached for any app. Also, you cannot cache credentials because you never get the credentials in the first place - you only get the resulting token. Listen, you would violate every possible best practice if you //asked// the user for their username and password and stored them. Please do not do this.
The final answer is this: an app on multiple devices can use SkyDrive as a shared storage solution for files and settings (like XML files) - but the developer needs to understand the risk and mitigate that (mitigation might be easy for your app). The user, on every device, would need to sign in and grant each application access to it folders. And, that's it.