URL parameters
Last updated
Last updated
A URL parameter is a piece of information that you place in the browser's URL. They follow a structure and can hold many different types of data.
Every page in your application (except for the index page) has its own URL that follows a regular pattern:
or if you have connected to a domain:
This points the browser to the right domain and to the right page. The information in that URL is actually an instruction to the server to send the correct page back to the browser. In other words, your browser sends that URL to the server, which responds by sending back the files needed to display the page.
URL parameters also serve a function, but instead of talking to the server they can send messages to the current page. In other words, your Bubble app can write and read URL parameters in the browser's URL bar and use that information for different purposes.
URL parameters are listed after the complete page URL, and are separated from that URL with a question mark (?). If there are multiple parameters, they are separated from each other with an ampersand.
Each URL parameter consists of a key and a value:
The key identifies the parameter with a unique string of text such as name
The value is the data that the parameter holds, such as John
The structure would then look like this:
If we place that in the full page URL (and separate it from the URL with a ? as we explored earlier) we get:
Now to add slightly more complexity, let's change the name parameter to firstname and add a second parameter called lastname.
In this last example, Bubble would be able to identify the full name John Doe from the URL bar. Let's have a look at how that happens.
Note: There are some plugins that can manipulate the browser's URL bar, including its parameters. It's worth noting that Bubble does not always catch updates to parameters if they are not made with the Go to page action. Recognizing the change may require a page reload or the plugin may be able to return an updated value.
As we've covered, the URL parameter consists of a key and a value, and we need to instruct Bubble what key to look for in order to get the value in return.
To do that, we set up an expression where we use the Get data from page URL .
After picking the data source, Bubble will ask for some additional parameters:
The first one is the key to identify our parameter. We want to fetch the first name (John), so we'll set that to firstname.
Secondly, we need to tell Bubble what kind of data to expect. We can set this to text.
As soon as you set the key, you can see on the right side that Bubble updates the expression to say Get firstname from page URL.
If the parameter name=John exists in the URL, the text element will show the name John to our users. If the URL parameter can't be found or has an empty value, it will display nothing.
In the example above we used the text data type to read a simple piece of information: a name. But URL parameters can also be used to read other types of data.
Bubble's general data types (text, numbers, dates, etc) need particular formatting in order to ensure compatibility with all browser.
Bubble automatically applies the correct formatting in most cases, but if you have hardcoded links or want to learn more about how the different data types are formatted, check out the info-box below.
You can also link to a custom data type in a URL parameter. To read and retrieve the correct thing, that thing's Unique ID needs to be present in the parameter. The name (key) of the parameter does not affect the result, but when you use the Get data from page URL data source you need to set it to the correct data type, as exemplified below:
First we set the name (key) that identifies the right parameter
Then we set the type to the data type of the thing we want to retrieve
Bubble then lets you add operators to the Get data from page URL data source relevant to that thing. In the example we are getting the name of the Task.
The URL in this case would look like this:
You can also retrieve an option from an Option set. Option sets do not have Unique ID's but are identified by the value stored in the Display field. Just like with data types, you can give the parameter an arbitrary name, but you need to set the type to the Option set you want to retreive.
First we set the name (key) that identifies the right parameter
Then we set the type to the Option set we want to retrieve
Bubble then lets you add operators to the Get data from page URL data source relevant to that Option set. In the example we are getting the abbreviation of the State.
The URL in this case would look like this if we included the state name in the Display field:
There are two ways to pass URL parameters to a page:
The first is to include it with the URL when the page loads, for example by linking to the page with a URL that includes the parameters. Simply copy/pasting the URL into a link will have Bubble recognize the parameters on page load.
The second is to use the Go to page action and checking Send more parameters to the page. This will apply the necessary encoding to whichever information you provide and send the parameter.
The Go to page action does not reload the page if you are going to the same page that you are already viewing. This means you can set and change URL parameters as much as needed without the page having to be reloaded.
You can only pass one value at a time in each URL parameter (but you can create as many parameters as you need, within the maximum URL length supported by the browser). There may be workarounds to pass lists, but it's not officially supported by Bubble at this point.
URL parameters are not insecure by and of themselves, but they can require that you understand the potential vulnerabilities associated with using them. For example:
They are fully editable by your users, meaning that they can add, remove and change URL parameters as they want.
They are of course also fully visible in the browser's URL bar, meaning that they should never contain any sensitive data
When used for navigation, keep in mind that a tech-savvy user can pay attention to the URL parameters and understand their structure: if you don't secure your navigation in other ways the user may be able to access sections they are not supposed to
When including custom data types in the URL, you are revealing the Unique ID of that thing. Again this is not a vulnerability on its own, but can lead to vulnerabilities. Someone could for example replace the Unique ID in the URL to see a record that's not their own: the things needs to be protected with Privacy Rules
