Allowing to exclude secret on demand #2
Conversation
|
Hello Youngchan, first of all, thank you for taking the time to dive into my rubbish code in order to add this feature (and for updating the readme, hehe) :) – I'll merge your PR after running some basic tests! Believe me or not, the very first iteration of this module worked liked this, however, before putting it on git I decided to go with the secrets instead, so people wouldn't have to fiddle with access rules. The reasoning behind this decision was: A) Changing rules would be an additional step where a lot of things could potentially go wrong, think typos, Firebase wouldn't save the modified rules, people would forget to change them or would set invalid rules, etc. Then people would ping me in the middle of the night, asking me why the hell they can read but not write values to their database and I'd have no idea where exactly things went wrong. To me, this was against the goal of providing a plug-and-play-ish module. Secrets, on the other hand, are either correct or not, so it's a binary make or break property. Even IF people bump into problems with copying the secret into their Framer-project, I'd argue these problems are way easier to detect and to debug than having some obscure access rules somewhere on the Firebase site. B) I thought, asking people to change their DB access rules would require some explanation on why they want to do that, after all, granting everyone on the web read AND write access to your DB is something that intuitively seems to be insecure and therefore wrong – which it is, to some degree (then again, I assume and hope you only share your prototypes with colleagues, testers and people that wouldn't want to do cause you any harm). In short, If I'd ask people to change their DB rules – even with a proper explanation – I'd assume people wouldn't feel comfortably doing so. Now, putting your DB secret in plain characters in your Framer project for everyone to see isn't any better or more secure for that matter but the narrative is quite a bit different: If you put your secret key in plain text into a Frame project that potentially anyone can open, see and edit you intuitively know it's no longer a "secret" – after all, you're literally handing everyone a key to your database. I think this is a pretty straight-forward way of telling people of what they're doing and what consequences it could have. So all in all, going with secrets rather than with rules was a design- and not a decision based on security. BUT if you know what you're doing and are willing to change access rules you should totally have to option to go with rules instead, hence why I'm happy that you made that change. Again, thanks! |
|
Everything's looking good, I'll merge and update all of my examples. I'll keep the secrets in those example for the reason provided above as I consider access rules a "pro"-feature (for now). Just wanted you to know so that you don't wonder :) |
|
Hello Marc, I really appreciate your response and sharing your thoughts on the design of this module! 👍 |
|
Thank YOU for contributing! :) All my argumentations and design decisions aside, as Firebase is now moving to the unnecessary complex OAuth 2 and secret keys are now considered an EOL legacy feature, it seems very likely that I'll remove the option to use keys altogether with the next major update. At that point – which will happen rather sooner than later – the modification of access rules will be required due to a lack of better alternatives, I'm afraid. |
Hello. Currently, the module always require secret key and force to share it when the Framer prototype is shared on cloud. Therefore, I thought about making secret optional. I understand this is not a complete solution regarding security, however, it seemed still better than not sharing secret on public.