Do we need to change Firebase rules after 30 days?

Questions about Thunkable
1

Do we have to change our firebase project after every 30 days. This is not clearly mentioned in the documentation.

2

Can you provide a link to whatever made you ask this?

1 Like
3

Not that i know.
I’ve never touched it after creating and connecting

2 Likes
4

image
image810Ă—373 35.6 KB

Do We have to use test mode or locked mode ?

5

Locked

1 Like
6

This has nothing to do with Thunkable. Firebase is just letting you know that if you don’t set up secure rules within 30 days, they will lock your database.

1 Like
7

So you mean we have to start in locked mode and then change the rules to true( or can we do that in test mode too?)

9

Yes

No

1 Like
10

@overturner
I have my database in test mode for over a year now. I just changed the database rules and made it not date bound instead of 30 days however, my production database has different rules

11

This sentence is a bit confusing for me. :cold_sweat:

What do you mean by production db?

1 Like
12

I have my test DB and my production DB (Firebase calls them projects). When working on a project, it is connected to the test environment with minimum rules but when I move it to production then permission rules are different.

This is in my test DB

{
  "rules": {
    ".read": "true",  // 2021-2-4
    ".write": "true",  // 2021-2-4
  }
}
1 Like
13

And in Production Db You Have removed the dates And you have started in test mode. Am I Right @muneer ?

1 Like
14

In production, you use Locked mode

This is a sample rule

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "$uid === auth.uid",
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Only authenticated users can access the data that is located under their own userID.

The simplest is to use this

{
 “rules”: {
 “.read”: “auth != null”,
 “.write”: “auth != null”
 }
}

Which means only authenticated users can perform CRUD.

2 Likes
15

Thanks @muneer for the reply
The first screen in my app in login , so whoever accesses the data has to login.
So In the End , I Can Add A Test mode And Change the rules to true am i right?

1 Like
16

or do i have to change it to auth != null

1 Like
17

I would use this. Because if you just set it to TRUE then if there is a bug in the Login Screen that allows the user to go to the next screen the database will not allow data retrieval or update.

The way I do is to start with just True for both read and write to ease the work. When the first demo is ready I switch to validating user IDs to prevent accidental data changes from unauthenticated users.

With this option, the application will only change data that is located under the User ID key in the database. Preventing accidental change to other users’ data.

1 Like
18

Thank you @muneer for your time. I will implement this

1 Like
19

You are welcome. However, when implementing such rules you need to review your project use case.

If for example you are developing a forum such as this community then you will need an admin or a group leader who is allowed to change or delete other users’ posts then the rules to restrict access to userID only will not help for the project and you will need a rule that will allow the leader to change the posts of other.

Hope that clarifies it.