[Privacy Rules] Visitors seeing User's data - best way to authenticate? 🔓

Questions
1

Hello Bubblers! :wave:

Context:

We are building an app where our clients (data type User) can share information with some friends (external).

Problem:

We are facing a question regarding the database structure.
These friends need to authenticate :unlock: in the platform for them to see the client’s information (and only that one!).
We don’t know what is the best way for them to authenticate :thinking:

Solutions investigated so far:

Data type "Friends"
  • Creation of a dedicated data type “Friends” to store information about these contacts
  • Structure example:
    Client (User) | Friend email (text) | Friend login (text - unique random string)
  • The friend receives an email with his “logins”. In the app, he is prompted to enter these logins in some inputs. Then, through workflows and conditions, groups are hidden/shown and the client’s data is displayed (the client is retrieved because of the relation “logins” > “friend” > “client”)
  • :warning: Limitation we encountered:
    • Privacy rules cannot be applied on an other data type than Users. So we can not allow a specific Friend to see information from a specific User. So the privacy rules need to remain wide open (although the page would only display a Client’s information, it could be “hacked” to retrieve all data from the database)
    • The “logins” generated for the Friend are stored visible in the database (vs a User password which is stored more encrypted by Bubble and invisible for us)
Data type "Users" (real)
  • When a Client adds a friend to the database, it creates a User for this friend
  • We can track the relation between the User-Client and the User-Friend within the data type User or in a separate data type
  • Structure example for the latest:
    Client (User) | Friend (User) | Invitation sent (Yes-No)
  • :warning: Limitations:
    • If the Friend also wants to become a Client, he already exists in the database
    • If the Friend is also a Client and he updates his logins, these changes will apply both to his Client profile and his Friend profile
    • If a Client wants to add a Friend that is already in the database (either as a User-Client or a User-Friend), we musn’t reset his logins
    • We need to store the Use-Friend’s password visible in the database: indeed, when a User-Client creates a User-Friend, this one receives an e-mail with his logins. But, if another User-Client invites this same User-Friend, we need to send him an other invitation e-mail, with the same logins (since he’s a User in the database), and so we need to store them
Data type "Users" (fake)
  • This solution is similar as the previous one, meaning that we create a User for this friend. The only difference is that we don’t use the real email of this friend, instead we set a unique fake “email”
  • Structure example:
    Fake email (as the official User email to log in) “johndoe[random unique]@[our domain].com” | Real email (custom field) “johndoe@gmail.com” | Client (User) “Paul Smith”
  • If 2 Clients add the same Friend, it will then create 2 fake Users (with 2 uniques fake emails)
  • If this friend becomes a Client, he will still be able to create a real account with his real email
  • :warning: Limitations:
    • The friend will log in with his real email (he will not know about the fake emails). Therefore, we systematically need to do the relation between the real email and the fake email (which is used to actually log in).
    • Latency: the database is clustered with fake Users.
Data API
  • In case the Friends are not Users (cf above Data type “Friends”), this solution could use a “workflow API” to retrieve data from the database.
  • We can “Ignore privacy rules” with this setup.
  • :warning: Limitation:
    • Security issue: Not quite sure if visitors can trigger any API call and so access to all Clients information.

(Click sections to see details)

:point_right: So what is the best approach here? :point_left:
(either above or other ideas)

Heads up to @allenyang @eve @neema :star_struck:

1 Like
2

Hello!

You’ll need the Friends users to sign up with the platform as well. We would recommend that you have a data field in the User type that determines whether the User in question is a “Client” or “Friend”; you can have workflows for your Clients to set up Friend-type accounts to allow the Friend accounts access to the Client’s data.

Feel free to email us at support@bubble.io if this is not enough info!

3 Likes
3

Hello @eve!

Thanks a lot for you quick reply! :slightly_smiling_face:

We will then go with the second scenario above “Data type “Users” (real)”.

We are going to explore all the implications of this solution (login, sign up, multi-clients, both client & friend, etc.) and we’ll get back to this post or the Support in case we encounter any real issue.

Thanks again!