You see that it is adivsed to create your file with your app-specific mime type. Is it right way? I wonder because google drive somehow associates files with the application that created them for Open with functionality. Can this be exploited for the file picker?
FYI-- You mentioned your project ID being alpine-dogfish-833. If you login to the developer console, then click on your project (which takes you to the project "Overview" page), you will see 2 identifiers at the top: Project ID: alpine-dogfish-833 and Project Number: 1088706429537. "Project Number" == "App ID" == "the numeric prefix on the Client ID"
If the file has custom contents that only your app can understand, use the app specific mime type. Otherwise, use the standard mime type for whatever kind of file you are working with.
I have finally discovered that when your app (identified with CLIENT_ID) creates a file with mime-type application/vnd.google-apps.drive-sdk, the mime-type is expanded with .<AppID>. The AppID is the first part of your CLIENT_ID. Basically, project ID looked like alpine-dogfish-833 in mine case. I have then generated Client_ID 1088706429537-4oqhqr7o826ditbok23sll1rund1jim1.apps.googleusercontent.com and 1088706429537 is the AppID that we are looking for because when my app creates a file, using
gapi.client.drive.files.insert({
'resource': {
mimeType: application/vnd.google-apps.drive-sdk,
title: file_name
}
Note mime-type is application/vnd.google-apps.drive-sdk -- it does not contain any app ID. Querying the file reveals that the effective mime type of resulting file is actually application/vnd.google-apps.drive-sdk.1088706429537. Google can even fix the mime type even if you misspel application/vnd.google-apps.drive-sdk a bit.
This answers my question because eliminates all the confusions. The major confusion is that your project has additional application id, that you get even before the CLIENT-ID but it has nothing to do with signing the files with app-specific mime-type. I did not find that in the referred q&a. Secondly, this answers my question because it basically says that mime-type contains APP_ID so that app id and mime-type is therefore the same thing and there is no difference/redundancy/conflict to choose between two.
Related
I am spending hours (literally) trying to find a way to change the DriveApp.Permission of my script (for web App).
Actually, its value is VIEW, not allowing me to create folders, files or edit them (read only).
The script is configured to run as "me", accessible for anyone.
I have checked the owner of the folder ( FOLDER.getOwner().getEmail(); ) and owner of the user/session ( Session.getActiveUser().getEmail() ).
Not surprisingly, they've returned the same value. I have read THIS, but without success in retrieving any useful information.
I think, the problem is around the DriverApp.Permission value.
I was brief as a possible, I think. Could someone help me?
To put it clear: the script, the driver, etc., all of them belongs to me ( \o/ ).
Example:
DriveApp.getRootFolder().getFoldersByName( "ExistingFolder" ).next().createFile( "No_authorized_it_will_not_be_created_and_will_trigger_a_exepction" , "Some TEXT" );
Google GET response (translated/approximated)
Exception: You don't have permission to call DriveApp.Folder.createFile. You need to have permissions :https://www.googleapis.com/auth/drive (line 135, file "InternalDriver")
With support of #Copper and suggestion of #TheMaster, my solution:
Add this JSON object to the manifest
"oauthScopes": ["https://www.googleapis.com/auth/documents", "https://www.googleapis.com/auth/drive"]
Create a new version of the project, and try it again.
I have removed the actual permission related to project before deploy a new version.
I'm not sure whether "https://www.googleapis.com/auth/documents" path is necessary for simple creation or edition of folders/files. The other path string is certainly needed.
When a section renamed get sections API doesn't reflect the updated name whereas get page api shows updated parent section name. This seems to be bug/ data inconsistency in ON API.
On change of anything at page level updates the lastModifiedDateTime for a section but nothing gets changed at notebook level. This again seems to be like some data inconsitency issue.
Can somebody clear this confusion.
(Note - All above can be tested using MS Graph API Explorer
)
These are two separate topics:
Section renaming
This is a known limitation/bug in OneNote - if you rename a section in OneNote Online (in your browser), then the API GET ~/notebooks/id/sections or GET ~/sections will give you the "old" name. This is because OneNote Online doesn't actually rename a file, it only marks the file as "to be renamed" - if you were to look at the file itself in OneDrive/SharePoint it would still have the old name.
Once the OneNote Native Client sees the section (for example OneNote for Windows) sees the section that has been marked as "to be renamed", it actually renames the file.
The OneNote API GET ~/sections/id/pages actually looks at the section binaries and is able to tell whether the section is renamed or not, which is why that name can be trusted as the "most up to date" one.
I have communicated this feedback to our team and we are exploring alternatives - I encourage you to start an item in uservoice so we can better understand impact.
https://onenote.uservoice.com/forums/245490-onenote-developer-apis
LastModifiedTime (LMT) on notebook/section clarifications:
The LMT of a section is equal to max(LMT of pages under it).
The LMT of a section group however is not max (LMT of sections and section groups under it). A section group is a folder and its LMT should behave like that of a folder in a traditional file system (reflects time of last add/delete of a file/folder directly under it).
However, there is nothing stopping you from using $expand and calculating the LMT (as you understand it) yourself based on the entities below the notebook/section group.
https://blogs.msdn.microsoft.com/onenotedev/2014/12/16/beta-get-onenote-entities-in-one-roundtrip-using-expand/
I was let Chrome Web Store dashboard create private key therefore when I use "Load unpacked extension" in Extensions tab, id of it becomes random. As solution I added "key" field to manifest.json file and used public key from dashboard. This gives proper id but then I can't commit this manifest.json file because even that public key easy to find still won't be allowed to share in public I think. I checked many open source projects which using native messaging and none of them includes key field in their manifest file.
Then I tried packing extension myself so I can have private key file but then when I use "Load unpacked extension" I can't use this private key file like including "key.pem" in same directory and then ignoring this "key.pem" file in git. And doing "Pack extension" and dragging this crx file every single time when I need to test something would be inefficient.
Reason why I need same id is because I'm using native messaging and it have "allowed_origins" field which require same id otherwise not works. So what is best way to have same id and still avoid committing this with git?
According to the Node-Webkit wiki the manifest for a program requires a name and this name must be globally unique because it determines the name of the directory that data files for the program are stored in.
I haven't been able to find anything else that this name is used for. Is it safe to just use a UUID as the name listed in the manifest? Or will that be exposed to the user somewhere potentially?
It's more typically related to the common program name that the user sees, but it doesn't have to be. For example on the Mac, the standard location for app specific data is ~/Library/Application Support/. When I look there I see things like GIMP, Skype, XDK &c. If your app happened to have the same name as another app, it would cause problems as they'd both writing to the same location, i.e. if I gave my app the name GIMP, both apps would try to write files to that dir.
Typically a user doesn't have to access this directly, so there's probably no harm in using a UUID here, though I would probably append it to a name related to my app name, just for clarity/simplicity, i.e. instead of making the name foo I'd make it foo-<UUID>.
But I'm no expert . . . .
My application stores its data in an Access 2010 database (accdb) file. It's password protected, which means it's encrypted w/ AES-128.
I'd like to add some meta data to the file that's publically available. This way older verisons of my application can investigate the file to see if it's even worth trying to open. Otherwise, they'll just get the dreaded "Unrecognized Database Format" error, which is usually associated with file corruptions.
In Windows, you can right-click on a file, click "Properties" and see attributes under the Details tab. I'd love it if I add attributes like the version of my application that last touched the file, and maybe other details. I'd like to avoid having a different file extension for each version of my app!
Is it possible to add some public meta data to an encrypted Access 2010 database?
You can add custom database properties : http://support.microsoft.com/default.aspx?scid=kb;en-us;q178745
You can change the file extension of an encrypted Access database and change the properties for that extension. The extension .enc is fairly descriptive and does not seem to be widely used.
The file will open normally when clicked and ask for the password. The icon will be recognizably Access and the description, "Encrypted MS Access" in this case, will appear under Type in a directory listing.
With NTFS, you can add an alternate data stream (ADS):
notepad.exe z:\docs\testde.enc:Extra.txt
Reading the stream:
more < testde.enc:extra.txt
More information: http://www.think-techie.com/2010/04/alternate-data-streams.html
http://www.irongeek.com/i.php?page=security/altds
This is a tough nut to crack! An application must read information about the ACCDB, but that information can't be stored in the ACCDB because you want the read without opening the ACCDB. And you can't use the suggested file system methods because this must work under Wine on Mac (I assume from another of your questions).
The only solution I can see is to create a companion file (with same base name but different extension) to hold the metadata. So if your application wants to know about SomeDb.accdb, it would look for a file named SomeDb.metadata and read that instead.
I suggested a kludge for your earlier question ... unfortunately this is another. :-) However, it's a simple kludge and it should work ... even on Mac.