Firebase rules for secure access without sign-in?

Questions about Thunkable
1

I know this is slightly off-topic but I’m hoping someone can help.

I want users to be able to read/write data from Firebase without having to sign in using an email address. For my meal planning app, I’d like to generate a random User ID (I’ve already done that) and then have the app sync to the Firebase node with that value. That’s working fine with the test rules that Firebase sets by default (which are wide open). How do I change them to protect users more?

Here’s my Firebase structure:

Screen Shot 2021-11-20 at 9.21.09 PM
Screen Shot 2021-11-20 at 9.21.09 PM772×496 14 KB

I’m saving the User ID (e.g. 3362-6163-7471-6933-91) in a Stored variable on the device. So when the app loads, it uses that same User ID every time. But how do I ensure that that particular user has access to only that node, in this case /Users/3362-6163-7471-6933-91/ and not all of /Users/?

It looks like this might be a good place for me to start… not sure:

https://firebase.google.com/docs/rules/basics#attribute-based_and_role-based_access

1 Like
2

I know there is a way to:
Use the login function the same, but you need some settings.
Device variable of an ID: Randomly generated for the first use. (You also need to register by the way: “you have a Gmail account+ID@gmail.com” will become a non-fake email.
Password device variable.
For example:if you have a Gmail:"abcdapp@gmail.com" and userID is “AHGK1133”
Than user email:is “abcdapp+ AHGK1133@gmail.com”
The password is randomly generated and stored for the first time.
Register and log in to this account.

2 Likes
3

^^^^ive done this before. No email verification. Can be a workable solution!

The email can literally be anyRandomValue@test.com

Password: another random string

Save both to the local storage to ensure data persistence across app updates.

2 Likes
4

rule
{"rules": {"Users": {"$user": {".read": "$user == auth.uid && auth.uid!=null", ".write": "$user == auth.uid && auth.uid!=null", }, }, } }

5

Okay but typically there’s a Sign Up block that requires email verification. How do you bypass that step?

And also with the Sign In block, wouldn’t I need to use the green User ID block instead of my custom random User ID value?

2 Likes
6

Do not judge on the login output block, but it is still recommended to use a valid email: YOURGmail+ID@gmail.com
You don’t need to use the uid it gives.

7

I’m getting an error about the Identity Toolkit API. So I went and enabled that but now it’s asking me to set up credentials for authenticating to that API. Is that required?

image
image1642×1892 299 KB

I don’t remember ever doing that for my other Firebase database which already uses authenticated sign ins (email + password).

1 Like
8

I can find the api on the project setting page on the firebase console.

9

Do you mean the Web API Key or something else?

10

Using the uid would generally allow you more security as the uid is only ever returned to the logged in user.

When does this happen?

Which block requires verification? You should still be able to log a user in without verifying their email. How else can the app tell you if they have verified or not without logging in that person anyways, right? Typically, a developer may just limit what a logged in user can do if they haven’t verified their email yet. In some cases, you may not allow them to pass the login portal at all without verification first. Just depends on your use case.

11

If I use the Sign Up block, I see this error immediately:

image

And with Sign In, I see this:

image

12

Thank you. I had the wrong API key entered in the project settings in Thunkable. I’m no longer getting the errors about the Identity Toolkit API.

13

Those rules are not working for me. Before I changed the rules, I was able to get the value from /Users/app variable user ID but now I can’t:

image
image1430×170 34.7 KB

14

This is how you login without using sing in / up block of Thunkable and can use your own single email login and then control the access from your app.

1 Like
15

It does work with these basic rules:

// Only authenticated users can access/write data
{
   “rules”: {
   “.read”: “auth != null”,
   “.write”: “auth != null”
   }
}

But not with these rules that @tony.ycy.program suggested:

{
  "rules": {
    "Users": {
      "$user": {
        ".read": "$user == auth.uid && auth.uid!=null", 
        ".write": "$user == auth.uid && auth.uid!=null", 
      }, 
    }, 
  } 
}
1 Like
16

The suggested rules assumes using the built in user id not a custom made one.

2 Likes
17

That’s what I was thinking. Do you think it’s fairly safe to use the “only authenticated users…” rules I posted right above since the user will never know their own random username and password and since there is no way to access any one else’s data from within the app?

Not to mention, there’s nothing confidential about the data… it’s really just a list of food items. :slight_smile:

1 Like
18

I believe this is a workable solution without compromising the data security. The email and password is something that you will choose yourself and for me I set verification to false and use a dummy email to use it as an app login. All other functions I control by the app itself.

Again, you can choose to use the API calls to login or use the Sign In component and provide the email and password in the code without any GUI components.

1 Like
19

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.