How we can get preview of google drive files in web without login into google account. In current scenario only public files are visible through embed link, we need to show preview of file in iframe which are not public and without login.
Here in lies the difference between the term "public" and "private". The way google authentication works is that any data that is public is free for anyone to see. If you set the file to public anyone can open it without being logged in or authenticated to Google.
Private files on the other hand you must have permission to access. There is no way to preview a file you do not have permissions to access. There is no workaround for this.
I think "Publish" is what is you need. The file can still be "Private".
Publish and embed Google Docs, Sheets, Slides & Forms
To make a document, spreadsheet, or presentation, available for a large audience to see, publish a file. After you publish your file, you’ll have a URL that you can send to anyone or embed into your website.
Related
I have an internal app (not a published one, only used within our Google Workspace domain) which is a command line tool to update the contents of some Google Sheets. It currently uses the https://www.googleapis.com/auth/drive scope and works fine.
I want to minimize the privileges of the authorization token that this app caches, and by reading the documentation it seems that I should be able to use the https://www.googleapis.com/auth/drive.readonly scope to find the file I want, and also https://www.googleapis.com/auth/drive.file to grant write access to only a specific file.
With the reduced scopes, I am not surprised to get an error like:
appNotAuthorizedToFile: The user has not granted the app 566375348811 write access to the file 1UsItGhBHwRaodHbv5g1LCrSESUZBkskDvKDkbGjREjI
The only relevant documentation talks about integrating apps with Google Drive and using the Drive Picker UI which I expect does this authorization behind the scenes. Since this is an internal command line tool, I really don't want to go that route.
Hence the question:
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
I'm OK even if I need to set some magic metadata on the file to make it accessible.
Update
As I got a couple of responses saying that when using drive.file it is not possible to access files which are not created by the application, I am putting some supporting documentation here to show why I think it is possible:
The API-specific auth info is the first document on the Google Drive API page, and it specifically mentions:
So, when possible, use non-sensitive scopes as they narrow access to
specific functionality needed by an app. In most cases, providing
narrow access means using the
https://www.googleapis.com/auth/drive.file per-file access scope.
Further down the page it mentions:
This scope enables users to select the specific files from Google
Drive, and through the Google Picker, that they want to allow your app
to access.
I understand this to mean that it is possible to open files which were not created by the app, even when using drive.file.
My problem is that the document goes on to explain:
Many apps work with per-file access without any changes. If you are
currently using your own file picker, we recommend switching to the
Google Picker which fully supports the drive.file scope.
Well, since I am using a command line app, I cannot use the Google Picker, so I am asking how to implement my own. I do understand that the picker itself needs to have access to all the files (hence the need for a drive.readonly scope), but to actually be able to write the files, it needs the elevated permission of drive or the more restrictive per-file access of drive.file.
If I simulate an authorization request for drive.file I get a prompt which explains that authorizing the request will grant my app to:
See, edit, create, and delete only the specific Google Drive files you use with this app ℹ️
Clicking on the information icon I get a more verbose explanation which reads like it support opening any file I authorize:
This app wants permission to create new files or change existing files
that you open with this app. Once authorized, the app can:
See these files
Upload and download these files
Delete these files
See the names and emails of people you share these files with
Share and stop sharing these files with others
Organize these files
There may be private information in your Google Drive, like financial
records, medical reports, photos or tax info.
There are also other examples of applications like ZIP Extractor or diagrams.net or Photo Editor which use the drive.file scope (based on the authorization prompt), and which I can use to open and edit files that were not created by them.
I am posting this as an answer, to demonstrate an ugly "workaround" for the issue.
TL;DR: Use a web based frontend to authorize access to files. Once the app is authorized, the command line app inherits the permissions.
More step by step instructions, assuming we already have a working command line project:
Go to https://myaccount.google.com/permissions and revoke all access I have granted to my app.
Follow the instructions at the Drive Picker API to update my current GCP project.
Create an API key. OK to be unrestricted, but I restricted it to https://localhost:9843
Create a new OAuth 2.0 client ID of a "Web application" type (my current one is "Desktop" type and that would not work). Authorize https://localhost:9843 as a JavaScript origin.
Copy the helloworld.html example at the bottom of the Drive Picker API guide which is also on GitHub with the following modifications:
Set developerKey to the API key created above
Set clientId to the new OAuth 2.0 client ID created abovce
Set appId to the numeric project ID of my GCP project
Add 'include_granted_scopes': true to the call to window.gapi.auth.authorize
Update createPicker to make it easier to find the files I want. E.g., set the mime type filter to application/vnd.google-apps.spreadsheet.
Host the example in a browser with ruby -rwebrick/https -e 'WEBrick::HTTPServer.new(:Port => 9843, :DocumentRoot => ".", :SSLEnable => true, :SSLCertName => "CN=localhost", :SSLCertComment => "Autogenerated" ).start'
Now, if my command line app fails to edit a file, I can use https://localhost:9843/helloworld.html to grant access to the file, and my command line app can then edit that file.
If you check the docs for the scope you will find it says.
https://www.googleapis.com/auth/drive.file View and manage Google Drive files and folders that you have opened or created with this app
This gives your app access to files that the app itself created or has previously opened.
You should also know that there is no way to limit authorization to a single file. Authorization is all or not thing.
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
You make sure that the file was created by the app itself. using files.create. If the file was created by any other app the you cant access it using the drive.file scope
There is one note though if you have https://www.googleapis.com/auth/drive.read-only scope and you open that file to read it. the line where it says opened or created with this app implies to me that once you have opended it for read in this app that you would then be able to use it with https://www.googleapis.com/auth/drive.file but its not something I have tried.
Another thing is im not sure what you mean by open the google drive api is a file storage api its not going to let you see the contents of the file your going to have to download it and open it locally. Have you considered going though the Google sheets api if you want to read and write to it programmatically?
Our app has the ability to upload documents from google drive to our app, or to embed google docs in our app.
Currently, we are looking at using these API scopes:
google docs: https://www.googleapis.com/auth/documents.readonly
"View your Google Docs documents"
google drive: https://www.googleapis.com/auth/drive.readonly
"See and download all your Google Drive files"
However, those scopes give us read access to ALL the user's google drive files and documents. We actually only want access to the files the user selects themselves to share with us. Is there a way to only gain access to user selected files, and not all files? I basically want our scope to be more restricted than those two, both for the user's comfort and privacy, as well as limiting our app potential liability.
I see that this is this scope:
https://www.googleapis.com/auth/drive.file
"View and manage Google Drive files and folders that you have opened or created with this app"
But I only want read access, and don't need the ability to 'manage' anything on the user's drive. I also don't see a parallel for google docs.
Any information, solutions, and/or suggestions are greatly appreciated.
I'm requesting authorization codes using the Google API and specify https://www.googleapis.com/auth/drive.file as the required scope since I'm going to store files on the users drives.
However, when I'm authenticating it says my application requests permission for two scopes, both
View and manage Google Drive files and folders that you have opened or created with this app
and
View metadata for files in your Google Drive
I can verify that I indeed have access to list all files on the drive.
Is the drive.metadata automatically included/required for the scope i'm requesting?
I wish to ask for as few permissions as possible.
Drive v3 scopes
https://www.googleapis.com/auth/drive View and manage the files in your Google Drive
https://www.googleapis.com/auth/drive.appdata View and manage its own configuration data in your Google Drive
https://www.googleapis.com/auth/drive.file View and manage Google Drive files and folders that you have opened or created with this app
https://www.googleapis.com/auth/drive.metadata View and manage metadata of files in your Google Drive
https://www.googleapis.com/auth/drive.metadata.readonly View metadata for files in your Google Drive
https://www.googleapis.com/auth/drive.photos.readonly View the photos, videos and albums in your Google Photos
https://www.googleapis.com/auth/drive.readonly View the files in your Google Drive
https://www.googleapis.com/auth/drive.scripts Modify your Google Apps Script scripts' behavior
You cant view metadata on a file you dont have access to see. Yes you need to be able to see them. Google is smart they know if you want to want to see the metadata your going to have to also need the ability to see the file in question. So yes you are going to need to be able to list it.
I'm trying to somehow allow other people to download uploaded files on QuickBase on a different website. I have files on QuickBase uploaded, but people need to sign-in to QuickBase to download it. Is there any other way around it?
You can grant what is essentially anonymous access to one of your Quickbase applications by giving "Everyone on the Internet" a role in your application. It gives anyone with a link to that application whatever access level is defined in the role given. If you want to only share files, you could create a role that has view only access of that specific file attachment field and assign that to "Everyone on the Internet". If you want to be selective about which records are available for download you can include a checkbox to "Make Public" and include that in the role's view logic.
You grant "Everyone on the Internet" access in the add user form for the application. If you start typing "Everyone on the Internet", you'll see it pop up as a recommended user name. If you do not see this as an option, that means that granting open access was disabled by one of your billing account administrators.
Just remember, whatever permissions you grant "Everyone on the Internet" applies to literally anyone on the Internet that has a link to your app. Of course, you can always use a separate file hosting service like Dropbox or Box if you want to avoid the Quickbase issue entirely.
You can allow file downloads for anyone with the link to the file. That's a setting for every file attachment field on QuickBase. Once you go to the specific attachment field setting you will find it under File Attachment field options. It's a checkbox called "Allow access to this file attachment from a Quickbase link without signing in". For me, that's prefered compared to giving everyone access to the app and restricting all the other fields by role.
I'm currently working on a rather interesting... project. I have a client who wants to allow form uploads (from a page presented on their server) specifically to their own google drive account. The platform being used is essentially LAMP.
Single (pre-authenticated) google drive account. Multiple otherwise anonymous upload sources (users).
They do not want users to be required to have their own google accounts (rules out simply using Picker on the user's own drive files).
They want some degree of backwards browser compatibility, such as IE8 (rules out XHR to form the post using HTML5's file API to read the filedata). They don't want to use flash/etc due to potential compatibility issues with certain mobile browsers.
What is working:
Authenticating (getting a refresh token, storing, using it to get access tokens as needed)
Uploading a file to the account without metadata
Result of file upload being sent to hidden iframe
Catching the iframe load event via jquery to at least know something has happened
Problems:
The REST API upload endpoint does not support CORS: there is no way to access the result iframe directly. (see: Authorization of Google Drive using JavaScript)
The return from a successful upload is only raw JSON, not JSONP.
There is seemingly no way to host anything with proper headers to open via browser on the googleapis.com domain, so easyXDM and similar multi-iframe with cross origin workaround communication javascript approaches are ruled out.
There is no way to embed a callback URL in the POST from the submit, the API does not allow for it.
The Picker displays errors on trying to upload if you pass it an Oauth2 token that is not for a user who is also authenticated in their browser (assumedly via cookie). Strangely enough you can show files from the Oauth2 token's matching account, but other than in a browser instance where the target Oauth2 token's account matches the already logged in user any file uploads fail with an ambiguous "Server rejected" message. This happens with all files and file types, including files working in an authenticated browser instance. I assume it's an authentication flow/scope issue of some sort. I haven't tried diving the Picker source.
All of the javascript Google Drive API upload examples seem to rely on using HTML 5 to get the file data, so anything of that nature seems to be ruled out.
While files are uploaded, there's no way other than guesstimating which file came from which user, since we can't get the file object ID from the result in our inaccessible iframe. At best we could make a very rough time based guess, but this is a terrible idea in case of concurrency issues.
We can't set the file name or any other identifier for the file (not even a unique folder) because the REST API relies on that metadata being sent via JSON in the post request body, not via form fields. So we end up with file objects in the drive with no names/etc.
We can't create the file with metadata populated server side (or via jquery/XHR, or the google javascript API client) and then update it with a form based upload because the update API endpoint exclusively works with PUT (tested).
We can't upload the files to our local server and then send them to google (proxy them) as the php ini is locked down to prevent larger file uploads (and back to restrictions imposed on using HTML5 or flash for why we can't chunk files/etc).
All of this has been both researched and to varying degrees tried.
At the moment this is going on hold (at least it was a useful way to learn the API and gain a sense of its limitations) and I'm just going to implement something similar on dropbox, but if anyone has any useful input it would be lovely!
e.g. is there any way to get this working with Drive? Have I overlooked something?
I also realize that this is probably essentially a less than intended use-case, so I'm not expecting miracles. I realize that the ideal flow would be to simply allow users to upload if necessary to their own google drives and then have them grant file access to our web app (via Picker or API+our own UI), but this becomes a problem when not all of our own users are necessarily already google account users. I know that google would OBVIOUSLY prefer we get even more people to sign up with them in order to have this happen, but making people sign up for a google account to use our app was ruled out (not out of any prejudice on our part, it was just too many added steps and potential user hurdles). Even simply having them sign in to google if they did have accounts was deemed unwanted for the basic LCD feature functionality, although it's likely to be added as an additional option on top of whatever becomes the base solution.
The biggest problem with the approach you described is you're introducing a big security issue. Allowing an anonymous user to directly upload to Drive from the client requires leaking a shared access token to anyone who comes by. Even with the limited drive.file scope, a malicious or even slightly curious user would be able to list, access (read/update/delete!) any file that was uploaded by that app.
Of course a public drop box feature is still useful, but you really need to proxy those requests to avoid revealing the access token. If your PHP environment is too restrictive, why not run the proxy elsewhere? You can host a simple proxy to handle the uploading just about anywhere -- app engine, heroku, etc. and support whatever features you need to ensure the metadata is set correctly for your app.