Trusting client side element data

Had a read through the documentation on client side and server side processing however I’m still not 100% clear.

My question is essentially, can I trust data from a repeating group? My assumption is probably not since it’s a client side element and could potentially be changed(?), but then I have questions around how best to retrieve data from the repeating group, safely.

Apologies if this is already explained in the documentation somewhere, I’m still fairly new to Bubble.

Thanks
Michael

It depends on how you are extracting information from this repeating group and what elements are present in it… For example, if you are extracting information from text inputs that are in these repeating groups, your users will be able to change the information.

But in general, repeating groups are only used to visually organize information from your database…

Can you clarify your use case?

3 Likes

It is safe to assume that every single piece of data from the frontend can be manipulated. Not only inputs but litteraly everything.

I am not aware of any way of ensuring that the frontend data is correct, so when this becomes a matter you need to rely on backend workflows that work in a close circuit.

2 Likes

Thanks for the reply.

Say for example I want to update records in my database table (app data) and I want to update it from information in my repeating group (which the user can’t change via a textbox input).

There is a datasource for the repeating group.

In my workflow for this, behind the scenes taking the example above, does it work like this:

Bubble takes data from clientside for the repeating group → Update records

OR

Bubble takes data from data source for the repeating group → Update records

If it’s the former then you can see how a user might be able to change the repeating group data.

I expect it works by the latter, looking at the data in the datasource - but just want to check before trusting the data.

Your frontend RG probably does a search to get its data.

So you’ll want your backend workflow to do the exact same search on its own. So the backend is totally autonomous.

1 Like

Exactly…

Thanks both, so essentially you shouldn’t do what I’ve done here…

Bind a RP data source to button state

Then when it comes time to save those records in the repeating group I’ve done this in my workflow:

image

Instead I assume the RP should be bound to a data type?

Just trying to ensure the app is secure.

Sorry if this is an obvious one, still learning the system - the layer of abstraction that no code provides is both a blessing and a curse, I’ve found so far

What does your flow do with the input email?

It gets a user email input, does it get more data?

No more data to retrieve, it calls a recursive backend workflow which saves each of the email address to a datatype (table)

image

Well if the backend workflow does nothing more than creating things sent from the frontend, then this is exactly the same as creating these things from the frontend.

But I guess right now you might probably be at the beginning of your project and later on you’ll add more actions to the backend, for instance checking the length of the email addresses and also checking the formatting using regex for instance.

1 Like