search

LIT-Protocol / GoogleDriveOauth

0 stars 2 forks source link

Oauth integration with Google Drive and Lit Protocol #1

Open glitch003 opened 3 years ago

glitch003 commented 3 years ago

Looking for a fullstack JS dev to create a project that will let users delegate access to google drive documents via the Lit protocol. The final product will be a react frontend + nodejs backend that lets users delegate access to their files, and lets other users request access to those files. The frontend can be utilitarian and ugly, and we will add design and style it later on.

User Types

“Drive Owner” who wants to share their files and documents with other people “Accessor” who wants to access files that belong to “Drive Owner”

User Journey

Drive Owner

The drive owner wants to share files on their google drive with members of their DAO, without having to approve access for each user. They delegate this approval to this app that you are building.

Requirements

The drive owner should be able to grant access to other users based on requirements they define. After creating one of these requirements, the Drive Owner should be able to see a list of these requirements and the access they will grant. The Drive Owner should be able to delete a given requirement. The Drive Owner should be able to paste a Google Drive link into a text field, and have an “access” link generated that they can send to Accessors. The Google Drive link should be parsed and when an Accessor visits the access link, the back end should use the Google Drive Oauth API to grant access to the given Google Drive file that was provided in the text field.

Process for granting access:

  1. Drive Owner uses Google Oauth to authorize this app to share their documents with others
  2. Drive Owner is presented with a “control panel” that lets them set the requirements that an Accesor must meet to be able to access a file, and the Google Drive permissions that the Accessor would be granted, such as read, write, or comment access.
  3. Drive Owner clicks “Grant Access” and is presented with a modal that lets them define the requirements. We have this modal already and will provide it for you.
  4. Drive Owner picks the type of access that will be granted, such as read, write, or comment.
  5. You should save these to the database on the backend for future retrieval

Accessor

The Accessor wants to access files that exist on the Drive Owner’s drive. They do this by clicking a link that is provided to them by the Drive Owner, and was generated by the Drive Owner using this app. When they arrive, they will enter their Google email address into a text field, and they will be asked to sign a message with their wallet. This signed message will be sent to the Lit Protocol using the Lit JS SDK (it’s a single function call) and the Lit JS SDK returns a JWT. The JWT should be sent to the back end api which will verify it using the Lit JS SDK (a single function call), and if the verification function returns true, the backend should use the Google Oauth API to grant access to the file. The backend should return the url for the file, which was saved when the Drive Owner created the requirement. The frontend should then redirect the user to the url of the file on Google Drive.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 1353.0 DAI (1353.0 USD @ $1.0/DAI) attached to it.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Workers have applied to start work.

These users each claimed they can complete the work by 265 years, 2 months from now. Please review their action plans below:

1) leetdev has applied to start work _(Funders only: approve worker | reject worker)_.

I am a very experienced full stack developer. I have read the requirements of this project, and feel confident that I can develop the application you require - i.e. a React application (using a node.js backend) that allows to delegate access to Google Drive documents via the Lit protocol (plus additional functionality described in the project description).

Learn more on the Gitcoin Issue Details page.

apenugon commented 3 years ago

Hey, thanks for approving! Can you send over the modal you had in mind for requirements?

glitch003 commented 3 years ago

Thanks for getting started on this!

I'm finishing up the modal today, but the output of the modal is an array of accessControlConditions. In the meantime, you can use this hardcoded access control conditions array which will permit any user with 0.00001 ETH to be granted access.

const accessControlConditions = [ { contractAddress: '', standardContractType: '', chain, method: 'eth_getBalance', parameters: [ ':userAddress', 'latest' ], returnValueTest: { comparator: '>=', value: '10000000000000' } } ]

The Lit JS SDK that you'll need is located here: https://github.com/LIT-Protocol/lit-js-sdk

I will follow up via email with oauth credentials you can use to let users oauth their google drive accounts.

glitch003 commented 3 years ago

Ok the modal is here: https://www.npmjs.com/package/lit-access-control-conditions-modal

Don't hesitate if you have any questions

apenugon commented 3 years ago

To clarify the share process, do you intend for 1) Drive owner creates multiple share links for a drive file (cannot edit requirements after creating share link) or 2) Drive owner creates a single share link per drive file (can edit requirements after creating share link by pasting the same drive link)?

Also, do you have a strong opinion on which DB I use since you'll be hosting this afterwards? I was planning on using Mongo but it doesn't really matter much for implementation here, I can use sqlite if that would make things easier

glitch003 commented 3 years ago

Yes, Option 1) please. The user cannot edit after creating, but they can delete.

Also, here's some example code to show how to use the Lit JS SDK for this purpose: https://github.com/LIT-Protocol/lit-minimal-jwt-example
In this example, it uses possession of an NFT for the access control condition, but you would use whatever the user chooses in the lit-access-control-conditions-modal instead. Please use the "role" field for the user's role (edit, read, comment) which you can see here in the example: https://github.com/LIT-Protocol/lit-minimal-jwt-example/blob/main/index.html#L50

Would it be possible to use Postgres for the DB? I can set up a remote postgres instance for you if you don't wanna install it on your computer.

glitch003 commented 3 years ago

And I just sent you an email with the oauth credentials

apenugon commented 3 years ago

Awesome, thanks! No need to set up postgres, I've got it installed - just let me know if there are any special config options or anything I should use.

apenugon commented 3 years ago

Implementation on this is going well - have the drive flow mostly set up! One thing that's come up is how to handle management of Google drive access (since a share will need to occur whenever a shared link is accessed).

