Since the apps scope has been moved from drive.app to drive.apps.readonly the installation procedure seems to have changed as well(?).
It used to work perfectly to grant access to drive without installing the app to drive.
Now when a user grants access the app is half-installed - which means it appears in the list of the users apps even though he did not install it from the webstore.
This is bad, because now there is no way to tell if the app is already installed.
When the app is half-installed the custom file icons do not appear in drive.
My app installation worked perfectly before the change - now it seems to be somehow broken.
Is there a recommended way right now how to update the drive integration to get the same seamless experience as before?
As an explanation, we felt it would be important for users to be able to see all apps authorized to user their Drive, with a convenient way to revoke access. Your app is not half installed, it is installed, and once installed you can ask the user to authorize for files as you need.
I'm sorry this feels non-seamless to you right now, and we are looking to improve this experience for you, so stay tuned. I will update this answer when that happens.
Related
I am wrapping headless chrome using the excellent ChromeHtmlToPDF library. This we are using to dynamically render PDFs from a website. This works locally under IIS express, and also works on the server when recompiled as a console app, so the technology works. However running under IIS, chrome always exits immediately and a error of "one or more parameters are invalid", is returned.
You can fix this by passing Chrome a custom user profile directory:
chrome.exe --user-data-dir="C:\NewChromeProfile" ...
This directory will be created by the account under which Chrome is running, and therefore the account will have the permissions it needs.
After many many hours looking into this I finally solved it by running it under my own user, the restricted IIS user, then comparing the activity logs generated by the excellent microsoft process monitor.
I tracked it down to file permissions on one directory: C:\Windows\System32\config\systemprofile\AppData\Local\Google\Chrome\User Data
The app pool user needs write + modify permissions to this directory. It's up to you if you feel this is an acceptable security risk; however for us it is, for now.
This is where headless chrome stores it's crashpad directory. No amount of parameter fiddling seems to be able to dissuade it of this. That seems to be a bug.
Hope this helps someone else, I couldn't find anything on this anywhere.
While i am inserting this permission in manifest it shows error " Permission is only granted to system apps"
Actually i used this permission for developing application based on Oauth2 token. But i cant enable this permission. Can any Help me?
MODIFY_PHONE_STATE permission is granted to system apps only.
For your information, there are 2 types of Android apps: system & user
User apps are just all your normal app installations through the Google Play Store, Amazon Appstore or sideloading. These go into the
/data partition of your Android phone, which is the part of the
internal memory made available for user data and apps.
System apps are basically the apps that come pre-installed with your ROM. In a standard Android user environment, the user doesn’t
have write access to the /system partition and thus, installing or
uninstalling system apps directly isn’t possible.
In order to install an app as a system app on your Android device,
your device must either be rooted or have a custom recovery installed (or both).
That being said, that error is actually wrong because you have a valid code and compilation should work. It would be better if it gave a warning instead. In Eclipse you can easily fix it. Just go to:
Window -> Preferences -> Android -> Lint Error Checking.
Find ProtectedPermission from the list and set the severity to something other than error(info for example). This way your project will still compile.
I'm running into what seems to be a serious usability problem for users trying to use a Google Drive app from more than one account. In order for an app to be able to use Drive APIs on a user's behalf, the user must install the associated Chrome Web Store app while logged in as that user. The problem is that the Chrome Web Store seems to look for an app being installed per browser, whereas the Drive API needs the app to be installed per user.
As far as I can tell, the only way to install the same app for multiple users in the same (Chrome) browser is to install with one user, then log in as the second user, uninstall the app (which the CWS says is already installed), and then reinstall it (so that Drive will mark the app as installed for the second user). This is a very confusing experience, because during this process the app and the CWS are sending the user mixed messages about whether the app is installed.
I'm not sure if there's a canonical app to test for system bugs like this. Is DrEdit live somewhere? But if you want to see the problem behavior in our implementation, install the Graphing Calculator by Desmos.com as one user, launch it and log in using google drive and verify that everything is working. Then log out from the app, and use https://accounts.google.com to log in to google as a different user, and try using the app again. The app will tell you that it isn't installed (that's what Drive's APIs are telling us) and direct you to the CWS, which claims that the app is installed.
We are aware of the issue. And I agree this is a really bad experience for users using the same Browser (and the same Chrome session). One of the issue is that the account you are logged-into chrome can be different than the account you are logged into Google Web (Gmail, Chrome Web Store, Drive etc...) Therefore the Chrome Web Store has to make a choice to either use the apps's install status on the Browser or the Web Google account.
If you write an FAQ for your users maybe you can suggest that the most effective way to install the app for the second user is to simply install it using another browser like Firefox. Especially since Firefox won't be impacted by this issue because the app doesn't get installed on Firefox, only on the Drive account :)
The bug is filed internally, now we can only wait for it to be prioritized and fixed/sorted-out. We are also working on some other way for apps to have an install flow that doesn't involve the Chrome Web Store so that it will be less impacted by all of he Chrome Web Store/Chrome browser intricacies.
I'll make sure to ping our eng team on that issue again.
In order for google drive api calls to work, a user must install the app through the Chrome Web Store. I would like to know how to undo this process for testing. I tried uninstalling our CWS app, but drive api calls are still going through just fine. Is there some additional step beyond uninstalling the app that's necessary?
You can uninstall apps from Drive through the "Wheel" top right menu > Manage Apps... > Options > Remove this app.
If you just want to test the auth flow again (you know the first time you do open-with or create-new you go through the OAuth 2 grant screen) you can go to the following page https://accounts.google.com/IssuedAuthSubTokens .
It lets you revoke OAuth access to apps, if you revoke access to your app the next time you do open-with or create-new you will go through the OAuth 2 grant screen again.
(Very useful since only the first time you exchange the auth code will you get a refresh token)
I would usually do the later for development it's easier than uninstalling + reinstalling an app.
I have created a chrome geolocation extension. Why does it give location coordinates without ever asking the user for permission, not even on first install ?:S
When you install the extension you grant it permission to access various things. If it's one you've developed, then it will assume that you've granted it permission. Users will get a box like this, with whatever APIs you've used: