-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable local development #36
Enable local development #36
Conversation
I really don't feel comfortable putting someone's Firebase credentials for all to see. It's a pretty hefty security flaw IMO. The secrets file already has a template. I'm fine with adding a command snippet in the README to copy it or even generating an empty one, that parts great But I would rather point people to |
That increases development setup time from 5 seconds to about 2 hours, if you don't know what Flutterfire is (as I didn't). Nothing is being sent to Firebase as far as I know, besides usernames and hashes of passwords (which you're encouraged not to do at all if you read the README); if that's not the case, then I am having my privacy violated as owner of that firebase application also. If you want, you could set up a second dummy firebase app as yourself, but there is absolutely no reason to make it so hard to develop for this otherwise awesome app. Those are my thoughts at least. |
No developer will be concerned about privacy concerns; the source is available, and the license says
|
I am pretty sure if I cared, I could dig in the javascript being served by web.dungeonpaper.com and find the contents of both secret files you have. I don't care, but that is the reality of distributing code. It's not as though you can't just |
In Firestore's official docs, they do mention that these are not secrets; however, it is still generally not recommended to include them in open source projects. While yes, every person can technically find these details, putting them inside git will allow for far more attack vectors (especially automated ones). At the very least, a DDoS or rate limiting on unprotected resources, whichever they may be. I don't want to open that attack vector. From the docs (highlight added):
As for the ease of starting to work locally, I will add a one-liner shell to copy the secrets file as well (the blank one with the Sentry DSN), but the The majority of the work is creating a Firebase project. While it would be nice to make the app work entirely without connection to Firebase, it would require much deeper changes to the code, which I am not prioritizing right now (but I am definitely open to PRs on that front). As a possible solution, however, it should be possible to skip initialization of Firebase on init, and maybe prevent some other services from trying to connect, but that needs to be checked and tested. Mostly I think skipping Firebase init might be most of what's needed, as well as preventing the |
And I'm not suggesting you put your firebase up, only mine, which it doesn't matter if someone DDOSes |
Add a simple shell script which copies a dummy
secrets.dart
and myfirebase_options.dart
which should allow for, at the least, an easier developer experience for others.Document in the README how to use it.