Two major issues I just discovered while seeing if Retool is able to allow us to invite external users to some simple Apps.
One - Even when you have a user fully locked down to a single group that has a single app, where the home page is set to a single app, they can still simply type /querylibrary in the address bar and run arbitrary queries against databases.
One is worse than Two, but they are both VERY BAD for this use case. Unless I am missing some extra steps here, please advise if so! These are VERY CONCERNING—even from an internal standpoint, we don't want these holes to exist for less technical internal users either!
Would love a way to remove the Top Menu (Database, Query Library, Workflows, Forms) completely from a specific group/users. And do real auth checking on every page load so users can't go fishing for pages that are escaping proper auth on the server side. This is drastically reducing my confidence in Retool's ability to do proper permissions.
Ha - spoke too soon (didn't fully read through the new Portal docs). The Default All Users group strikes again. Need to make sure it's also locked down. Wonder why this group is even necessary?
Still some wonkiness when everything is locked down - looks like the top menu for a locked down user still shows Database / Workflows / Forms.
The Database link is just a 403 message, so it would make sense to remove it completely anyway.
You can nav to Workflows and looks like you can start creating them, another thing that would be good to remove since you can't really get anywhere, but I didn't test too much. Since there's ability to run JS here, who knows what's possible.
I'm glad you were able to find the Additional tab where you can configure permissions for viewing account details & the query library Currently, our permissions model is additive, so we want to make the tab accessible to users who have access to Workflows / QL / Database if they're in a group with Universal Use+ access to them or Use+ access to at least 1 Workflow / App.
Still, this is all great feedback! It definitely makes sense that you may want to block a lot of these options all together. I'll check internally to see if we're already working on any of these issues, and, if not, I'll create some internal feature requests
@Tess - we ran into the same issue, though adding on notbrain's number one, if you want to invite a user to a single dashboard that uses shared queries from the query library you have to set Query Library access to "Use queries in apps".
This works at first and doesn't add "Query Library" to the top nav, but if a user navigates to "/querylibrary" or searches for it using universal search they have permission to see and execute all shared queries manually.
This feels like a bug given the name of the setting - "use queries in apps". Do you know if this will be resolved?
@Tess Thanks for noticing! The main gripe I have with some of these settings is that they are open by default, and not locked down by default, so it creates work to make sure that security is in place, instead of work to make sure access is in place.
It would make more sense from a security posture to have the All Users group not override more restrictive groups (or any group for that matter). The way it is now, you can create a new group and believe everything is locked down, when other more permissive groups (however many there are) could undermine your new group's settings. It's MUCH easier and desirable to have someone complain that they can't see something they're supposed to versus them being able to see everything!
It should take work to give new users access, not to provide it by default, especially with the new Portal for external users approach.
Currently, our permissions model is additive, so we want to make the tab accessible to users who have access to Workflows / QL / Database if they're in a group with Universal Use+ access to them or Use+ access to at least 1 Workflow / App.