There are two ways to do this -

  1. Using a service account specifically for this service, which you would need to create/maintain (associated with the client oauth you already sent)
  2. Using refresh tokens which are given by Google and associated with each login. The issue with refresh tokens is that they apparently have some limits after which they stop working (see https://stackoverflow.com/questions/26135980/google-api-refresh-token-limit/26136111) and at that point the shared links would stop working. So with this approach shared links would not be permanent by default.

Do you have any thoughts on which of those approaches is better, or if there’s a better approach than those?

glitch003 commented 3 years ago

Awesome, thanks for the update.

So I think you can just use a single refresh token over and over to get a new access token until one of these things happens: https://developers.google.com/identity/protocols/oauth2#expiration

Therefore, option 2 is the best choice. Also, If you can grab and store the user's email when they login with oauth, then we have the capability to email them if an operation fails and ask them to re-auth again. I will implement that in the future, but if you could store their emails in the DB that would be a great help.

Thanks!

gitcoinbot commented 3 years ago

@apenugon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

apenugon commented 3 years ago

Have link generation working, just working through the Lit verification now.

For delivery here, does a github repo with code that works given a client secret file/postgres config work?

glitch003 commented 3 years ago

Ok, please ping me if you have any issues or problems with the verification.

Yeah a config file is fine as long as it's easy to switch to env vars later. So please put the config vars in their own JS file and export them from there so I only have to change them in one place and not hunt down everywhere they're used.

apenugon commented 3 years ago

I'm having some trouble with getting a JWT on the client side - the error says "You are not authorized to receive a signature to grant access to this content" with the code at https://github.com/apenugon/GoogleDriveOauth/blob/main/src/Link.js. Any idea where that's coming from?

Also, should I be using litNodeClient.saveSigningCondition when the sharer saves the file in the first place?

apenugon commented 3 years ago

@glitch003 see above - let me know!

glitch003 commented 3 years ago

Hey, apologies for sleeping on this. Was off the grid for a few days. I will debug this today.

glitch003 commented 3 years ago

Also, should I be using litNodeClient.saveSigningCondition when the sharer saves the file in the first place?

Yes, you must do this first, when the sharer saves the file. That is why you are getting the "not authorized" error.

glitch003 commented 3 years ago

Hey @apenugon how's it going? Almost done?

apenugon commented 3 years ago

Yes, almost! Just put the latest in https://github.com/apenugon/GoogleDriveOauth - the basic UI, link sharing, Google drive sharing, and link deletion are all done, the only issue is something coming up with getSignedToken.

The nodes return status code 422 for what I'm sending in https://github.com/apenugon/GoogleDriveOauth/blob/main/src/Link.js. I call saveSigningCondition in https://github.com/apenugon/GoogleDriveOauth/blob/main/src/App.js and that call seems to work. The flow seems pretty similar to the example app you sent, which does work on my machine, so there's probably something slightly off with what I'm doing.

apenugon commented 3 years ago

I figured that out - I was sending the "role" to server as an int. Apparently that was accepted with saveSigningCondition, but failed with error 422 with getSignedToken. Interestingly, changing my call to getSignedToken without another corresponding saveSigningCondition triggered a 500 error from each node - seems like a bug somewhere in there.

Now however, I'm getting a new error from the client:

base.js:18 Uncaught (in promise) Error: Unknown type, must be binary type at e.value (base.js:18) at Object.e.exports [as default] (to-string.js:28) at litNodeClient.js:151

This is at a call to uint8ArrayToString. The signatures received seem valid so not sure what's going on here. I tried replacing the call in verifyJwt in https://github.com/LIT-Protocol/lit-minimal-jwt-example/blob/main/index.html with what I was trying to send, and it actually worked when running that page - so, it seems like the error is somewhere in the npm lit-js-sdk library.

glitch003 commented 3 years ago

Hey, it was a bug in the SDK where the array wasn't a proper Uint8Array. I fixed the bug and updated the sdk and was able to get past this error. Apologies for the bug. Please update to these dependencies:

"lit-access-control-conditions-modal": "^1.1.4",
    "lit-js-sdk": "^1.1.59",

Great work so far!

When the user is accessing a shared file, is it possible to grant access without collecting their email? Like can you just get the "share URL" from the google drive api with the requested permissions and return that for the user? Or is email required to "grant access" via the google API?

apenugon commented 3 years ago

Awesome, thanks! Just tried it and it worked - uploaded the latest to the git repo. Tested link generation, deletion, and sharing with an authorized user and a non-authorized user with account address as the access condition. For some reason I get a 500 error from the nodes when using an authorized control condition that tests for NFT ownership or DAO ownership when I'm not an authorized user, not sure what's going on there since I'm just passing over those conditions from the modal.

The email is required with the "share permissions" endpoint. It is possible to use a link (listed as webViewLink here) but there is a 1 to 1 mapping from file to link. That means that if someone wanted one criteria of people to have read access and another to have write, for example, that would not be possible since only one link could be generated per file. Also, that link just uses the drive id so anybody could access these files if that they found the id somewhere which may not be desirable.

glitch003 commented 3 years ago

Oh ok, thanks for the info on the sharing link api. Yeah I think the solution you came up with, where the user enters the email address, is the best.

I got the whole thing fully working by putting a few changes in. I pushed them to this main repo.

Great work. Feel free to pull my changes in to your branch and do any final polishing if you have any, and I'll approve this bounty!

glitch003 commented 3 years ago

Also just a note: You'll need to define the env var REACT_APP_CLIENT_KEY with your google client id because I used that in the react app to replace the hardcoded client id.

apenugon commented 3 years ago

Awesome, thanks Chris! Just pushed a final commit doing some refactoring and cleaning up. Should be good to approve.

gitcoinbot commented 3 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

Work for 1353.0 DAI (1353.0 USD @ $1.0/DAI) has been submitted by: