Email Whitelist for Rules

[Benjamin K]

Apologies if this message was already posted but unfortunately I'm not overly familiar with google groups.

Currently I'm designing an application that will be used in a fairly small group, what I would like to do it have all people register via this system: https://www.firebase.com/docs/web/guide/login/password.html then have to have the user be approved via an admin email. If not this then allow any account creation but only allow users that are stored in a whitelist that contains the emails of authorized users to read and write to the database.

Any help is very much appreciated!

Thanks, Benjamin

[Tom Larkworthy]

HI Benjamin,

Sounds like you need email verification with a few extra conditions. There is an example here: http://www.webhook.com/blog/e-mail-verification-with-firebases-simple-login.

Tom 

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/9b7eba89-08b2-43da-942e-22c864083049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin K]

Hmm, that seems like it could probably accomplish the task but I'm not using a web page I'm using an desktop Java application. Is there any alternative methods to accomplish this because from what I can see that method relies on a web service pretty heavily.

[Tom Larkworthy]

The above relies on a server side process that talks to Firebase and sends an email. I wouldn't personally call it a web service as its not connected to the (world wide) web, although maybe email is a bit webby (and another thing to setup)

Are you hoping to avoid any server side processes? If its a really small group of people you could manually whitelist the users in the /users/$user/verification path from within the Firebase dashboard. I can explain more if thats the direction you want.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/aa399e53-90b7-4498-a8fc-dcea7a79c0e6%40googlegroups.com.

[Benjamin K]

Unfortunately due to my lack of experience with web development I think just a whitelist will do fine, it's just going to be a fairly small application with about 8 users to begin with and I can always change the system in the future when I'm more familiar with web development. If you could go into more detail that would be great.

[Tom Larkworthy]

OK cool. If its only 8 users manual verification might be the expedient route.

So let the users sign up with email and password. Allow them to create a user record but with verified set to false. Allow them to state their *claimed* email. Then prevent them from writing any other data until that flag is flipped. So the security rules would look something like:

{
    "rules": {
        "$user": {
            "verified-flag": {
                // a new user can only write false from a client device
                ".write": "auth.uid === $user && newData.val() === false",
                ".validate": "newData.isBoolean()"
            },
            "email": {
                // a new user can write here only once, and only with a value that matches their auth payload claimed email
                ".write": "auth.uid === $user && !data.exists() && newData.exists() && auth.email == newData.val()",
                ".validate": "newData.isString()"
            },
            "userdata": {
                // write only if logged in user and that verified has been flipped to true
                ".write": "auth.uid === $user && newData.parent().child('verified-flag').val() === true"
            }
        }
    }
}

So the user app would

1. let the user create a username and password account

2. the user application then writes to /$user/verified-flag with the value of false  (where $user is their auth uid see https://www.firebase.com/docs/android/guide/login/password.html)

3. then the user application writes the *claimed* email to /$user/email

Then they cannot write anything in the privileged userdata area until someone flips the verified-flag. 

4. You manually check you firebase admin dashboard for new verified-flag = false (or issue a query on /$user for verified == false). You should not flip that bit until you have verified ownership of that email address, as any client can claim any email address. So send them an email saying "did you create an account in the last 24 hours?" If they say yes, and the email is on your whitelist, then its probably safe to consider that account verified and you can just use the Firebase dashboard to manually change their verified-flag to true. 

5. Now that user account is verified they can write to /$user/userdata which is where your main application data will reside.

I hope that helps, the first link I posted goes further by automating step 4, but you need to be able to read and write emails in a service somewhere.

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc85cc43-e546-415d-96ba-b7f660aadfe8%40googlegroups.com.

[Benjamin K]

The auth variable doesn't have a predefined email variable, I've looked at this: https://www.firebase.com/docs/security/guide/user-security.html but it seems there's not an option to auth with email and password as well as use a custom token.

[Tom Larkworthy]

Ooops, sorry, my mistake. Yes, the email field is available in the application SDK but is not encoded into the auth payload https://www.firebase.com/docs/web/guide/login/password.html

I think we removed that feature because it was easy to assume that was a trusted email address when, in fact, it was not. However, as the flow I outlined above was verifying the email, it is not a problem for the client to just copy that field into the Firebase. So remove that clause from the email .write rule. This re-enforces the notion that the email can be spoofed, which is why you need an additional step to double check the validity of email.

    "email": {
                // a new user can write here only once, another process needs to verify this email address
                ".write": "auth.uid === $user && !data.exists() && newData.exists()",
                ".validate": "newData.isString()"
     },

Sorry about that.

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/f6b75b85-d74f-42d6-935a-6ef2caa1e007%40googlegroups.com.