Firebase Security - Add Credentialized Setup

[dbozarth]

First, thank you for creating this project. How difficult would it be to add the ability to run the DB connection secured. In your setup the connection is established in "TEST" meaning that FB will reset the security to AUTH every 30 days. It would be nice to have the ability to use email/password connection security so that a project could be used more permanently. If I understand FB for Python there is a firebase-admin library that uses API Keys. The values are stored in a .env and then used as the initial connect routine. Given the credentials and URL path are all that is required the additional memory should be almost zero. ESP32-WROVER-E has 4MB flash and the WROVER -IE has 8MB. Plenty of room.

What makes FBRTDB so interesting to me is the serverless aspect allowing for easy data collection on the MC and easy dashboard creation for control and monitoring using almost any web framework... ie.. React, Angular, Flask, Vue, etc.. Within maybe one hour you can have all the ESP32 side and a hosted dashboard up and running.

You could have an async set up to read the DB on the ESP every so often to check for commands pushed into the DB from the hosted dashboard. Based on my experience with FB you could do so with latency under 100ms(my best was 18ms). This makes it almost possible to get a realtime(almost as RT would be < 10ms) roundtrip. ORM connections take too long for such low latency.

I would be willing to work on creating the required additions to your library to allow for the secured connection. Let me know if there are any hurdles that cannot be crossed and this is why you have chosen to stop at open connection protocols.

Again, thank you for the effort.

[ckoever]

Thank you for your suggestions. The connection to the database with credentials is already implemented in the "beta" branch. The reason why I never pulled the beta branch is firstly because there is no documentation for it (just didn't have the time) and because the setup script that is supposed to simplify the setup doesn't run smoothly.

Basically you can orientate yourself on these pages
https://firebase.google.com/docs/reference/rest/auth
https://firebase.google.com/docs/reference/rest/database

The reason why I wrote the code with threads back then is that the usocket library did not support asyncio. Therefore, there would have been no speed advantage.

If you want to contribute in the project, please contact me on discord ckoever#0086
But basically the new beta branch is divided into:
class rtdb + auth
--> Only the starter + configuration functions
class INTERNAL
--> Where the connection is made and modified
class INTERNAL.rtdb + INTERNAL.auth:
--> The functions that do something with the established connection ("LOCAL_SS")

[dbozarth]

What version of MicroPython are you testing with? MicroPython v1.19.1-espnow-6-g44f65965b fails. No matter how I restructure the SSL. ujson.loads throws an exception for syntax on the JSON return value.

…

On Sep 9 2022, at 6:33 am, Christian Köver - Draxl ***@***.***> wrote: Thank you for your suggestions. The connection to the database with credentials is already implemented in the "beta" branch. The reason why I never pulled the beta branch is firstly because there is no documentation for it (just didn't have the time) and because the setup script that is supposed to simplify the setup doesn't run smoothly. Basically you can orientate yourself on these pages https://firebase.google.com/docs/reference/rest/auth ***@***.***/0?redirect=https%3A%2F%2Ffirebase.google.com%2Fdocs%2Freference%2Frest%2Fauth&recipient=cmVwbHkrQUlQRldKQUw2SEFYWEhDVUNURlBKTE9CRkJMUk5FVkJOSEhGREFWSVdRQHJlcGx5LmdpdGh1Yi5jb20%3D) https://firebase.google.com/docs/reference/rest/database ***@***.***/1?redirect=https%3A%2F%2Ffirebase.google.com%2Fdocs%2Freference%2Frest%2Fdatabase&recipient=cmVwbHkrQUlQRldKQUw2SEFYWEhDVUNURlBKTE9CRkJMUk5FVkJOSEhGREFWSVdRQHJlcGx5LmdpdGh1Yi5jb20%3D) The reason why I wrote the code with threads back then is that the usocket library did not support asyncio. Therefore, there would have been no speed advantage. If you want to contribute in the project, please contact me on github ckoever#0086 But basically the new beta branch is divided into: class rtdb + auth --> Only the starter + configuration functions class INTERNAL --> Where the connection is made and modified class INTERNAL.rtdb + INTERNAL.auth: --> The functions that do something with the established connection ("LOCAL_SS") — Reply to this email directly, view it on GitHub ***@***.***/2?redirect=https%3A%2F%2Fgithub.com%2Fckoever%2Fmicropython-firebase-realtime-database%2Fissues%2F5%23issuecomment-1241863832&recipient=cmVwbHkrQUlQRldKQUw2SEFYWEhDVUNURlBKTE9CRkJMUk5FVkJOSEhGREFWSVdRQHJlcGx5LmdpdGh1Yi5jb20%3D), or unsubscribe ***@***.***/3?redirect=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAIPFWJH4WQUBOESXUMFBMLDV5MOBNANCNFSM6AAAAAAQIPQ77Y&recipient=cmVwbHkrQUlQRldKQUw2SEFYWEhDVUNURlBKTE9CRkJMUk5FVkJOSEhGREFWSVdRQHJlcGx5LmdpdGh1Yi5jb20%3D). You are receiving this because you authored the thread.

[dbozarth]

I was able to get main working with V1.14. I would think that to speed the data roundtrip one could somehow open the connection and keep it open so as not to have to reconnect each time you interact with FB. This takes about 1.5 sec to connect=>Send req=>Disconnect. In theory there would be a session key that would keep the connection alive until expiry or disconnect.

Any ideas on a method to do so?

[ckoever]

video
I Updated the beta branch.

[ckoever]

I was able to get main working with V1.14. I would think that to speed the data roundtrip one could somehow open the connection and keep it open so as not to have to reconnect each time you interact with FB. This takes about 1.5 sec to connect=>Send req=>Disconnect. In theory there would be a session key that would keep the connection alive until expiry or disconnect.

Any ideas on a method to do so?

Only one "command" can be executed in that cycle with REST API.