Sharing apps publicly with the EOTI group allows you to extend your Quickbase apps deep into an organization or externally to your customers, but it also introduces risk. This article explains how to reduce the risk of opening your app to the EOTI group.
In this article
Set up and use secure public links
Secure public links provide a URL with an access key and limit information that anonymous users can access. Set them up by creating formula fields and custom rules in your app. When you share them, anyone with that link may access that specific part of your app. Learn more in Secure public links.
Use IP filtering
Disallow access to any Quickbase app from any network except your trusted network using IP filter rules (available in certain plans), only allowing the IP address or networks you define. For example, limit access to the app from only the corporate network or VPN.
This is useful for cases when you want to collect form submissions from internal staff who are not Quickbase users. In this way, your EOTI form is only available internally, not on the Internet.
Use custom role permissions to allow access to records
Important: Table permissions for roles allow you to hide parts of the UI and some data. Hiding data is not the same thing as securing data. Use custom rules and roles to truly secure data.
Here are some ideas about how you can use custom table-specific permissions to secure data. One risk when sharing apps publicly is the ability to view parent records from child records. Use one or more of the following rules to limit the view of the parent record:
-
Do not show the parent record when a child record has not been submitted (using a summary field)
-
Make a child record available for a limited period of time by using a formula-duration or formula-numeric field, for example, only within two minutes of the record being created
-
Do not show the parent record until another event is completed, such as selecting a checkbox field on the record
You can also use a combination of formula fields, and custom permissions to create cascading permissions. Cascading permissions are a powerful building technique that allow you to fine-tune the data available to certain roles. In its simplest form, it involves:
-
Creating a field to evaluate against
-
Adding that field as a lookup or summary field to related tables where you want to run the same evaluation
-
Making data available based on the field you’re evaluating against by using a custom rule on all tables involved
Cascading permissions can apply to any role in your app. By using this technique when sharing apps publicly, you can make sure that anonymous users see only what they need.
API usage with the EOTI group
Different architectures support accessing data via our API, including:
- Client-side
- Service-side
Client-side architecture refers to JavaScript pages that are created inside of a Quickbase app. While the pages are stored in Quickbase, the code runs in a user’s browser. These solutions are lightweight, fast, and easily deployable but do not have the security or durability of server-side solutions.
Server-side solutions refer to a scenario where a developer creates a solution, sometimes referred to as a portal, that is hosted and run on a third-party infrastructure. The infrastructure is not owned, maintained, or visible by Quickbase. This will be denoted by having an alternative domain where the portal is accessed.
Because JavaScript runs in the browser, the same security concerns and risk mitigation techniques that apply to using the EOTI group should be followed. All guidance for native use of Quickbase (both acceptable and non-acceptable) applies when using JavaScript pages that call the Quickbase API.