I was wondering if its actually safe to expose unique IDs of database items in the URL? like if i have a users profile page, should i expose it in the URL? or do somehting like add a token to the user and then send that to the URL and display data in the group by searching for a user that matches that token? it seems safer but consumes a search everytime.
Im a first time bubbler so im really worried abt Workload usage. dont want to run out of that so im trying to be careful. whats the best way to do this? also are there any tips to avoid heavy WLU usage?
Honestly for a profile page you don’t need to put anything in the URL at all. Just set the page’s content type to User, and when you navigate to it pass “Current User” as the data. Bubble handles it cleanly, nothing gets exposed, and you’re not burning a search every time the page loads.
Shouldnt the URL contain some form of indentification for the profile just in case? if internet breakds down temporarily or page reloads or refreshes etc?
EDIT: I guess my wider question is, is exposing Unique IDs in URL safe and common practice? if not whatre the alternatives
Yeah fair point, if the page refreshes and there’s no URL param Bubble just loses the data and the page breaks.Just use the unique ID directly, it’s fine. Bubble’s privacy rules are what actually protect your data, not whether the ID is visible in the URL or not. Set those up correctly on the User datatype and you’re good, no need to overcomplicate it with tokens.
Im a first time bubbler so im really worried abt Workload usage. dont want to run out of that so im trying to be careful. whats the best way to do this? also are there any tips to avoid heavy WLU usage?
Welcome to bubble! It’s a really powerful platform and if you invest time to learn it deeply it will be rewarding.
When I first started with WUs I was very concerned about burning though them fast - but in reality, the fears were unfounded. (Of course it depends on what you are building). If you keep an eye on the wu analysis tool you can then dig into areas of concern and look for more efficient ways to build them. I recommend trying buildprint at some point too - you can simply ask it questions such as “please look at my workflow and let me know if you can suggest a more elegant & WU efficient way to build it”. It’s really good.
Two ways, you can use the page content type and then have unique id or slug as url path list item and bubble automatically will do an individual data item request to fetch it.
Second, do URL parameter approach with unique id, but you must set the url parameter type to the data type the unique id is for, and when you do that, it’s a unique data request, no need to do a search.
If you use url parameter and are doing a search you’re wasting WUs, so ensure you set the parameter type.
Also, be careful when using AI systems for Bubble, especially around WU stuff. An LLM will not without explicit instruction search for bubble current pricing policies, nor will it easily discern what are alternative approaches to get the optimized for WU approach to most tasks in Bubble.
If you want real insights from real experienced developers, search the forum for those gold nuggets, because even something as simple as setting the URL parameter data type to use only 0.015 WUs to get the correct data entry versus using a search and using 0.3+ WUs is likely not getting surfaced by an LLM.
Ah okay. I get the efficiency bit. But what about security ? So if all my privacy rules are water tight and my page logic is sound too then if a random person gets a hold of any unique IDs of users or anything as such, can they harm the app in anyway ?
Also is it safe to run backend workflows while ignoring privacy rules ? If not then how are we supposed to make changes to database items if they have privacy rules on them considering backend workflows don’t have a “current user” logic. Thanks.
No. Is long as you have well-structured privacy rules, exposing Unique IDs shouldn’t be a problem.
In some cases, the user needs to trigger an operation that depends on querying records they should not have direct access to. That’s why we run these routines on the server side, instead of directly in the browser/frontend.
In those controlled cases, we need those workflows to ignore privacy rules. Otherwise, even though the workflow is running on the server side, where the user won’t have access to the underlying data, it would still result in an error precisely because of the privacy rules. In server-side workflows, the Current User is the user who initiated the workflow.
