Better documentation about `current_user.sid`

App Building
1

I have a couple of questions about the current_user.sid property.

Is it immutable for a single user?

Could I determine another user's sid?

Thanks!

2

Hey @bithippie!

The values on current_user are immutable and only accessible to the user themselves at the moment, there's a feature request here for being able to access other user data! Is there a particular use case you're looking to solve?

3

Hi @Kabirdas. This is good info!

I want to encrypt data before writing it to RetoolDB, without having to deploy a separate piece of infrastructure to do the encrypting, e.g., cloud function.

Blatantly stealing from this great article it looks like I can encrypt entirely client-side using WebCrypto.

The shortcoming here is WebCrypto requires me to supply 'my password'.

These were the three options I came up with. If you can think of any others please share!

  1. Initialize state with a secret to quietly supply as 'my password'. Obvious downside with that is anyone with access to the app source could inspect the code, discover the password, read and decrypt all rows in RetoolDB.
  2. Use something unique to the logged in user for 'my password' such as {{current_user.id}} or {{current_user.sid}}.
  3. Host an endpoint that has a centralized password. :-1:

Important context: I'm on Retool Free Tier, all members of my subdomain have equal access to all data and resources.

My goal is to be able to store data encrypted at rest in RetoolDB in a way where only the user who wrote the record is able to decrypt the record.

In my case, being able to fetch another users sid (without permission) would break the ability for me to use WebCrypto in this way.

4

Hey @bithippie!

Sorry about the late reply. That's certainly a very interesting use case and a creative solution for it as well! I'm not finding a better one for your use case but just want to add a bit of context:

At the moment it seems like it should work, I would specify that it's probably better to use {{ current_user.sid }} over {{ current_user.id }} since the latter is simply a sequential integer.

That being said, neither is really intended to be part of a cryptographic key, as mentioned above we do have a feature request for being able to access more user data and it's possible that, in the future, current_user.sid will be more broadly accessible than it is now.

(As a side note for self-hosted users: it's currently possible to find each user's sid in the users table of your Retool storage database)

There is a Beta feature that allows you to prevent users from spoofing current_user properties:

1874×920 135 KB

Turning that on might help add a bit more security but that usually requires being able to restrict permissions in another way. If you're on the free or team plans any user could conceivably modify the query itself to not require the current_user reference.

5

Thanks for the reply @Kabirdas.

You confirmed my suspicions. I had a few other ideas which could get me closer to the desired outcome but it's not perfect.

  1. I could ask the user to supply a password which I keep in local storage. If local storage gets scrubbed then of course I would need to ask them to resupply the password. If the user lost the password all the data would become indecipherable so I was looking for an approach that didn't require user input.

  2. A different approach is I could possibly host an airtable endpoint which maps sid to encryption key that way I get around the problem of everyone in retool being admins and potentially modifying the query. I also wouldn't have to own any infra to do this.

I may go that route now that I've thought this aloud.

Thanks again for all the info. I think I have a workable path forward!