Which kind of cookie is required to work with webContentLink? I noticed when I'm logged in to Gmail only, i get 403 error. When I open Google Drive too in on other tab and check some files, then my webContentLinks starts to work. Is this the way it should work or did I missed something? Once it was sufficient to be logged in only in Gmail...
(I have a very simple web application, that shows some links to files I shared with my friends in Google Drive. I don't want to use further authentication, but public is also not an option. It was very convenient to have accessible links when their Gmail is opened.)
Related
I have a number of images in Google Drive and I am wanting to use them in various ways via the direct link style:
https://drive.google.com/uc?id=DOCID
In Chrome I am logged into three different Google accounts, my corporate one, my personal one, and one other. If I navigate through the Google Drive interface to my files in the corporate account I can see them fine. If I use the form https://drive.google.com/open?id=DOCID then the Google Drive interface opens properly with the image displayed. However, when I try to access the file directly using the uc?id= URL style above I get a 403 error.
"403. That’s an error.
We're sorry, but you do not have access to this page. That’s all we know."
I have tracked this down to being because when I use this URL form, for some reason Chrome or Google Drive are using the wrong authentication credentials - i.e. the ones from my personal account even though this file is in my corporate account.
I've proved this by firing up Firefox, which isn't authenticated to any account, logging in as my corporate user, and then using the URL above: bingo, the image is displayed.
So my question: is there any way to force the URL style above to use the correct set of credentials when accessing the file?
You can use drive.google.com/u/1/uc?id=DOCID or drive.google.com/a/mycorporatedomain.com/uc?id=DOCID
However, do not rely on these URL's not changing in the future.
Log out of all the accounts and only log in just one needed account. This works for me. The google free 15 GB is good since I can always create new email but difficulty in downloading file give drop box an edge.
I'm creating a Chrome extension that modifies the gmail UI.
But when I authenticate (with chrome.identity.getAuthToken) in the Chrome extension, it defaults to using the user account that is signed into Chrome.
But I need data for a gmail account when I am on that gmail page.
I saw this answer, but I was wondering if there was any easier way?
I just went through the same process and I couldn't find an easier way.
You'll need to authenticate yourself.
We tried using the mechanism in that link but it requires putting the Client Secret in the Extension - very ugly.
In the end we request and refresh tokens externally through a hosted web page from our www site.
Although a hassle to set up once in place it works nicely and is worth the effort.
We are having issues where sometimes a file that a user can access is not returned when the user issues a files.list. This can happen in many ways. For example, new members of a Google group will not see previously shared files, as described in this question. Moreover, acording to Google documentation there are other limits on sharing which can prevent shared files from appearing in the "Shared with me" view. Finally, a user can issue a files.delete on a file she doesn't own, and the file will disappear from files.list but will still exist.
What can a user do via the SDK alone to cause a file which she can access via files.get to appear in the list of files retrieved via files.list? We are using a service account which impersonates users; the user never authenticates to Google via a browser. A link in an email that the user needs to click won't work for us, unfortunately. Accessing the file via the Google Drive UI has the desired effect, but the analogous files.get call does not.
The Google Calendar API explicitly exposes a CalendarList interface where a user can issue an insert to add an existing calendar to her list. The Google Drive SDK seems like a hybrid Files/FilesList interface with some of the functionality missing (nothing like FilesList.insert) and some of the functionality mixed together (issuing a delete as a non-owner acts like FilesList.delete but issuing it as the owner acts like Files.delete).
If we can't manage the user's files list programmatically then it is not useful for our service. We could ignore the files.list call entirely and just start recursively performing children.list queries on all shared folders, but this is incredibly expensive (unless someone knows how to issue a single query which returns all the Files resources in a folder and not just the IDs of those resources).
Any help would be appreciated. We've been trying this many different ways and have been frustrated at every turn. Thanks!
I'm looking for some clarification on accessing Google docs/Drive SDK via a Service Account.
I have everything set up in the API Console and I can successfully generate an access token via the JWT process and indeed I can issue requests to either drive SDK or the Docs List API to get a listing of documents. However, the document listing is always empty, I was expecting to see all the documents in my Google Drive. I am obviously not understanding fully what a service account gives you. If I upload a document via the Service Account then it does show up correctly, but is not visible in my Google Drive, it's as if the Service Account is a totally separate black box.
The reason I want to use Service Accounts is that I have a service running that needs to upload documents to various clients Google Docs accounts, without them having to go through the OAuth dance as there will be no UI interaction at all. Is this possible with Google docs. I was hoping that they could just send my the client_email and the certificate with the private key and I would be able to upload documents to that account.
Many thanks for your consideration
-Marshall
Not sure whether you need the answer anymore, but I just faced with the same issue, came to this post. Found one solution which works in my case, so sharing with everyone here.
The only integration point towards GoogleDrive in my case is document listing.
When I first created my service account, it didn't work as well (just empty list all the time).
What did I do to fix it:
Go to MyDrive UI https://drive.google.com/#my-drive
Checked all the documents I want to see on my website
In the top menu clicked "More"->"Share..."->"Share..."
In "Add people" section (new window "Sharing settings (N items)") I added service account email (format is "XXXXXX##developer.gserviceaccount.com")
Run document listing once again and got it working.
I'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.