Features of working with the Google Drive API
Recently, we needed to make a simple application for Google Drive. The application was supposed to generate a list of users on whom documents are shared in the specified folder with the possibility of editing. The task, in principle, is simple, so without thinking twice, I unfolded the draft of the project on angularJS and began to code. Google, I thought, is a big company, it should have a clear and stable API and I will do it in a couple of days.
I was too naive.
The application implied the absence of a server part (only client js), so for authorization and identification it was decided to use Google authorization. Authorization is easy! But it was not there. To identify the user between the application screens, I decided to store an authorization object, which is returned by the gapi.auth.getToken () method. The method is regular, everything is created for this. But when serializing this object, a funny error “Permission denied to access property 'toJSON'” constantly occurred. The error is “intuitive” understandable, so I spent half a day on it. It turned out that in the object that this function returns, there is a circular reference to itself. The cyclic reference was contained in the variable g-oauth-window. Therefore, a simple code solved this problem:
The next problem with client authorization is the resumption of the client session. Authentication session when using only client authentication is saved for 1 hour. But how to renew it or extend it is not clear. My dances with a tambourine with re-authorization and other shamanism could not help me, so still the client part of me authorizes the user for 1 hour. For convenience, put in the top menu the remaining time before the invalidation of the session. In principle, for this tool 1 hour is enough.
')
And here it was not without problems. The first bad luck that I encountered - how to get an external link to the document? If everything is fine with ordinary documents - it is taken from the file object's alternateLink property, then there is some magic with a folder. Any folder is returned as a link to a strange folderview interface, which I have never seen before. Googling didn’t lead to anything, so I had to fix this with an ugly code:
I built the whole array of document owners regarding userId, which gives Google. I thought it was unique and gave a complete understanding that it was the same user. But it was not so. According to the documentation of drive.permissions.list, the user ID ( pruflink ) is returned as id. But in reality it turned out that this is not the identifier that I am looking for. Why is it so - for me still remains a mystery. Therefore, I used email to identify and “recognize” the user in the list of owners. But this is still half the trouble.
This confusion with ids leads to another funny bug. If the current authorized user is a document reader, then permission.list will not return an access list. Consequently, to show that I am a reader, I use the information from the userInfo of the current user. And if the same person is then in the permission.list of another file, for example, the owner of the document, then he will have a completely different identifier. This leads to the fact that in the list of users the current authorized user can be duplicated.
Conclusion: the user ID can not be trusted, because it can change. For identification of the user it is better to use email, although theoretically it may be absent. For example, if a document is shared on a corporate domain, then in this case the email will not be, as it is shared on all users who belong to this domain.
There were a couple of little things that have already flown out of my head. For example, in the file information object there were no several variables described in the documentation. Honestly I don’t remember which ones, but these are trifles.
PS What is the result of all this can be seen here . If you have ideas on how to add a service, write in the comments - I implement it.
PPS If you know a beautiful solution to the problems described in the article, write in a personal or in the comments. I think, I am not the first who faced these problems.
I was too naive.
Authorization
The application implied the absence of a server part (only client js), so for authorization and identification it was decided to use Google authorization. Authorization is easy! But it was not there. To identify the user between the application screens, I decided to store an authorization object, which is returned by the gapi.auth.getToken () method. The method is regular, everything is created for this. But when serializing this object, a funny error “Permission denied to access property 'toJSON'” constantly occurred. The error is “intuitive” understandable, so I spent half a day on it. It turned out that in the object that this function returns, there is a circular reference to itself. The cyclic reference was contained in the variable g-oauth-window. Therefore, a simple code solved this problem:
var oAuthObj = gapi.auth.getToken(); oAuthObj['g-oauth-window'] = null; $window.localStorage.setItem('googlerSession', JSON.stringify(oAuthObj)); The next problem with client authorization is the resumption of the client session. Authentication session when using only client authentication is saved for 1 hour. But how to renew it or extend it is not clear. My dances with a tambourine with re-authorization and other shamanism could not help me, so still the client part of me authorizes the user for 1 hour. For convenience, put in the top menu the remaining time before the invalidation of the session. In principle, for this tool 1 hour is enough.
')
Work with documents
And here it was not without problems. The first bad luck that I encountered - how to get an external link to the document? If everything is fine with ordinary documents - it is taken from the file object's alternateLink property, then there is some magic with a folder. Any folder is returned as a link to a strange folderview interface, which I have never seen before. Googling didn’t lead to anything, so I had to fix this with an ugly code:
var fileLink = fileObject.alternateLink; if (fileLink.indexOf("folderview") != -1) { fileLink = fileLink.replace("folderview?id=", "#folders/"); fileLink = fileLink.replace("&usp=drivesdk", ""); fileLink = fileLink.replace("docs.google.com", "drive.google.com"); } Rights to documents
I built the whole array of document owners regarding userId, which gives Google. I thought it was unique and gave a complete understanding that it was the same user. But it was not so. According to the documentation of drive.permissions.list, the user ID ( pruflink ) is returned as id. But in reality it turned out that this is not the identifier that I am looking for. Why is it so - for me still remains a mystery. Therefore, I used email to identify and “recognize” the user in the list of owners. But this is still half the trouble.
This confusion with ids leads to another funny bug. If the current authorized user is a document reader, then permission.list will not return an access list. Consequently, to show that I am a reader, I use the information from the userInfo of the current user. And if the same person is then in the permission.list of another file, for example, the owner of the document, then he will have a completely different identifier. This leads to the fact that in the list of users the current authorized user can be duplicated.
Conclusion: the user ID can not be trusted, because it can change. For identification of the user it is better to use email, although theoretically it may be absent. For example, if a document is shared on a corporate domain, then in this case the email will not be, as it is shared on all users who belong to this domain.
There were a couple of little things that have already flown out of my head. For example, in the file information object there were no several variables described in the documentation. Honestly I don’t remember which ones, but these are trifles.
PS What is the result of all this can be seen here . If you have ideas on how to add a service, write in the comments - I implement it.
PPS If you know a beautiful solution to the problems described in the article, write in a personal or in the comments. I think, I am not the first who faced these problems.
Source: https://habr.com/ru/post/241209/
All Articles