If you’ve ever used JavaScript to modify UI or enable a non-native workflow in a Quickbase app, this post is for you. We know that adding custom code to an application can be a valuable way to extend Quickbase. However, we need to provide this capability in a secure and supportable way. To that end, Quickbase provides the ability to use custom code in code pages. On the other hand, we also see builders inserting custom code into places it was never intended to be used. To improve the security and stability of the platform, we are changing the way Quickbase handles custom code. Specifically, we are changing how the platform handles JavaScript and unsupported HTML tags in places other than code pages. Code pages are where custom code has always been supported, and we encourage app builders to insert it there. We will roll out these changes throughout 2021. This post will cover the background on where custom code is supported in Quickbase, and why it’s important for us to make a change. You can also find details about our plan below, and how that impacts you.
Table of Contents
Background
For years, Quickbase builders have inserted JavaScript outside of code pages. This has been done to customize the UI or to automate workflow (such as reloading the current page). Yet custom code such as JavaScript was never intended to be used in a Quickbase app, except in code pages. Builders have shared many solutions like this on our community forum. You might see them called "Image OnLoad" or "Branding OnLoad".
Because the added JavaScript code cannot be sanitized by Quickbase, it could open a security vulnerability that a sophisticated, malicious, builder could take advantage of. “Sanitizing” is simply making sure that an input into a field is what the software intended. For example, to sanitize a field that says “Image URL”, we would ensure it only accepts a format like https://mywebsite.com/images/banner.png and that it only contains secure content. None of the code within a code page can access the native Quickbase document object model (DOM). When you write custom code such as JavaScript in a code page, you are creating a new web page from scratch. This is why it is more secure to restrict JavaScript to being used only in a code page
The Quickbase platform includes many security measures which protect you against the risks mentioned above. For example, when you create a new app, any API call pointed at that app must include an application token. We have put in place policies to control cross-origin resource sharing (CORS). And we allow realm admins to restrict what type of content may be embedded as an iFrame within their apps. But the work of building a platform with world-class, enterprise grade security never stops. Our software engineers and system architects are always searching for opportunities to improve. Changing how JavaScript is handled in Quickbase apps is the next step in that journey.
Besides this security issue, it's impossible for us to test inserted JavaScript as we make changes to the Quickbase platform. A routine upgrade to an open source library, a change to styling, or to the DOM may cause these custom solutions to break without warning. As we progress with projects like the UI Refresh in 2021 and beyond, these kinds of changes will become more frequent.
In order to move the platform forward in a safe, secure, and sustainable way, we must close the loopholes that allow builders to insert unsanitized custom code into their apps.
Upcoming Changes
There are three areas of the product that need to have the loophole closed. We will close one area at a time, every two months starting in April 2021.
- Rich Text Fields, where customers could unintentionally allow end users to insert JavaScript. This area was closed in the April 2021 release. Note: This does not include Formula-Rich Text fields.
- Custom Branding, where customers typically insert JavaScript to modify the UI in non-native ways. This area was closed in the June 2021 release.
- Formula Fields, where customers can write scripts to automate workflows. Examples of these include cascading deletes and executing multiple actions when a user presses a button. This area will be closed in the August 2021 release. This includes Formula-Rich Text fields.
When an area is closed, builders will no longer be able to insert new JavaScript or edit the JavaScript that has been inserted into the area. With these series of changes, we will not remove or modify any existing custom code. We will not intentionally break any existing solutions that leverage these techniques. But a change to styling, a change to the DOM, or an update to a technical library could cause a solution to unintentionally break without warning. And, if a solution breaks for one of these reasons after the area has been closed, builders will not be able to edit the JavaScript to fix it.
After we close each loophole, builders will no longer be able to insert or update JavaScript in that part of their apps. For example, imagine you have a formula that contains JavaScript. You need to update the formula, so you open the field properties. In that case, we would pop up a message warning that the field contains unsupported content. If you click Save without removing the JavaScript, you will see an error message preventing the save. You may hit cancel at that point, to back out and keep the previous configuration of your field.
We encourage you to continue extending your ecosystem of apps using custom code. You can use custom code such as JavaScript in code pages, even after we close all the loopholes above.
NOTE: The vast majority of custom code that's inserted into Quickbase apps outside of code pages is JavaScript code. However, the product changes above will not just restrict where JavaScript can be used. Those restrictions will apply to all custom code that is unsupported outside of code pages. The only custom code that may be used outside of code pages is:
- Simple HTML tags such as "a", "div", and "img". (See a complete list of supported HTML tags)
- Any native HTML attributes for those tags. (Such as the "width" and "height" attributes of the img tag)
- CSS style code which is included in-line, as part of one of the supported HTML tags above
As a reminder, iFrame HTML tags are not supported outside of code pages and they will be affected by the product changes above.
Product Alternatives
Many agile companies extend their Quickbase apps today using custom code. This is a crucial tool for flexing and adapting to a fast-paced business environment. The intended workflow for Quickbase to interact with custom code is by having a formula-url or formula-rich text field as a button or link. Clicking on one of these would open a new browser tab, or redirect the current tab, to the code page. Custom HTML, CSS and JavaScript can be included in this code page. If desired, the page can close itself and redirect to the original page. For example, see the animation below:
We will also work to make this even easier in the future. Over time, we will address the majority of extensibility needs in a few ways:
-
- Our ongoing product initiatives have an increased focus on customization and power natively. We know will not be able to build a native setting, switch or toggle for every possibility. Yet we conduct research and make data-informed decisions on where more flexibility makes sense.
- We will continue to absorb small items into future product iterations that customers need so custom code isn’t needed. Examples of this include, but are not limited to:
- Ability to use Now to get the live time a formula-url was pressed, rather than when the first page loaded
- New formula functions like UserRoles() and NameOfMonth()
- More control over the behavior of formula-urls
- Allow app builders to use JavaScript in certain areas outside of Code Pages. These would not allow arbitrary code to be inserted. Instead, they would support specific methods of extending a Quickbase app with custom code. For example, let's consider the new dashboards in beta as of February 2021. These new dashboards allow app builders to create filters which apply to all reports and charts on the page. We could allow a developer to create a custom chart type, which connects to the dashboard filter. So when an app user clicks that filter, all the reports and charts on the dashboard would update - including the custom-coded charts. This would allow builders to create their own chart, and have it behave natively and seamlessly for their users. We have many plans in this area. While this is not an overnight deliverable, we are confident in the research we have done and our roadmap to deliver on this promise.
Programming languages like JavaScript are powerful because they are open-ended. You can use JavaScript to solve virtually any problem if you have the time and technical know-how. But Quickbase is a no-code platform. Quickbase is powerful because of how fast it allows you to build and update apps, deliver value and unlock insights within your data. So we will always focus on accelerating that speed and ease of use. We do not intend for Quickbase to become a full-fledged integrated development environment (IDE).
Next Steps
First, we want to be as transparent as possible, so app builders are aware of any risks in their applications. To that end, builders will begin seeing a warning in areas that have unsupported content in the near future. This will not prohibit changes to these areas of the platform.
Are you already thinking about some of your apps which use these JavaScript techniques? If so, please start planning how you can migrate to supported solutions. We have been logging Quickbase apps that contain unsupported custom code. Those logs are only able to cover apps where you've updated the app’s structure recently. So if you have an app you're unsure about, you can update the properties of any field or table to get it added to the logs. That way, if that app does contain JavaScript or other types of unsupported custom code, it will appear in the logs the following day. On February 11th, we'll send an email inviting account admins to a Quickbase app so you can see where inserted JavaScript is being used. If your account admin does not receive that email, it means that our logs do not show any inserted JavaScript in your account.
Review the list of FAQs below. If you still have questions or need help, don’t hesitate to reach out to our Care team by submitting a ticket. We're happy to help identify alternative solutions. However, please note that we will not be able to interpret or troubleshoot custom code. If you find yourself in need of more hands-on assistance, we recommend engaging with one of our QSPs, whom we can help you connect with.
FAQ
What is JavaScript Insertion?
JavaScript Insertion occurs when custom JavaScript code is added to any part of a Quickbase app other than a code page. Some examples include formula fields, rich text fields, and custom branding. While officially not supported, these techniques are used to more deeply customize an app’s UI or workflow. While this has never been officially supported, the platform was not explicitly blocking this as it should have been. As we have added features to the platform over the years, many of the reasons why these techniques were used have become obsolete.
What is changing with regards to JavaScript Insertion?
We will begin restricting app builders from inserting JavaScript in formula fields, app branding, and rich text fields. Builders will no longer be able to insert new JavaScript code in those areas. We will also block edits to any existing JavaScript in those same places. These areas were never intended to allow for JavaScript insertion. You can still insert JavaScript in a Code Page, which is the appropriate place in a Quickbase application.
Will these changes only affect inserted JavaScript code?
The vast majority of custom code that's inserted into Quickbase apps outside of code pages is JavaScript code. However, the product changes above will not just restrict where JavaScript can be used. Those restrictions will apply to all custom code that is unsupported outside of code pages. The only custom code that may be used outside of code pages is:
- Simple HTML tags such as "a", "div", and "img". (See a complete list of supported HTML tags)
- Any native HTML attributes for those tags. (Such as the "width" and "height" attributes of the img tag)
- CSS style code which is included in-line, as part of one of the supported HTML tags above
As a reminder, iFrame HTML tags are not supported outside of code pages and they will be affected by the product changes above.
When will these changes take place?
Throughout a series of releases in 2021. After the April 2021 release, users will no longer be able to insert JavaScript into Rich text fields. After the June 2021 release, users will no longer be able to insert JavaScript into Custom Branding. After the August 2021 release, users will no longer be able to insert JavaScript into Formula Fields.
Why do we need to make these changes?
Custom JavaScript inserted into these areas is not sanitized by Quickbase. This opens the platform up to potential attacks from malicious users, to modify pages or gain access to protected data. Such custom code is also impossible for Quickbase to test. This means routine changes to the platform could (and do) cause a solution to break without warning. Closing these loopholes allows us to provide a more supportable, enterprise-grade platform. It also enables our support resources to triage and troubleshoot more effectively.
How are we informing customers of this change?
On February 11, 2021, we will email Account Admins who will be affected by this change. The email will include a link to a Quickbase app which will help you locate inserted JavaScript in your apps. We will email those Account Admins before we make each of the product changes above. Those changes will take affect with our product releases in April 2021, June 2021, and August 2021. Application Managers will also see warnings in apps that include inserted JavaScript. For example, a message will appear if you edit the properties of a formula that includes inserted JavaScript.
What will happen with existing JavaScript solutions?
We will not be making any changes to existing objects that contain inserted JavaScript at this time, or during any of the releases mentioned above. That means that solutions that leverage inserted JavaScript should continue to work as they were designed. However, builders will not be able to save changes to these objects after their respective release. After the April 2021 release, you will not be able to make changes to JavaScript within Rich Text fields. After the June 2021 release, you will not be able to make changes to JavaScript within Branding. After the August 2021 release you will not be able to make changes to JavaScript within Formula fields. As always, these solutions might break as a result of a routine change we make to the Quickbase platform. For example, upgrading a technical library, or changing either our styling or our Document Object Model (DOM) could cause inserted JavaScript to stop working.
What will happen if a builder attempts to save changes to an object with inserted JavaScript?
After we close each loophole, builders will no longer be able to insert or update JavaScript in that part of their apps. For example, imagine you have a formula that contains JavaScript. You need to update the formula, so you open the field properties. In that case, we would pop up a message warning that the field contains unsupported content. If you click Save without removing the JavaScript, you will see an error message preventing the save. You may hit cancel at that point, to back out and keep the previous configuration of your field.
What will happen if I copy an app with inserted JavaScript?
Customers should be able to copy applications with unsupported JavaScript. The inserted JavaScript will carry over to the copied app. As with any inserted JavaScript, after we close down the area it is inserted in, builders will not be able to edit it.
Should I remove all inserted JavaScript from my Quickbase apps?
We are not removing or modifying any existing inserted JavaScript. You can continue to use your apps that contain inserted JavaScript. But, while we are not intentionally breaking any solutions that rely on inserted JavaScript, these solutions could break as a result of a routine change to the platform, like a change to styling, an upgrade to technical libraries, or a change to the Document Object Model (DOM). As we progress with the UI Refresh Initiative, these changes will become more frequent, increasing the chances that your apps could break. If you want to avoid that risk, you should explore alternative, supported solutions to the problems you’re solving with inserted JavaScript.
What if I need help?
If you’re still not clear on exactly what is changing, or have a specific question about your account, you can always submit a support case to our Care team. Also, our Quickbase Solution Providers (QSPs) are a network of professional services firms that you can contract with to help you plan for and execute any changes to your apps that you might deem necessary as a result of this announcement. They can help you identify and implement alternative, supported solutions to the problems you currently solve with inserted JavaScript.
If you are working with a QSP already, you can follow up with that partner or find a potential partner here. We also have a list of partners who are providing services offerings to specifically handle JavaScript issues. If you would like a referral to a partner or potential partners, submit a support case, and a support representative can provide this for you.
Can builders still insert JavaScript into code pages?
Yes, users are encouraged to use code pages to leverage custom code for their Quickbase applications. These code pages should be used standalone, rather than attempted to be “injected” into a Quickbase page.
What if I need help identifying my inserted JavaScript?
The first place to look is the Inserted JavaScript Usage app. This is a Quickbase app that lists where inserted JavaScript is used in your apps. It includes details such as Field ID for formulas that include inserted JavaScript. On February 11, 2021, we will email a link to this app to Account Administrators. We will send this email only to accounts we've detected are using inserted JavaScript. Not sure whether a specific app includes inserted Javascript? You can check this by opening the app in question, then making any schema change. For instance, you could add a new field or update the properties of an existing field. Then, you can check the Usage app one day later. We update the Usage app daily. So if the app in question still does not appear in the Usage app then you do not need to take further action.
