Set up supabase policies

[rndquu]

Depends on https://github.com/ubiquity/ubiquibot/issues/546

We have plans for reading permit URLs from supabase DB instead of parsing github comments.

We're going to hardcode supabase API key in the frontend code so we need to restrict access to most of the supabase tables. In other words we should setup supabase policies in the way so that the hardcoded supabase API key could only read from the permit URLs table without access to all other tables.

[0x4007]

Shouldn't this be a one hour task?

[rndquu]

Shouldn't this be a one hour task?

Ideally it should be <4 hours task

[0x4007]

Okay a rough workaround for pricing then.

[seprintour]

/start

[ubiquibot[bot]]

Deadline	Mon, 31 Jul 2023 17:45:08 GMT
Registered Wallet	0x3623338046b101ecEc741De9C3594CC2176f39E5
Payment Multiplier	1.00
Multiplier Reason
Total Bounty	300 USD

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

[seprintour]

Ready for review

[aditygrg2]

/wallet bc1q8clc7wq7q4wgrcmz8s56j27pjj509t7fk6sluf

[ubiquibot[bot]]

Please include your wallet or ENS address. usage: /wallet 0x0000000000000000000000000000000000000000

[aditygrg2]

/wallet 0xB951653877b7D6c9AB26bf5E7f30708fC76f53E0

[ubiquibot[bot]]

Skipping to register the wallet address because you have not provided a valid SIGNATURE_HASH. Use etherscan to sign the message DevPool and register your wallet by appending the signature hash.

Usage: /wallet <WALLET_ADDRESS | ENS_NAME>

Example: /wallet 0x16ce4d863eD687455137576da2A0cbaf4f1E8f76 0x0830f316c982a7fd4ff050c8fdc1212a8fd92f6bb42b2337b839f2b4e156f05a359ef8f4acd0b57cdedec7874a865ee07076ab2c81dc9f9de28ced55228587f81c

[aditygrg2]

/wallet 0xB951653877b7D6c9AB26bf5E7f30708fC76f53E0 0x081e8d678650bbc0a13827affe0ebf6049b186105b6726a5a3bf8e51704f9ba37c397589737b03b39a953ed8f9c436146e650db3d229ee6369b00bd2ed7c4bc81c

[ubiquibot[bot]]

Updated the wallet address for @aditygrg2 successfully! Your new address: 0xB951653877b7D6c9AB26bf5E7f30708fC76f53E0

[0xcodercrane]

Sorry to jump into the issue lately, but I couldn't agree to expose the API key to the frontend code because of security regardless of the security policy they support.

Ideally we should have that endpoints in ubiquibot itself without exposing any key information.

How is it possible? The ubiquibot is kind of a serverless function. Right now it has been designed to receive all requests but verify before receiving. In the verification step, it checks necessary security params. For permit URL endpoints, we can bypass the verification step.

@rndquu

[0x4007]

but I couldn't agree to expose the API key to the frontend code because of security regardless of the security policy they support.

Well I didn't do any updated research on this, but last I looked into it, Supabase created "anonymous keys" specifically for this reason. Basically if you have a client web app, and need to access certain data in the database, I suppose its convenient to embed the key directly in the client, making it public.

[seprintour]

Sorry to jump into the issue lately, but I couldn't agree to expose the API key to the frontend code because of security regardless of the security policy they support.

There's a public and secret key, once we setup the RLS.. we do not have any issues with security as that was what it was made for by Supabase

[rndquu]

Sorry to jump into the issue lately, but I couldn't agree to expose the API key to the frontend code because of security regardless of the security policy they support.

Ideally we should have that endpoints in ubiquibot itself without exposing any key information.

How is it possible? The ubiquibot is kind of a serverless function. Right now it has been designed to receive all requests but verify before receiving. In the verification step, it checks necessary security params. For permit URL endpoints, we can bypass the verification step.

@rndquu

From the docs: """ This raises an interesting question however: "if my anon key is in the client, then can't someone read my javascript and steal my key?", the answer is yes. And this is where Postgres policies come in.

Using Postgres's "Row-Level-Security" policies, we can set rules on what data the anon key is allowed or not allowed to access by default.

We can say for example that the anon key should only be able to read from a particular table, but not write, update, nor delete. """

So supabase's RLS was made specifically to expose API keys. Anyway @whilefoo says that he has tested the corresponding PR.

Expected behavior:

• anybody can read from the permits table
• anybody can not modify the permits table

@whilefoo Does it work this way?

[whilefoo]

Expected behavior:

• anybody can read from the permits table
• anybody can not modify the permits table

I found this to be true in my testing.

If the RLS is enabled, every action (read, write, modify, delete) is forbidden by default, then you can add policies that allow certain actions.

[0xcodercrane]

ok lets give it a try

[ubiquibot[bot]]

[ CLAIM 300 WXDAI ]

0x36233380...2176f39E5

If you enjoy the DevPool experience, please follow Ubiquity on GitHub and star this repo to show your support. It helps a lot!