# Privacy rule based on Current User's email address not possible **URL:** \ **Category:** Need help\ **Created:** [October 23, 2024, 9:26am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299 "2024-10-23T09:26:36Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![michael.bond](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@michael.bond](https://forum.bubble.io/u/michael.bond)\ **Post date:** [October 23, 2024, 9:26am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/1 "2024-10-23T09:26:36Z")
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. ![image](https://us1.discourse-cdn.com/bubble/original/3X/e/9/e96c7431fb9bb4f038423b6975fc95c12d407ead.png) 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. Thanks ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [October 23, 2024, 9:50am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/2 "2024-10-23T09:50:20Z")
The User field on your other Datatypes should be of type User. The your privacy rules can be when This Thing’s User is Current User. So just update the data to include the a User field on the relevant datatypes. ---
**Author:** ![michael.bond](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@michael.bond](https://forum.bubble.io/u/michael.bond)\ **Post date:** [October 23, 2024, 10:10am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/3 "2024-10-23T10:10:18Z")
Thanks, so essentially there isn’t a way around it. Because I wrongly assumed this was possible, there’s now a fair amount of logic and workflows to change annoyingly - but that’s on me. I do wonder WHY this isn’t possible though, oh well - will remember for the future. Thanks for your reply. ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 23, 2024, 12:30pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/4 "2024-10-23T12:30:52Z")
> [@michael.bond](#): > > Been working to securing my apps data server side, Good on you > [@michael.bond](#): > > there’s now a fair amount of logic and workflows to change annoyingly - but that’s on me. What’s your use case? As @adamhholmes points out, it’s likely that you should be relating data by the User type, not an email (text). ---
**Author:** ![michael.bond](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@michael.bond](https://forum.bubble.io/u/michael.bond)\ **Post date:** [October 23, 2024, 1:26pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/5 "2024-10-23T13:26:04Z")
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. ---
**Author:** ![boston85719](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/boston85719/32/77286_2.png) [@boston85719](https://forum.bubble.io/u/boston85719)\ **Post date:** [October 23, 2024, 1:50pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/6 "2024-10-23T13:50:07Z")
> [@michael.bond](#): > > where I’ve aimed to speed up development by building first, then returning the restrict them - probably not the right approach! 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. > [@michael.bond](#): > > 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. 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). > [@michael.bond](#): > > 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. 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’. ---
**Author:** ![michael.bond](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@michael.bond](https://forum.bubble.io/u/michael.bond)\ **Post date:** [October 23, 2024, 2:16pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/7 "2024-10-23T14:16:27Z")
> [@boston85719](#): > > 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… Thanks for the explainer. 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. ---
**Author:** ![boston85719](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/boston85719/32/77286_2.png) [@boston85719](https://forum.bubble.io/u/boston85719)\ **Post date:** [October 23, 2024, 3:24pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/8 "2024-10-23T15:24:15Z")
> [@michael.bond](#): > > “you must have privacy rules setup before going into production, no ifs or buts”. This is good advice. Before you deploy to live (ie: before going into production), you should implement your privacy rules and test against them. ---
**Author:** ![GH5T](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/gh5t/32/209141_2.png) [@GH5T](https://forum.bubble.io/u/GH5T)\ **Post date:** [October 24, 2024, 9:31am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/9 "2024-10-24T09:31:07Z")
> [@boston85719](#): > > 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. 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. ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 24, 2024, 9:52am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/10 "2024-10-24T09:52:55Z")
> [@GH5T](#): > > IDK bout you guys, but this is opinionated I believe. 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. ---
**Author:** ![randomanon](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@randomanon](https://forum.bubble.io/u/randomanon)\ **Post date:** [October 24, 2024, 10:19am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/11 "2024-10-24T10:19:13Z")
> [@michael.bond](#): > > 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. A hacker could do this, that’s why you have privacy rules. ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 24, 2024, 10:22am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/12 "2024-10-24T10:22:03Z")
> [@michael.bond](#): > > 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. 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. ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [October 24, 2024, 10:32am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/13 "2024-10-24T10:32:23Z")
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. ---
**Author:** ![michael.bond](https://avatars.discourse-cdn.com/v4/letter/m/858c86/32.png) [@michael.bond](https://forum.bubble.io/u/michael.bond)\ **Post date:** [October 24, 2024, 10:55am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/14 "2024-10-24T10:55:39Z")
> 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. Couple that with the ability to see the db schema using this tool, I bet you could scrape a hell of alot of data out there that you shouldn’t really be able to access. [https://forum.bubble.io/t/give-me-a-url-and-ill-visualize-your-entire-database](https://forum.bubble.io/t/give-me-a-url-and-ill-visualize-your-entire-database) I’m glad for asking, and thanks for all the replies - given me a better understanding how to build going forward. ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 24, 2024, 10:59am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/15 "2024-10-24T10:59:40Z")
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. ---
**Author:** ![boston85719](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/boston85719/32/77286_2.png) [@boston85719](https://forum.bubble.io/u/boston85719)\ **Post date:** [October 24, 2024, 11:00am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/16 "2024-10-24T11:00:24Z")
> [@GH5T](#): > > IDK bout you guys, but this is opinionated I believe The phrase ‘in my mind’ indicates an opinion. > [@georgecollier](#): > > The number of bugs that must slip through when adding them later! None, when tested properly. That would be the point of testing before deploying to live. > [@georgecollier](#): > > 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) 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. > [@georgecollier](#): > > but if you add them later you’ve got to go over every possible user interaction to check it still works. Solid testing to ensure no crazy mistakes are made in a live app like deleting other user data. > [@adamhholmes](#): > > it requires the entire app to be tested again to make sure the new privacy rules haven’t broken anything. 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. ---
**Author:** ![adamhholmes](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/adamhholmes/32/100510_2.png) [@adamhholmes](https://forum.bubble.io/u/adamhholmes)\ **Post date:** [October 24, 2024, 11:49am UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/17 "2024-10-24T11:49:28Z")
> [@boston85719](#): > > 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. That’s a good point… 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). ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 24, 2024, 12:01pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/18 "2024-10-24T12:01:14Z")
> [@adamhholmes](#): > > 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. Yeah this is wack and a pain for maintainability. 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. ---
**Author:** ![randomanon](https://avatars.discourse-cdn.com/v4/letter/r/8491ac/32.png) [@randomanon](https://forum.bubble.io/u/randomanon)\ **Post date:** [October 24, 2024, 12:29pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/19 "2024-10-24T12:29:06Z")
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. ---
**Author:** ![georgecollier](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/georgecollier/32/182327_2.png) [@georgecollier](https://forum.bubble.io/u/georgecollier)\ **Post date:** [October 24, 2024, 12:36pm UTC](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299/20 "2024-10-24T12:36:05Z")
![CleanShot 2024-10-24 at 13.33.35@2x](https://us1.discourse-cdn.com/bubble/original/3X/f/8/f8e29c9302d1fcc8dc9091c4615d7e5e002a1cc0.png) Big value-adds are: - privacy rules (handles data that is supposed to be public effectively too so won’t flag public listings in a marketplace for example) - page redirects (assesses if a page should be private, takes into account that content may be hidden on page load even if no server side redirect) - public backend workflows (identifies exploitable backend workflows e.g ‘sendemail’ that takes an email address and content parameter - known insecure plugins - leaking data in API calls, including API keys or user data - sensitive data stored in option sets It’s just a one time audit vs Flusk which focuses on ongoing monitoring. All of this without collaborator access. [Next page](https://forum.bubble.io/t/privacy-rule-based-on-current-users-email-address-not-possible/345299.md?page=2)