Enable local development

[magnus-ISU]

Add a simple shell script which copies a dummy secrets.dart and my firebase_options.dart which should allow for, at the least, an easier developer experience for others.

Document in the README how to use it.

[chenasraf]

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 flutterfire configure properly than put someone's credentials there; both for your sake - against abusing of the Firebase services on your name, and both for users' safety that have no idea what kind of information is logged/sent to a Firebase account which they don't know, with no way to properly address privacy concerns - I have no way to enforce the privacy policy this way, and I might be liable for any potential (even if very unlikely) damages as result

[magnus-ISU]

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.

[magnus-ISU]

No developer will be concerned about privacy concerns; the source is available, and the license says

Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

[magnus-ISU]

Also: https://stackoverflow.com/questions/71989719/does-firebaseoptions-should-be-kept-secret-or-can-be-available-in-source-code-wi

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 curl any network traffic you want anyway.

[chenasraf]

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):

For open source projects, we generally do not recommend including the app's Firebase config file or object in source control because, in most cases, your users should create their own Firebase projects and point their apps to their own Firebase resources (via their own Firebase config file or object).

https://firebase.google.com/docs/projects/learn-more#config-files-objects:~:text=For%20open%20source,file%20or%20object).

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 flutterfire snippet is already there - it's 2 lines.

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 AuthProvider and UserProvider from querying the auth state from Firebase.

[magnus-ISU]

And I'm not suggesting you put your firebase up, only mine, which it doesn't matter if someone DDOSes