Distinct end users can see everyone else's data. Do I need to configure Firestore or is there a way to do this within Retool Portals?

We are building an external app that is meant to handle multiple users (from different customers) at once, and we want to store the data for all of them separately. One customer should not be able to see anyone else's data. Since we just got Retool Portals, the way it's structured right now is everything just reads and writes into a single Firestore with no user data access restrictions -- so everyone can see everything.

How I'm planning to solve it is to retrieve the User ID from Retool Portals (not sure how!) and make this the collection ID in Firestore. Everything that currently exists in our current structure of "collection > document" is pushed down a level to "collection > document > collection" with the User ID becoming the new grand-parent. So there would be only one collection per user, and that's all they can access.

Does that make sense? Not sure if there's a much simpler way to do this that I'm missing. If so, would you be able to provide me with a demo of how to do it? I'm struggling to configure Retool Portals on my own.

Also, this feels like a common question but was unable to find anything when searching through the forum - apologies if I missed something that already exists! Thank you in advance :slight_smile:

Hey! Thanks for writing in. The most relevant doc here is implementing row-level security.

You can reference and maintain a mapping table of Retool User ID to your customer id, as outlined in the doc. Accessing the Retool User ID is possible by referencing {{ current_user.sid }} in your queries. You also have access to other fields like email as well.

So, your queries could look something like:

SELECT        *
FROM          orders as a
INNER JOIN    (
        SELECT 
            customer_id 
        FROM mapping_table 
        WHERE retool_user_sid = {{ current_user.sid }} 
) as b
ON a.customer_id = b.customer_id

The fields on current_user aren't spoofable, so a customer won't be able to modify these values to access someone else's data.

Additionally, rather than maintaining this mapping table, you could also store these attributes directly on the user through User Attributes. Depending on the plan you're on, this can be done in the UI (on Business and above), or through API (if you're on Enterprise).

Hope this helps!

1 Like

I simply made a new login table in postgres, and do a query on app start based on current_user.email , that way you can attach whatever variable you like.

Retool user-attributes seems to do exactly the same thing, but doesn't feel as flexible as keeping the data in database.

How did you get Retool Portals? I sent and email to their support team a week ago, no response yet.

Is Retool Portals just a fancy name for one of the apps designated as "Home Page", or it's a new menu section that's not showing below?

Thanks Antony! Will give this a try and get back. Is there a way to do this by combining Portals with Firebase Auth?

@rxunique - it’s an authentication solution on the Business plan.

Retool Portals is our solution to letting you build authenticated external-facing apps in Retool. It's not so much a standalone product as it is a way of configuring Retool to support this use case. It's available on the Business plan and above.

This year we're going to make the experience of setting up the portal much more out of the box. Currently you can follow our docs to get started.

so Retool Portals is basically the auth related page configured in Branding Setting. Like login, forgot password etc? As to the actual portal content, just a regular retool web app, correct?

Yep! Branding settings lets you whitelabel Retool to match your brand, and you will also need to configure permissions for your portals users.

But you're spot on: the portal content (including the customized Home page), is all Retool apps!

Thanks for the clarification. All make sense now.

How does price work for external users? That's what I asked in the support email and heard no reply.

Is it treated the same as End user on business plan?

That's correct. External end-users are the same as internal end-users on our Business plan. It works as you're building out your initial use case and validating Retool's different features with a smaller set of users.

When you start thinking about productionizing your use case, things like fully removing Retool's user menu, fully whitelabeling emails, and getting custom pricing often make sense—in which case our team would be happy to help.

Hi team, the way I've solved this (and it works well!) is by using current_user.sid as my parent in the Firestore. (FYI, we're not using the Retool storage and just reading and writing to Firebase directly.) Now, each user has their own data and can't see anyone else's.

  1. You mentioned the current_user fields aren't spoofable, but just want to double check if I should be aware of any security concerns.

  2. What I'm looking to do next is share data only across users who belong to the same organization. Is there a way you can help me to do this?

Awesome to hear! Regarding query spoofing, our docs outline a bit more on how it works.

On your second point, could you clarify a bit more what you mean on sharing data?

Thanks!

Given users 1, 2, and 3, where 1 and 2 are in the same organization, but 3 is not:

We want 1 and 2 to see some of the same stuff about their company, and some individualized stuff about them. The "stuff" here is data in our Firestore that we've collected about a) the company and b) the individual.

3 should not be able to see anything that 1 and 2 can see, and vice versa.

Just want to bump this!

Hi folks, would really love some help with this.

Essentially, we want to have multiple seats per organization we onboard. What would it take to set this up? Have been struggling with it in Retool for the last week (current approach is the first user in the org has their user ID point to an org ID that we generate; we now somehow want to enable this first user to invite their colleagues, and have their colleagues assigned the same org ID).