Been working to securing my apps data server side, something that’s been bothering me for a while is that there doesn’t appear to be anywhere of saying:
This object’s field is Current user’s email
The parts I’ve hidden below just include my custom added data fields, not the default ones.
Didn’t know this as a beginner, so in a lot of my table design I’ve inserted user’s email addresses as text fields - instead of the user object.
Is there any workaround for this? I don’t want to do something whacky like duplicate the email address for the users in another datafield if there’s a better solution.
My use case is that I have a bunch of data types with publicly visible privacy rules on them where I’ve aimed to speed up development by building first, then returning the restrict them - probably not the right approach!
In a few of my tables design I’ve included a text data type containing the email address of the person who should only be able to see said record.
In my clientside elements such as repeating groups, I’ve always ensured “do a search for” contains constraints that limit the data the user can see - my lookups almost always contain a constraint for user = current user’s email.
For some extra protection I want to retrospectively go over my data types so that server side it will never return another customers data.
For example, if I made a mistake in one of my “do a search for” for forgot to add the correct constraint, I want to always ensure customer X can only see customer X’s records - so it’s blocked server side if said mistake was made.
Bit of peace of mind really, hopefully that’s the correct approach - I’m still fairly new to bubble.
It is absolutely the right approach in my mind and should be a best practice followed by every developer as it does speed up development time as it removes slow downs caused by silly privacy rule errors, such as not logging in while testing. Also reduces the chances that other mistakes do not go uncovered prior to deploying to live.
If you set these up properly before implementing privacy rules, or at least do proper testing and debugging prior to implementing privacy rules, this will not happen anyway…best way is to use ‘current user’ and not some text field representing email address. In Bubble, all roads lead by to user…this is because every single data type has a built in field of ‘creator’ which is related to User data type. The created by field should not always be utilized though since there are use cases of a need to have another field, like ‘user-owner’ that you create (for example, employee created data, when employee leaves, the data can be transferred) but also because of Bubbles’ not fully realized feature of ‘cookies’ (when a user is not logged in and is not a registered user, any data they create, Bubble properly maps the ‘creator’ field to them when they return to register within 72 hours, - however, absurdly, Bubble did not make this same functional possible for a registered user, who is logged out and comes back within 72 hours and logs into their existing account).
This should be a field that is related to User and not a text field
Your privacy rules could be either ‘this things creator is current user’ or ‘this things user-owner is current user’.
And yep, this had crossed my mind - did wonder whether privacy rules are absolutely required, when you visit most of the videos online of people teaching privacy rules the message is generally “you must have privacy rules setup before going into production, no ifs or buts”.
I did check devtools on a fair few parts of the app and at no point can my test user see information that they shouldn’t be allowed to see.
And presumably someone can’t manually send a HTTP post to https://%appname%/version-test/elasticsearch/msearch to request information they shouldn’t ordinarily be able to see, these requests need to come from the elements I assume.
IDK bout you guys, but this is opinionated I believe. Mainly because I always build with privacy first, then open as needed. Sure it takes a little longer, but it takes longer to go back and then secure your app.
Yeah, I can’t imagine building an app without building privacy rules first. The number of bugs that must slip through when adding them later! It’s generally pretty easy to tell when an issue is caused by privacy rules (so you can make the change in 2 minutes when you find it and be on your way) but if you add them later you’ve got to go over every possible user interaction to check it still works.
Yes you can, it’s like ten lines of code (though you don’t execute it from the URL you provided). Essentially you can search the DB without the data API enabled with constraints like the data API. You can access any data that the privacy rules permit you to have access to.
Yeah… building an app without Privacy rules first, then going back and adding them afterwards seems crazy to me!!! (certainly it goes against virtually ALL my development best practices), and on the rare occasion where I have done it this way (either intentionally or not), it requires the entire app to be tested again to make sure the new privacy rules haven’t broken anything.
Yes you can, it’s like ten lines of code (though you don’t execute it from the URL you provided). Essentially you can search the DB without the data API enabled with constraints like the data API. You can access any data that the privacy rules permit you to have access to.
Wow, I guess Bubble’s privacy term “publicly visible” is pretty accurate then.
I’m building an audit tool that reviews more of your app than Flusk and doesn’t need collaborator access,
it just works with publicly available info. DM me with your app URL if you want me to run it on your app so you can see what’s public and/or exploitable.
None, when tested properly. That would be the point of testing before deploying to live.
Except that the logs do not show when a privacy rule causes and issue and the debugger doesn’t show when privacy rules are the issue if the privacy rule does not allow the data entry to be found in searches.
Solid testing to ensure no crazy mistakes are made in a live app like deleting other user data.
Exactly, to ensure the privacy rules are working properly and that all other features/functions worked properly prior, meaning there is no need to use privacy rules as a crutch to avoid making mistakes in search constraints or something else that can cause the app to malfunction.
It is okay for people to have differing opinions, everybody has different approaches to life, development and we all learn differently as well. I guess I am just wired a bit differently than some other developers and the way in which I want to approach my development, makes it such that I don’t want to be bothered by privacy rules during development and I want to just test features to ensure they work, and then go back and test privacy rules to ensure they work, even if that means I have to test every user type, as in the end, it makes it so that my live app is more secure and less buggy compared to if I were to put in privacy rules first since I’m prone to not logging in while testing.
Glad everybody has their own ways that work for them.
I never like to rely solely on privacy rules to restrict what data is loaded… (that’s what search constraints are for).
I’ve seen apps that don’t use any search constraints… and just use privacy rules to restrict data to, say, only data created by the current User.
That’s fine (I guess) but if the privacy rules change at some point (or they are incorrectly set up, as is often the case), then it can cause problems.
So a combination of correct search constraints, plus robust privacy rules is best (in my opinion).
I use search constraints everywhere, build privacy rules first, and then when I do make a mistake, I get to be glad my privacy rules are set up correctly and it causes a bug rather than a data leak.
What are you looking for exactly? Would be curious to know how yours is more comprehensive. I know that there are a couple of very esoteric things that not even Flusk checks for, like having an API call set as Data instead of Action.
